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.
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:
@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.
@myway880 Not entirely sure what you are saying here. Can you elaborate in the other thread? This thread is for weekly reports.
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
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.
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
clever math doesnât sound simple
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.
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:
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.
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?
Well, the attribute node gives access to custom attributes, right?