Author Topic: Autobump concerns and 2d displacement ala vray  (Read 2872 times)

2018-11-28, 20:14:51

peterguthrie

  • Active Users
  • **
  • Posts: 243
    • View Profile
    • Peter Guthrie Visualisation
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


2018-11-29, 00:53:57
Reply #1

Jpjapers

  • Active Users
  • **
  • Posts: 1221
    • View Profile
I agree 2-4px looks somewhat flatter than the rest here.

2018-11-29, 10:39:43
Reply #2

Juraj Talcik

  • Active Users
  • **
  • Posts: 3755
  • Tinkering away
    • View Profile
    • studio website
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.
talcikdemovicova.com  Website and blog
be.net/jurajtalcik   Our studio Behance portfolio
Instagram   Our studio Instagram, managed by Veronika

2018-11-29, 11:09:14
Reply #3

nkilar

  • Active Users
  • **
  • Posts: 852
    • View Profile
    • My personal website
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.

2018-11-29, 12:06:42
Reply #4

Fluss

  • Active Users
  • **
  • Posts: 435
    • View Profile
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 :


2018-11-29, 12:30:59
Reply #5

Ondra

  • Administrator
  • Active Users
  • *****
  • Posts: 8904
  • Turning coffee to features since 2009
    • View Profile
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.
Rendering is magic.
Private scene uploader | How to get minidumps for crashed/frozen 3ds Max | Sorry for short replies, brief responses = more time to develop Corona ;)

2018-11-29, 13:01:48
Reply #6

Jpjapers

  • Active Users
  • **
  • Posts: 1221
    • View Profile
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 :)

2018-11-29, 14:24:33
Reply #7

romullus

  • Global Moderator
  • Active Users
  • ****
  • Posts: 6071
  • Let's move this topic, shall we?
    • View Profile
    • My Models
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.
I'm not Corona Team member. Everything i say, is my personal opinion only.

2018-11-29, 15:10:10
Reply #8

Fluss

  • Active Users
  • **
  • Posts: 435
    • View Profile
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


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)

« Last Edit: 2018-11-29, 19:48:12 by Fluss »

2018-11-29, 16:37:24
Reply #9

Fluss

  • Active Users
  • **
  • Posts: 435
    • View Profile
@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?
« Last Edit: 2018-11-29, 21:21:05 by Fluss »

2018-11-29, 23:51:52
Reply #10

dj_buckley

  • Active Users
  • **
  • Posts: 298
    • View Profile
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?

2018-11-30, 09:23:15
Reply #11

TomG

  • Corona Team
  • Active Users
  • ****
  • Posts: 2737
    • View Profile
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.

2018-11-30, 09:44:29
Reply #12

Fluss

  • Active Users
  • **
  • Posts: 435
    • View Profile
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.
« Last Edit: 2018-11-30, 10:09:21 by Fluss »

2018-11-30, 10:33:19
Reply #13

Juraj Talcik

  • Active Users
  • **
  • Posts: 3755
  • Tinkering away
    • View Profile
    • studio website
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.
talcikdemovicova.com  Website and blog
be.net/jurajtalcik   Our studio Behance portfolio
Instagram   Our studio Instagram, managed by Veronika

2018-11-30, 11:03:28
Reply #14

romullus

  • Global Moderator
  • Active Users
  • ****
  • Posts: 6071
  • Let's move this topic, shall we?
    • View Profile
    • My Models
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?
I'm not Corona Team member. Everything i say, is my personal opinion only.