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
Seems like a bold claim. I can understand it is a useful feature, maybe making a proposal on right click select could get some interest. Really all you need is a developer interested and capable of developing the feature.
There is a pretty feature complete addon available at gumroad, here is the blenderartists forum link:
2 Likes
I’m talking about built in feature not 3rd party paid addon,next big thing Luxcore have this feature.why can’t our living legend have the same.
Hey there @brecht !
I’m a VFX professional and a very long-time Blender user. I have a generalist 3D skillset but I am specialized as a digital compositor. I love the Cycles engine and have found it to be very capable, you fine folks are getting closer and closer to feature parity with the commercial render engines, slowly but surely.
The fact that progress is being made is fantastic, you folks are great developers. However, I can’t help but feel that it’s taking too long to implement support for Deep Output with absolutely no indication that it’s in the works or being seriously considered.
There are other things like light selects and built-in World, Object, refWorld and refObject position passes(without having to do strange conversions and workarounds to make them sort of work in comp packages) that also need implementing but Deep Output is a big one. OpenEXR supports the reading and writing of Deep data and has reasonably clear documentation.
I’m aware that generating Deep data and being able to write it are two different things of course. Given that almost all the major engines and packages support Deep Output by now, what exactly is it going to take to get it implemented as a utility pass in Cycles? Looking around, some of the previous mentions of feature requests for it go back as far as 12+ months.
I really don’t mean any offence but non-answers and skirting around the subject have been incredibly frustrating. I genuinely enjoy using Blender and Cycles and believe that having Deep Output would take what is a great render engine and get it on the path to become an amazing render engine that studios would have to be crazy not to adopt, promote and contribute towards.
Kindest Regards & Respects,
Alan
4 Likes
It would be a great feature to have, but at the moment there are quite a few features higher on our priority list. Realistically we can’t give a time estimate for it. It’s really the same as other features, we’d need more time and developers to get it done faster.
5 Likes
Apologies for the delayed response, quick trip to the airport and back.
That’s a bit of a bummer. Not to press the issue too much but do you think it’d take something along the lines of when Epic gave the dev team a grant to improve FBX support? I think that was around the 10,000 Euro mark in 2014.
An unofficial rough estimate would be a great starting point for what it could possibly take to get a feature like that implemented.
Also, I’ve got some programming experience and a solid understanding of OOP under my belt but I’m not super familiar with the Cycles API, any pointers on where to poke around should I be desperate enough to mess about? 
1 Like
This is not completely Cycles-related, but it would be really great if we could use all available Cycles textures in the Displace modifier as well, instead of only rendertime micro-displacement.
Additionally, it would be even more powerful if there’d be UV projection options for the Displace modifier, such as cylindrical, spherical, cube, planar, shrinkwrap, …
— Edit: Someone pointed me to this plan, which will hopefully be realized soon. 
5 Likes
I second this. That would indeed be quite useful.
2 Likes
Cycles micro-displacement has been left hidden in Experimental status for more than 4 years now. It’s about time it becomes a Supported feature.
17 Likes
Continuing the Cycles Displacement discussion, here is some feedback from user Romanji at Blender Artists:
The standard setting for the Displacement node should be set to Displacement, not Bump only which kinda defeats the purpose. There are 3 steps involved in setting up Displacement. 2 are not really intuitive and maybe should be handled better in terms of communicating it to the user.
The displacement node in the shader editor is obvious. The setting of the node in the property editor is totally not obvious.
The fact that you have to subdivide your model and need to use Subdivision modifier is semi obvious (since it is the only way to do that) but it could also be confusing to people.
9 Likes
Agreed that this should be streamlined. I don’t use displacement often but when I do, it takes a good two minutes and three test renders before I finally tick all the boxes.
It’s going to be easier already with subdiv as an object property (as in you won’t have to add a subsurf modifier), and it would be made even easier by changing the default displacement type in material properties to ‘true’ or ‘both’.
2 Likes
I think the default type could stay on “bump” but move the dropdown into the material output node. That way it easy to reach and find.
First I thought that it could be put into the displacement node but since you can have several displacement nodes in one shader graph I am not sure if this might cause problems.
3 Likes
A way to avoid confusion would be: no option, Displacement only makes …Displacement! Let’s do the bump connecting bumps or normal maps into BSDFs Normal sockets
4 Likes