formal feature request [new nodes] dictionary node, list node, increment node

ideas for super useful nodes.

[dictionary node] has N data slots, exposed using layering of some sort.
[think game logic states each with x slots defined by user]

inputs = key

outputs = data from slot

uses (combined with inciment generated key can access data on a grid)
many other use cases

[list node] similar to dictionary but an ordered list
inputs = index
outputs= data

uses = accessing dif maps based on perlin noise and inciriment node int

incriment math node setting
inputs[ value,step]
output [value]

with these we can do procedural textures, interpolate a grid of probes, and in general wield much more data with a smaller nodegraph.

You should explicit the context of your demand.
Obviously, you are not talking about animation nodes addon that already have that.

So in what node system do you want to add theses nodes ?

A formal feature request, no less?
This’ll definitely have to happen.

glsl nodes, and cycles.

in the game engine we could use the dictionary and the incriment node to select a precomputed reflection map
(for static elements)
or a precomputed global illumination probe system

The only people who currently put any effort into the game engine are the UPBGE developers and it does not really make sense in my opinion to put a formal feature request here. The game engine section would kind of make more sense.

it benefits much more than just ge people,

the dict could store textures or values, anything really.

using inciment, and a dict one could have a 24 channel splat map w/little effort,

Why would you need a dictionary for that? I don’t see what the advantage over the current situation would be.

incriment color red .05 as key [ spit out 20 diff maps]
(.0 through .05 = texture 1)
(.051-.1 is texture 2 )
it would hide huge complex nodes into a tight package.

If it is part of a shader, it means all the contained textures would need to be loaded all the time which would have a negative performance impact as all of them would be sent to the GPU.
If you think about a strategy to only send the required textures, I think it is the wrong place to have it. It would need to be outside of the shader for this.

in a splat map, rgba are used to mix 3 or more textures, with adding more textures per color channel, the nodes quickly become very complicated.

this does the same job without any complications.

and for linear interpolation of a grid of any format of samples,
(reflect probes, or global illumination probes etc)
the dictionary is the way to go.

Sorry, I seriously don’t see what the benefit would be.

sounds like you are trying not to :wink:

If you’re thinking that using different value levels per color channel will give you more splat textures (in a way that is smooth and looks correct), you are sadly mistaken.

In transition zones (as the red values in the vertex color goes down), you might get lines that show different textures in the middle of it. What you want is the ability to have a custom paint type where you define any number of individual channels given any name you choose, that is the only way that splatting more than 4 textures will really work in a way that one expects.

Since you are explaining it in a very abstract way, I am not sure whether I understand it correctly. My understanding at this point has the implication, that it does not really make sense.

the idea is to store a grid of images, this node will be used to mix multiple images

I was thinking about it and having a vector as input and a reflection as a output would be ideal

before I was thinking of mixing the closest 9 probes or something using nodes,

now I think the node itself would need parallax correction built in.