Cycles/EEVEE Improvements - Weekly Reports

it seems that variable voronoi size is somewhat possible

It seems like something that can be done using a node group. Not sure if it is worth it.

Seems like this was done manually using multiple voronoi nodes, so not exactly variable.

1 Like

mmm, someone already answered like this, but how?

The most useful here is probably 4D, which could also be displayed as a “time” or “seed” value in order to skip implementing 4D vectors.

Very nice. Reminds me some works from shadertoy.com. Just some idea:
It would be interesting to add Voronoi cell center position control as generic input. This way interesting effects could be achieved. For example odd alternating input pattern in one axis leads to hexagonal honeycomb pattern.

Volume Info Node

A Volume Info node was added. The node provides the color, density, flame, and temperature of smoke domains:

Vertex Color Node

A Vertex Color node was added. The node provide a nice interface to select the target Vertex Color:

Vertex Color Alpha

The alpha value of the vertex colors is now exposed:

Object Color

The object color property is now exposed through the Object Info node. This is particularly useful when using a tool like Animation Nodes, where colors are computed in Animation Nodes and needs to be passed to the render target. For instance:

Notes

For the Vertex Color node, it should be noted that the vertex layers are queried from the mesh of the active object. So if the active object has no mesh, no layer can be selected:

40 Likes

@OmarEmaraDev Yes yes YES! You are awesome! Does that actually mean we don’t have to add those unintuitive ‘density’ and ‘color’ attributes anymore for rendering smoke!?

Yes. As far as I know, there is no reason to use the attribute node at all now, since all of its functions are now provided by other more intuitive nodes.

7 Likes

@myway880 Not entirely sure what you are saying here. Can you elaborate in the other thread? This thread is for weekly reports.

1 Like

Hello! Nice work! May be there is some plans to implement Multi Normal Map node or Normal Map Mix node? Lack of way to properly mix 2 or more maps really makes us stumble in work process :dizzy_face:

2 Likes

This one is massive for me, finally we can have the same material in different color variations that depend on the Object and we don’t need to create tens of material variations. Now if only each material slot could have it’s own color set up independently.

6 Likes

This reminds me (if I remember this correctly) about the fact why Object Color wasn’t initially exposed (intentionally) - it was considered an old-school structure when Cycles was first introduced. This means - it’s great to have per object/material slot/ color variation, however it’s not sure if the way it is stored is future proof and optimal. Of course, to have it like this is huge improvement over the past. Now I don’t have to use the object pass number to fade in objects individually when they share a material;)

I don’t think we have the time to do this in this GSoC project.

Not sure I understand. Do you want the material diffuse color property to be available like the object color?

isn’t normal map mixing just some simple but clever math?
There are node setups around but making it as build-in node would be more user friendly.

for example: https://blog.selfshadow.com/publications/blending-in-detail/ » https://i.stack.imgur.com/tzuBe.png

1 Like

clever math doesn’t sound simple

2 Likes

Clever indeed. It’s actually very difficult as I’ve understood it. Not that I don’t agree having it in the future would be nice. But for the GSoC it’s clearly too much already.

1 Like

Can you explain what the difference of such a mix node would be compared to current daisy chaining method? I mean mixing detail and base normals like this:

1 Like

You provided a source we can use to implement the node. But which method should we use? Are there better alternative methods? Can we verify those methods? Can we do better ourselves? What about the performance of each method? 


Those things require lots of research and development. Writing code is simple, knowing what to write isn’t.

I would rather spend time working on what we already implemented to be in tip-top shape so that it becomes easier to review and hopefully merge.

4 Likes

Now that you talks about perfomance
 one thing good in substance is taht you can see the total and each node time to process a shader/material

Could we have that in blender? or it doesn’t have sense because the internal implementation?

1 Like

Well, the attribute node gives access to custom attributes, right?