Displacement testing needed

[Ludvik Koutny]

Hi...

for those of you who have access to nightly builds, I would like to ask you to test displacement in 2013-02-04 build, as it should be vastly improved. If you find that there is not enough detail in foreground, do not be worried to increase Max subdiv per poly value to something very high.

Just do not try to combine very high max subdiv value with very low projected size and dense mesh, if you do not want to end up with a crash due to the running out of memory ;)

[lacilaci]

Alright.

[Sam75]

Could we have a "protect border" option ?

[Ludvik Koutny]

You mean edges break at borders?

[Sam75]

Not sure how to call it, displace tends to shift the whole object, can be a problem for open surfaces.

[Sam75]

Is 10 000 subdiv enough ?

I have to use turbosmooth to get good results.

Don't pay attention to the noise I messed up with gamma correction.

[Ludvik Koutny]

I do not know what protect border is.

As for Max subdiv per poly, I too think even 9999 might not be sometimes enough. I proposed to raise cap to one more digit and set default to 16 000. Hopefully, that change will make it to the new build. (Currently, some shading components are being rewritten in order to implement participating media, so there will be 3-4 days break before next daily build)

As a temporary workaround, i suggest you apply subdivide modifier to any objects in your scene with displacement materials, and set subdivision size in the modifier to about 100mm to make sure tessellation of all the geometry remains consistent. You can always disable visibility of the modifier in viewport only to keep your scene light and fast.

[Ludvik Koutny]

Ahh...  sorry, i missed one of your posts... Now i understand... :) Protect border means boundary edges of the geometry will stay in place so there are no gaps between displaced objects and surrounding objects in case these objects are edge to edge aligned to the displaced object. Am i correct?

[Sam75]

Exactly.

[lacilaci]

I think a "waterlevel" function might also be nice. To clip geometry.

[lacilaci]

suddenly.... holes :D

[lacilaci]

So, here's more proper working displacement test.. No bumpmapping just displaced geo...

Anyways that before, in my previous post happened when I lowered displacement ammount from 0,5 to 0,2. I fixed it by lowering to 0,1 and then back to 0,2. It happened only three times and so far only on this mesh, I played with displacement yesterday a LOT but this is the first time I saw it so I don't know what went wrong there...

[andreupuig]

Don't know what happens, but it seems that the model rendered unsmoothed when the displacement is active.
The Model is an editable poly with  turbosmooth modifier and subdivide. Same effect even if I collapse in an edit poly

[lacilaci]

Try instead of high displacement settings set higher renderable tesselation on the turbosmooth modifier... I had the same issue on the scanned head (look at the pic with holes). So I've set renderable subdiv to 4 and reduced displacement per poly to 500 and projected size to 1px.

[andreupuig]

Lacilaci, it works. I don't know if it's usual workflow or just a workaround, but with vray the shading remain smooth even if the subdvision is low.

[lacilaci]

Cause Vray does smooth subdivisions of its own afaik. It's even possible to set vraydisplace modifier to do subdiv only, giving you a memory efficient "turbosmooth" equivalent on the fly during rendering(memory efficient cause it subidivides only rendered portions by bucket)...

[Ondra]

This is because the normals are computed from the new geometry after displacement, that is derived from the old real geometry, so old shading normals are disabled. This causes basically disabling of shading normals when using very little displace height/mostly black texture. A workaround is to subdivide the geometry before displacement. I tried to go further and do a spherical interpolation of the shading normals, but it gave unstable results. I'll revisit it at some point, but for now I've already spent too much time with displacement.

PS: it looks like vray interpolates the normals correctly, but not the actual geometry.

[lacilaci]

Here's a pretty nice result using 32bit .exr for displacement.
Mesh on the left is original(about 1500-2000 poly), on the right it's corona displacement with 1px projection and 500 max subdivs.

It's not perfect but mainly because the original mesh is too low poly, but I wanted the displacement to do most of the work.

[Javadevil]

Here's a quick test with "Projected size pixel" 3000 Max size Polygons and 1px.

I found "Max Size units" chews up ram like crazy, and to get anything decent, it needs to be 0.2cm,  I haven't have a successful displacement from it yet, even with low memory Embree.

cheers

[lacilaci]

Well using max size in units tesselates the whole geometry so it will surely be heavier. Useful for animations so that you don't see geometry changes on objects, but I guess if you wan't to use it, then you need to do most of subdiv. with turbosmooth or so...

[Javadevil]

Hi lacilaci, 
Yep I realise that, I still don't think max unit size is memory efficient, it chews up my 32GB very quickly. Other renders cope a lot better.

[lacilaci]

Well that's possible, I haven't really compared that with other renderers...
I'm curious though.
Is it possible to have corona dynamically load and unload geometry during rendering? I guess it wouldn't work in progressive mode but maybe in bucket mode?
You know, like set ammount of ram you want to use and let corona do the magic :D This would make possible to render scenes heavier than would fit into ram at the cost of performance.