question to Matt about vector displacement

Started by digitalguru, July 15, 2016, 11:24:35 AM

Previous topic - Next topic

digitalguru

Hi Matt,

I wanted to render out a vector displacement map for the terrain for the tutorial I'd been making.

I had two Otrthographic cameras setup, one that covered the whole terrain - 8000 ortho width and another to sample a smaller region at 500 ortho width.

The 8000 version looks good, but the smaller region vector map is very aliased when using for displacement in Maya

[attach=1]

tried a few options, moving the camera closer to terrain, higher detail (4!), and various resolutions (up to 8k)

widening the ortho width and it gets better

I know the OpenExr output is 16bit and the aliasing is worse on smoother areas of the terrain (where you'd need 32bit float to sample gradient) but is there a limit on how small an area you can sample with the Displacement shader to vector?


Matt

#1
If there's a limit to how small you can go, I'm not sure what that would be. I'm surprised that there's stepping from the 16-bit EXR map. Can you load it into Nuke and see whether there's stepping in the raw data? It might be a Maya displacement problem.

Are you exporting displacement values 1:1, i.e. 1 metre of displacement = 1 in the EXR?

Matt
Just because milk is white doesn't mean that clouds are made of milk.

digitalguru

#2
Hi Matt,

Yes, I can see the stepping very clearly in Nuke - see attached:
[attach=1]

(graded it a bit to clamp the values into an image)

Tried it both in Anrold and loading as displacement map in Mudbox - the effect is the same.

Dsiplacement value are always 1:1 - I never need to play with that, just make the plane to be displaced the same size as the region rendered out of TG.

I exported a .ter file of the same area using Heightfield generate and converted it into a 32bit with TerraConv and it looks ok compared to the VDM, which is probably the way to go in 90% of cases, but of course then you lose the advantage of vector displacements.
Terraconv:
[attach=2]

VDM:
[attach=3]

JUst thinking laterally, is there a way I could scale up a small region to a larger size temporarily just to export the VDM? i.e if I had a region  I liked 500 ortho width square - expand it out to say 10000 just to export a vector map?

Oshyan

Try this with the new 32 bit EXR output when you get a chance...

- Oshyan

digitalguru

hey Oshyan,

Thanks for the info, that's great news, though I must confess I haven't bitten the bullet yet and upgraded to Terragen 4...

I guess the 32bit Exr ouput also applies to Render elements? Would be an advantage in some of the geometric elements like depth world position etc?

Oshyan

Yes, precisely, 32 bit render elements and that can be helpful for depth, etc.

- Oshyan

digitalguru

#6
QuoteTry this with the new 32 bit EXR output when you get a chance...

Probably old news for TG4 users, but just had the chance to test this out with 32bit exr and fixes the problem...
Original Terragen render
[attachimg=1]

Vector Displacement rendered in Maya/Arnold with 16bit exr
[attachimg=2]

Vector Displacement rendered in Maya/Arnold with 32bit exr
[attachimg=3]

In previous tests trying to squeeze some more resolution out of vector displacement in Terragen 3 - noticed a small area (300m square) can render vector displacement just fine so long as the general level is very low (close to "sea level" or Y value)...
Rendered in Maya/Arnold with 16bit vector displacement map
[attachimg=4]

but raising the whole displacement up (in this case - 1000m ) and the stair stepping appears when rendering a VDM at 16bit:
Rendered in Maya/Arnold with 16bit vector displacement map
[attachimg=5]

and goes away completely at 32bit: (rendered in Maya/Arnold)
[attachimg=6]

It looks like distance from the base level of the planet (the distance the blue node displacement to vector is testing against) results in less floating point precision (revealed more in a 16bit map) and is exacerbated by the ortho width of the area being sampled?

TG4 32bit output improves this enormously, but would be interested if Matt has any insights!

Matt

Nice results here.

The difference in precision that you saw between values close to 0 and those very far from 0 is to be expected with floating point numbers. From the Wikipedia article here:

Quote
A floating-point system can be used to represent, with a fixed number of digits, numbers of different orders of magnitude: e.g. the distance between galaxies or the diameter of an atomic nucleus can be expressed with the same unit of length. The result of this dynamic range is that the numbers that can be represented are not uniformly spaced; the difference between two consecutive representable numbers grows with the chosen scale.

I don't think the ortho width should have any effect on this. However, if your pixels are spaced further apart you are likely to have larger differences in the values between adjacent pixels, and these large differences will actually help you to hide the lack of precision per pixel, as long as the target renderer has enough precision when interpolating the pixels when performing displacement. (One would hope the renderer interpolates using at least 32-bit floats, regardless of whether the input is 16-bit or 32-bit).

Matt

Just because milk is white doesn't mean that clouds are made of milk.

digitalguru

QuoteHowever, if your pixels are spaced further apart you are likely to have larger differences in the values between adjacent pixels, and these large differences will actually help you to hide the lack of precision per pixel

Yes, I think that was what I was seeing in the example that started this thread, and makes sense, as does the floating point accuracy as you get further away from the planet.