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.
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.
24 posts were split to a new topic: Proxy objects
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.
Itās been asked for. This is usually called light linking, and itās on the cycles roadmap.
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
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
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
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?
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.
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.
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!
All render engines have Physical sun and sky horizon lighting feature,so can we have this for cycles.