Autobump concerns and 2d displacement ala vray

Hello friends,

I’m a bit out of the loop re: corona development but have just installed max2019 and corona 3 and was interested in testing out displacement.

One of our constant battles is with memory usage and displacement is part of that. I know you are probably sick of me going on about vray 2d displacement but it just worked and I never had any of the issues I have with 3d displacement.

Initial impression of autobump is that it doesn’t really solve our problem and in the end just looks like an aggressive bump map. For displacement values of 2-4px in a 5k render it actually looks worse I would say, and for higher displacement pixel values it does definitely help but i don’t think its a viable replacement or solution.

thoughts?

pg

corona3_autobump_slower.gif

I agree 2-4px looks somewhat flatter than the rest here.

I can only co-sign. I wrote my opposition to this multiple times, auto-bump is not solution to better displacement at all in my opinion. And we could have used bump/normal map on top before anyway. Only displacement is what looks good, and for that I need to keep it sub <2px, even for high-res (5-8k renders) and yet…the detail is nowhere as sharp as some other non-tesselation based solutions (like Vray’s 2D, but I’ve heard very good stuff about F-Storm and Octane disp), while costing fraction of memory.

Well to chime in myself… I find that whatever Octane is using is really useful - It has insanely low precalc times even for 8k displacement textures. My main issue with Corona displacement would be the really long precalc times which make it really hard to use in animation work.

I presume a 2D displacement option would probably solve the cons I listed.

I agree 100%. I can also confirm that Fstorm displacement is really memory efficient. Just saw a post on the Fstorm FB page that speaks by himself :

we will basically make the displacement better until it is good enough :wink: 2D disp is drastic step (both complexity wise and UI wise, since it has limitations and has to be set up), but if there is no other way (which it seems to be the case), then we will do it.

Glad to hear it Ondra :smiley:

Can someone explain to me what is that 2D displacement and how it differs from normal one? I’ve looked at Vray manual, but its description is rather vague. I constantly read 2D displacement this, 2D displacement that, but i never had a chance to work with it and i have no clue why it is so magic.

To be honest, I don’t really know how it is computed backend. All I know is that it gives decent results with a much smaller memory footprint than 3D displacement (in Vray) which is the main issue here. Basically, we’re all asking for crisp displacement and less memory usage. I’m still not really sure it is the best way to go tho. I’m still convinced there are other solutions to explore. Looking at Fstorm displacement, I’m quoting :

“FStorm displacement doesn’t subdivide the initial surface, doesn’t take much GPU memory and is camera independent. It can be applied to almost unlimited surfaces.”

It looks like it is based on some sort of volumetric displacement, potentially the same kind of tech used for geopattern. Maybe it’s not even possible to do that kind of stuff on CPU, I don’t know.. There are some rough explanations on the manual page :

But I think this is to be explored before taking any hurry decision on what’s the better option.

edit : It also looks like it is computing only one tile and conforming it to the base mesh while keeping continuity. That could explain the low memory footprint.

This paper looks interesting in that regard : http://www.cs.technion.ac.il/~gershon/papers/srf_disp_map.pdf

examples :

XYZ based displacement

Pattern deformation

UV based displacement

edit 2 : Also, looking a the kind of stair-stepping artifacts shown on the example below, it looks like displacement is rendered from the bounding volume (see the manual) using ray marching technique, hence the non-subdivision method. (still total assumption there)

@Ondra Just for curiosity, Is 3D displacement computed on the whole mesh as one signle entity or is there some kind of tech/optimisation like in the paper mentioned above?

I’m assuming this auto-bump is the one you have to enable in the develop/debug mode?

If you don’t enable it - has the normal default (tesselation method) been improved at all in Corona 3?

Only asking as the ‘Highlights of the Release’ state the following “- Displacement improvements allow you to use lower Displacement settings with the same image quality, lowering memory usage by up to 50%.”

Is that statement a by-product of autobump, or just a general improvement to displacement?

From the use of the Autobump. Other than “sharper textures at grazing angles” which will improve the look of displacement (with more detail, at grazing angles :smiley: ), there isn’t any other changes that would affect the displacement system.

I’ve made some tests and I can confirm that only one tile of geometry is processed and then scattered with mesh continuity :

150x150cm plane - 150x150cm planar UV - 8k tif Depth map (130Mo) - 620Mo of Vram used

10000x10000cm plane - 150x150cm planar UV - 8k tif Depth map (130Mo) - 620Mo of Vram used

And there is still plenty of details displaced

Even 2D displacement won’t match that memory usage so there is still room for improvement.



Fluss, feeling like you want to make that comparison further :- ) ? Would love to see F-Storm vs Vray’s 2D as well.

In fact, F-Storm does look superior here. Vray’s 2D always had its drawbacks like continuity, hence they called it ‘2D’ despite the algorithm (texture-space) having’t little to do with the namesake. But I always though the memory footprint was largely based on the texture sampled rather than total surface area like the subdivision.

Does the F-Storm has any drawbacks ? Is it properly self-shading ? Because it looks like miracle.

But if you do the same test in Corona (150cm plane vs 10000cm plane, that is similarly framed), you will get similar RAM usage between these too, because of adaptive displacement. Unless you want to say that Fstorm’s displacement isn’t adaptive and it’s calculating gazillions of triangles even when mesh is occupying single pixel in frame buffer. Or i’m missing something here?

Yeah, in this particular example Corona would do the same, although it seems both approach it differently. I am very intrigued by the F-Storm displacement.

Autobump was the only change regarding displacement. If you disable it in devel/debug, you will get V2 displacement.
When you load older scenes (pre-v3) you will be asked whether you want to switch to new displacement mode (autobump+lowered tesselation), or stay with the original settings.
When you create a new scene with Corona v3, autobump is on by default.

You’re right Juraj, I made a test with Vray 2D displacement and no matter the amount of displaced surface, the RAM footprint does not seem to change. It behaves exactly the same as Fstorm in that regard. There is just a couple of GB in between.

I made a simple displaced plane with 12K textures (diffuse, glossiness and displacement, no bump/normal map). Not that easy to get Vray and Fstorm to match so there is a tiny bit of difference. Also, note that Fstorm does not have map blur parameter and looked quite sharper on the first look so I set Vray map blur parameter to 0.5 :

Vray - no displacement 4641MB RAM - With displacement 14500MB RAM

Fstorm - no displacement 1820MB VRAM - With displacement 3650MB VRAM




wow theres so much more high frequency detail in fstorm!!
Its insane that its literally just the one guy developing. The other day someone asked for a copy button in the vfb. three days later it was there haha

I can’t tell if the Fstorm is sharper because of more displace detail (doesn’t seem so) or because the textures are overall bit sharper.

Can you do Corona in same setup now that you have it, would be super cool to have all :- ) Thanks much for doing the tests.