Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

Access to the cell value in Repeat modifiers

A topic by andybak created Aug 11, 2018 Views: 331 Replies: 2
Viewing posts 1 to 3

Hi. I've been hacking the generated shaders to get effects such as shown below. I'd like to start modifying the built-in shader templates and snippets to make this reusable (and even animatable).

The changes are fairly simple.

1. Add an out parameter to the modifier snippet so that I can also return the value of cell

2. Declare cell in map() and add the extra parameter

3. Modify the radius in the function call to sphere() based on the value of cell.

4. Modify the material ID that map() returns based on the value of cell.

#

Obviously though - if I change the templates and snippets I've essentially forked your code and the  burden for future updates will be on my shoulders.

So I wondered if you'd be interested in incorporating this feature in the official codebase? There's some further work needed to make this less hacky - probably the ability to add multiple materials to primitives and other ways to make use of the cell value.

Yes! Repeating with a cell ID got cut before release, but I was definitely going to add it back in an update.

I'd love to see any code or snippets or general feedback on doing it in a way that's not too hacky!

> I'd love to see any code or snippets or general feedback on doing it in a way that's not too hacky!

I think it's more of a UI problem than it is a code problem. Where is 'cell' useful and how can you elegantly allow it to be used to modify other values.

One of the reasons I started messing around with Klak is that this feels like it should be a node-based graph thing rather than the hierarchy based UI you've currently got.

However - logically speaking you can create graphs with the inspector UI - they are just harder to visualise. 

I think compiling a set of potential use-cases for 'cell' might help clarify both the code structure and the UI


1. Applying materials to a subset of cells based on a rule

2. Applying modifiers to a subset of cells based on a rule

3. Choosing primitives (or whole subtrees) based on the cell value and a rule

etc etc