Speaking of trees and plants, you can achieve a good amount of variation with procedural (also animated) deformation, being it one or more displacement modifiers based on cloud/wood texture and world or an empty coordinates. It is also very light on memory. Also particles-foliage can have procedural and animatable texture driven randomness.
Is what you need more control?
That’s an interresting idea - I just tried it, but I don’t see any straightforward way to correctly bend geometry without a node setup that is too complex to be user friendly. Maybe there could be a dedicated Node for this kind of deformation. Also - if you want deformation for the individual branches, that would become horribly complex probably.
Edit: Just noticed you meant modifiers and not nodes - but I think the same usability problems occur there.
3 Likes
Yeah with real displacement, instead of using modifiers, we can go the shader way as well, which can also provide much more options. Any way, the key point is to use procedural random textures, to get unique variations for all the geometries
I’d love to see a node to convert a Normal map to grayscale height values for use as a Bump / Displacement map.
I know a Normal map doesn’t contain height data, but a Height value could be added to the node, so you can adjust it to your needs.
Different methods to interpret the normal data could be implemented as a drop-down menu.
Thanks.
Hi,
I would have a little request to submit. I already made a topic about that here.
Would it be possible to set the ‘Alpha’ output of the ‘Image Texture’ node to 0 when no texture image is defined in Cycles ?
That is already the case in EEVEE and I find it’s very useful when you want to use the ‘Alpha’ output as a mask.
Thanks for consideration.
Any chance we can get per path type multipliers for lights? Essentially float values for ray visibility instead of booleans. It really helps in production lighting.
Hi, I saw this being asked on blender artists https://blenderartists.org/t/exclude-objects-from-light-source-2-8/1151414 and there’s been times I’ve missed it. I can’t believe no one asked for it here (apparently) but being able to exclude objects from certain lights is quite important in some cases.
2 Likes
It’s been asked for. This is usually called light linking, and it’s on the cycles roadmap.
2 Likes
I looked for it the way you named it and I found there’s a patch for it already but needs to be reviewed. I hope someone can push it forward and accept it or change wathever is needed since it’s almost there. https://developer.blender.org/D1985
1 Like
So it does not seem that there’s hardly any talk on transferring bake data to vertex colour data. In 2.79, we had bake Ambient Occlusion to vertex colour for example, which used Blender Internal. But we have since lost BI Renderer in 2.8. Any talk on getting this incredibly useful feature back? Vertex colours are still necessary! Thanks 
1 Like
mantra can do that. acctualy 
The latest official NVIDIA Studio driver release supports Optix (no more need for a beta driver).
Now I hope Optix will soon support all Cycles features, including the Ambient Occlusion and Bevel nodes.
Aaaand the GTX line of cards, I’m curious to see the improvment
1 Like
Dont know if this has been mentioned before, but when you have a scene with geometry far from the origin you start getting precision errors in shading.
Have you guys considered adding a “render in camera space” option, where world zero gets moved to where the camera is relative to the scene?
4 Likes
Basically this: 
There used to be this:
I think it’s helpful to see memory usage and time remaining because it helps with optimizing.
While I don’t think it needs to be as precise (ms) I think time in seconds is very useful. Both total time and time remaining. Then if you change something in the material, you know exactly what is the difference in render time.
something like:
Path Tracing Sample: 56/100
Mem: 537.51 MiB
Previous: 7.3 s
Time: 5.1 s (and raising as is being rendered until the end - then upon new render is moved to “Previous” right above)
Remains: 3.1 s (and lowering as is being rendered)
this way if we add 5.1 s + 3.1 s (and the estimation is good) the render will end up taking 8.2 s which is longer than previous 7.3 s so there was probably done something that makes rendering slower.
Would even be good to separate Memory usage for geometry and textures because those are the biggest influencers anyway,
and in Eevee there could be how long SSR takes and how long Ambient Occlusion takes and how long Shadows take, sometimes when preparing a rendered animation with Eevee it’s good to know these for optimization.
2 Likes
if i remember viewport never had such statistics… the bar u are referencing with memory stats etc was only avable as Final render.
Here is the full screenshot of default cube:)
and here it’s visible that’s 3D View:
through this it’s also visible that smaller the rendered window the lower it’s memory requirement is. Makes sense but can be missed without the Memory usage.
1 Like
Hi @OmarEmaraDev! I noticed that there’s now a random per island attribute. Thanks for that! It’s a much needed addition…
I would like to ask if there’s any plans for having this great suggestion by duarte.framos as well?
random output of the Object Info node would be a “From Dupli” option, so randomness would be kept consistent across multiple object inside one instance of a collection
Though IMHO, from parent gives much more room for control over which get random values.
Having both will be super awesome!
1 Like
All render engines have Physical sun and sky horizon lighting feature,so can we have this for cycles.
1 Like