Corona Renderer Forum

General Category => General Discussion => Topic started by: peterguthrie on 2018-11-28, 20:14:51

Title: Autobump concerns and 2d displacement ala vray
Post by: peterguthrie on 2018-11-28, 20:14:51
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

Title: Re: Autobump concerns and 2d displacement ala vray
Post by: Jpjapers on 2018-11-29, 00:53:57
I agree 2-4px looks somewhat flatter than the rest here.
Title: Re: Autobump concerns and 2d displacement ala vray
Post by: Juraj Talcik on 2018-11-29, 10:39:43
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.
Title: Re: Autobump concerns and 2d displacement ala vray
Post by: nkilar on 2018-11-29, 11:09:14
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.
Title: Re: Autobump concerns and 2d displacement ala vray
Post by: Fluss on 2018-11-29, 12:06:42
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 :

(https://scontent-cdg2-1.xx.fbcdn.net/v/t1.0-9/46837313_1975015342590509_4587039894060138496_o.jpg?_nc_cat=106&_nc_ht=scontent-cdg2-1.xx&oh=2b4b97ab27253bff10413a2508e73839&oe=5CA2E4B5)
Title: Re: Autobump concerns and 2d displacement ala vray
Post by: Ondra on 2018-11-29, 12:30:59
we will basically make the displacement better until it is good enough ;) 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.
Title: Re: Autobump concerns and 2d displacement ala vray
Post by: Jpjapers on 2018-11-29, 13:01:48
we will basically make the displacement better until it is good enough ;) 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 :)
Title: Re: Autobump concerns and 2d displacement ala vray
Post by: romullus on 2018-11-29, 14:24:33
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.
Title: Re: Autobump concerns and 2d displacement ala vray
Post by: Fluss on 2018-11-29, 15:10:10
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 :

https://fstormrender.ru/manual/displacement/

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
(https://ai2-s2-public.s3.amazonaws.com/figures/2017-08-08/0fb0d7aa5edf8a51bd323b50fe812a62857dc352/13-Figure6-1.png)

Pattern deformation
(https://ai2-s2-public.s3.amazonaws.com/figures/2017-08-08/0fb0d7aa5edf8a51bd323b50fe812a62857dc352/4-Figure1-1.png)

UV based displacement
(https://corona-renderer.com/forum/index.php?action=dlattach;topic=22625.0;attach=94415;image)

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)

(https://fstormrender.ru/wp-content/uploads/2016/11/Displacement5.jpg)
Title: Re: Autobump concerns and 2d displacement ala vray
Post by: Fluss on 2018-11-29, 16:37:24
@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?
Title: Re: Autobump concerns and 2d displacement ala vray
Post by: dj_buckley on 2018-11-29, 23:51:52
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?
Title: Re: Autobump concerns and 2d displacement ala vray
Post by: TomG on 2018-11-30, 09:23:15
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 :) ), there isn't any other changes that would affect the displacement system.
Title: Re: Autobump concerns and 2d displacement ala vray
Post by: Fluss on 2018-11-30, 09:44:29
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

(https://corona-renderer.com/forum/index.php?action=dlattach;topic=22625.0;attach=94444;image)

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

(https://corona-renderer.com/forum/index.php?action=dlattach;topic=22625.0;attach=94446;image)

And there is still plenty of details displaced

(https://corona-renderer.com/forum/index.php?action=dlattach;topic=22625.0;attach=94448;image)

Even 2D displacement won't match that memory usage so there is still room for improvement.
Title: Re: Autobump concerns and 2d displacement ala vray
Post by: Juraj Talcik on 2018-11-30, 10:33:19
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.
Title: Re: Autobump concerns and 2d displacement ala vray
Post by: romullus on 2018-11-30, 11:03:28
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?
Title: Re: Autobump concerns and 2d displacement ala vray
Post by: Juraj Talcik on 2018-11-30, 13:52:30
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.
Title: Re: Autobump concerns and 2d displacement ala vray
Post by: maru on 2018-11-30, 16:28:59
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?

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.
Title: Re: Autobump concerns and 2d displacement ala vray
Post by: Fluss on 2018-11-30, 16:42:50
But I always though the memory footprint was largely based on the texture sampled rather than total surface area like the subdivision.

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.

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

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

(https://corona-renderer.com/forum/index.php?action=dlattach;topic=22625.0;attach=94492;image)

(https://corona-renderer.com/forum/index.php?action=dlattach;topic=22625.0;attach=94496;image)

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

(https://corona-renderer.com/forum/index.php?action=dlattach;topic=22625.0;attach=94494;image)

(https://corona-renderer.com/forum/index.php?action=dlattach;topic=22625.0;attach=94498;image)

Title: Re: Autobump concerns and 2d displacement ala vray
Post by: Jpjapers on 2018-11-30, 16:44:23
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
Title: Re: Autobump concerns and 2d displacement ala vray
Post by: Juraj Talcik on 2018-11-30, 19:20:29
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.
Title: Re: Autobump concerns and 2d displacement ala vray
Post by: Fluss on 2018-11-30, 20:35:43
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.

Sure, here it is :

Corona - no displacement 4235MB RAM - With displacement 7250MB RAM - 1px with autobump on

(https://corona-renderer.com/forum/index.php?action=dlattach;topic=22625.0;attach=94505;image)
Title: Re: Autobump concerns and 2d displacement ala vray
Post by: romullus on 2018-11-30, 21:15:56
So, where's the problem? Corona displacement looks as good as its competitors and uses half amount of RAM compared to Vray. The only part where it sucks (sometimes), is that it cuts subdivision behind a camera very dramatically - look at the reflection in mirror ball.
Title: Re: Autobump concerns and 2d displacement ala vray
Post by: Fluss on 2018-11-30, 22:22:11
So, where's the problem? Corona displacement looks as good as its competitors and uses half amount of RAM compared to Vray. The only part where it sucks (sometimes), is that it cuts subdivision behind a camera very dramatically - look at the reflection in mirror ball.

Well just rotate the camera a bit and there you go :

Fstorm - still 3.65 GB - no reflection issue
(https://corona-renderer.com/forum/index.php?action=dlattach;topic=22625.0;attach=94507;image)

Corona - 17GB
(https://corona-renderer.com/forum/index.php?action=dlattach;topic=22625.0;attach=94509;image)

What's more, the Fstorm displacement is view-independent. In the current configuration, Corona displacement is view-dependent and that does not work well with animation. To get rid of those issues, you have to set it up in world space unit. Try to reach the same quality with these settings and your computer will explode.

Here is a (fancy) example i found, I'd kill to get that quality displacement in my animations :

Title: Re: Autobump concerns and 2d displacement ala vray
Post by: Juraj Talcik on 2018-11-30, 22:43:20
I don't want to post it as example, but I will describe my use-case scenario when subdivision method like Corona fails. Microdetail at high-resolution.

I have chair, that is made of transparent fabric, thickness of 1-2mm. Therefore my detail needs be in sub <1mm (To illustrate how that measure in px, if my fabric was up-close to camera, I would need 1px disp detail...at 8k resolution which are my finals).
The more surface area I have (I need multiple chairs of course), I can very quickly get into 100GB for of displacement in memory alone. (No, bump&normal is not replacement, I am talking complex 3D dimension pattern that alters the visual behavior).

With 2D disp from Vray, or the one from F-Storm (or even geopattern), my memory stops rising the moment the algorithm displaces the first tile of the texture map. And then it doesn't matter what resolution I render, or how much surface my displacement cover.

That sort of algorithm is absolutely superior in every regard. Corona is ok, usable only if I use it for crude way, like displace bunch of ground with mud&rocks, where I never need more than 2-3px detail. The moment I need both super-detail and high-surface coverage, it fails.


Quote
To get rid of those issues, you have to set it up in world space unit. Try to reach the same quality with these settings and your computer will explode.

Yep, absolutely this.
Title: Re: Autobump concerns and 2d displacement ala vray
Post by: maru on 2018-12-01, 19:40:33
Just a random question - what happens in fstorm/other if you use some procedural map for displacement on a large area, so that it cannot be just one tile repeated multiple times?
Title: Re: Autobump concerns and 2d displacement ala vray
Post by: Fluss on 2018-12-02, 13:59:34
Just a random question - what happens in fstorm/other if you use some procedural map for displacement on a large area, so that it cannot be just one tile repeated multiple times?

Fstorm only support bitmaps so I can't tell. For Vray 2D displacement, as raytracing is computed in texture space, it needs proper UV to work. So you can't use object/world XYZ coordinates for displacement. It is still usable tho, by using explicit map channel. Set a planar UVW map to fit the size of the plane (no tiling) and adjust the size and iterations of the noise map as desired. Then, the amount of details is directly driven by the resolution set in the displacement modifier (RAM usage will increase accordingly). See the example below :

Vray - 1k sampling - 2 100MB RAM
(https://corona-renderer.com/forum/index.php?action=dlattach;topic=22625.0;attach=94534;image)

Vray - 16k sampling - 21 400MB RAM
(https://corona-renderer.com/forum/index.php?action=dlattach;topic=22625.0;attach=94536;image)
Title: Re: Autobump concerns and 2d displacement ala vray
Post by: Juraj Talcik on 2018-12-02, 15:59:39
They have some obvious negatives as universal solution but are still superior when they apply. This is why I don't believe in single solution and it was smart for Vray to retain both algorithms.

Vray2D only takes memory as high as the bitmap footprint so 16k+ maps will obviously no be its forte. But let it sample 4k maps and it will reign supreme.
The algorithm is therefore highly suitable for tiling maps, because there the memory is minimal and the effect is sharpest.

I believe Corona shouldn't so strictly adhere to single option, most users will not be confused by being given two clearly explained solutions. Just like EdgeMap already has two modes of operation, so can displacement.

And I don't think this is anyhow terrible to be solved in UI, one checkbox could be in advanced options inside CoronaMTL, another checkbox would be added to modifier. Really simple,non-confusing additions. Those who don't want to touch it, won't need to. No hassle, no confusion, everyone wins.
Title: Re: Autobump concerns and 2d displacement ala vray
Post by: dcode on 2018-12-03, 13:54:24
They have some obvious negatives as universal solution but are still superior when they apply. This is why I don't believe in single solution and it was smart for Vray to retain both algorithms.

Vray2D only takes memory as high as the bitmap footprint so 16k+ maps will obviously no be its forte. But let it sample 4k maps and it will reign supreme.
The algorithm is therefore highly suitable for tiling maps, because there the memory is minimal and the effect is sharpest.

I believe Corona shouldn't so strictly adhere to single option, most users will not be confused by being given two clearly explained solutions. Just like EdgeMap already has two modes of operation, so can displacement.

And I don't think this is anyhow terrible to be solved in UI, one checkbox could be in advanced options inside CoronaMTL, another checkbox would be added to modifier. Really simple,non-confusing additions. Those who don't want to touch it, won't need to. No hassle, no confusion, everyone wins.

Indeed, I adore Fstorm displacement until I want to get creative with procedural work and then you come to a stop. So having two displacement options for two different purposes makes perfect sense ie. Bitmap Disp (so called 2D) and Procedural Disp. Voila :) So easy to say when you are not a programmer hahaha.
Title: Re: Autobump concerns and 2d displacement ala vray
Post by: kosso_olli on 2018-12-05, 10:48:03
wow theres so much more high frequency detail in fstorm!!

Well, setting blur to 0.5 for displacement in V-Ray is a terrible idea... No wonder it looks softer compared to FStorm.
Title: Re: Autobump concerns and 2d displacement ala vray
Post by: Fluss on 2018-12-05, 10:54:00
wow theres so much more high frequency detail in fstorm!!

Well, setting blur to 0.5 for displacement in V-Ray is a terrible idea... No wonder it looks softer compared to FStorm.

If you look at the settings, Vray displacement blur is set to 0.001, only diffuse and gloss are set to 0.5. I could have lowered it a bit more tho
Title: Re: Autobump concerns and 2d displacement ala vray
Post by: lupaz on 2018-12-07, 16:49:10
(No, bump&normal is not replacement, I am talking complex 3D dimension pattern that alters the visual behavior).

This I don't get. Let's say bump and/or normal maps were to be much better in corona, with micro detail, would't that be a good option?
Maybe it's easier for the corona team to improve this and not displacement necessarily.
The autobump idea in my opinion fails because bump in corona is not very good either.
But yes, displacement should be usable at 1px of resolution. And unfortunately I can only use that resolution in simple scenes.

Title: Re: Autobump concerns and 2d displacement ala vray
Post by: Juraj Talcik on 2018-12-08, 15:12:19
I believe not really because I frequently work with patterns that are very visible up-close as well as need to cover considerable surface area. I don't want to post much of that stuff here due to work reasons but it's prime example for Geopattern.

Bump&Normal, no matter how well done, are still quite short of the real deal for many occasions. Photorealistic renderer shouldn't rely on effects made to save memory&performance, it should have tools to provide absolute realism for every occasion. Right now Corona doesn't have that when it comes to micro-detail. Both 2D displacement and geo-pattern would be tremendous additions.
Title: Re: Autobump concerns and 2d displacement ala vray
Post by: Jpjapers on 2018-12-09, 00:22:35
I believe not really because I frequently work with patterns that are very visible up-close as well as need to cover considerable surface area. I don't want to post much of that stuff here due to work reasons but it's prime example for Geopattern.

Bump&Normal, no matter how well done, are still quite short of the real deal for many occasions. Photorealistic renderer shouldn't rely on effects made to save memory&performance, it should have tools to provide absolute realism for every occasion. Right now Corona doesn't have that when it comes to micro-detail. Both 2D displacement and geo-pattern would be tremendous additions.

Geopattern is by a long shot the biggest thing im jealous of fstorm users for. Fabrics alone are just so much better IMHO with that level of control.
Title: Re: Autobump concerns and 2d displacement ala vray
Post by: matsu on 2019-02-11, 16:31:20
I was really stoked when I read about the displacement improvements that came with the latest version. However, I've tried it out some now, and I'm actually bit disappointed.

I'm sure the latest fix has improved the look of irregular disp-maps, but the way I use it (in archviz) is to produce pronounced details on buildings, which are almost always sharp and regular.
In the image I use the same basic brick texture, but on some parts of the facade, the architect wants a striped pattern. Since the meshing of the displaced areas is triangulated and random, the edges get very jagged, and the shadows look... really bad.
This kind of thing worked a lot better with Vray's 2D displacement. (I don't have any experience from using Fstorm.)

In the image, the displacement is set to Screen 1.5px, but many times, the scenes are too large and too complex to use such a small value. (I'd love to be able to increase it per object, or even use Screen and World on different objects!)


A possible solution I could think of is that Corona considers the displacement map's contrast to decide where to add triangles. So, if there's a sharp contrast between the pixels in the map, Corona adds more triangles, and vice versa. Adaptive meshing based on dispmap contrast. Edit: Did a quick test, and noticed it already does this. Added another image where I used a checker map to displace a tessellated cube. It shows the problem, and how displacement tries to solve the issue. 1px displacement in this render, but artefacts remain no matter the setting.
One could also think that the meshing uses some kind of "loop detection" to follow the shapes of the dispmap.


Another thing I been thinking about is the option to use "displacement LOD" - an option to skip displacement if the the displaced geometry is too small (too far away). Right now, displacement can really destroy the look of displaced mesh that is too far away from the camera.
The only solution now is using different materials for different shots of your scene, but is just too cumbersome to be a practical solution, and using World scale just isn't an option due to memory use.


I really hope you keep working on this. For me, it's one of the areas where Corona is lacking compared to other renderers.
Title: Re: Autobump concerns and 2d displacement ala vray
Post by: maru on 2019-02-13, 12:03:44

(I'd love to be able to increase it per object, or even use Screen and World on different objects!)


You can do it with Corona Displacement Modifier. It is per-object displacement, with various settings.

Note that you can also disable the autobump feature in the development/experimental stuff rollout - https://coronarenderer.freshdesk.com/support/solutions/articles/12000021288

By the way, we have this thread logged in our task tracker, and we will definitely think how displacement can be improved.