Displacement Precision Issue MtoA 3.3.0 / 2018.6

[lennart.oberscheidt]

Hey guys,

we just noticed a displacement issue with Mtoa 3.3.0 and Maya 2018.6 which currently is an absolute showstopper for a shot we're working on as it will be severly inconvenient to work-around. Displacement seems to dramatically loose precision with translation of the displaced object in worldspace. Everything seems to be fine at world origin, however as soon as we move the object displacement gets progressively less detailed and introduces severe shading artifacts. We noticed this behaviour in a scene containing several asteroids which are merely moved to roughly world 0,4000,0 units. The bahviour is reproducible with a simple cube and a camera parented to it. The object gets progressively more destroyed the farther it is moved from the origin. Object space tranforms exhibit the same behaviour and this seems to be a world-space issue. Screenshots and file attached.

displacementcubetest.zip

displacementcubetest2.zip

As we're working on a 360° 10.000 frame sequence theres no way for me to conventiently move the object to around world origin as a workaround, and short of baking the displacement into geo half a day of troubleshooting did not present any viable solution. I'm not usually one to cry "bug!" the first time there's an issue, but I'm pretty sure this worked flawlessly before, isn't our fault and might be a pretty serious bug. We're discussing downgrading arnold currently.

Testing was done on Win 10 machines running Maya 2018.6 and arnold 3.3.0. We could not yet test any other system configurations.

Known Problem? Any pointers to a possible solution?

Thanks

Lennart

[Stephen.Blair]

It's the same all the way back to Arnold 5. In fact it gets a little worse when I go back to Arnold 5.2 and older.

I didn't try Arnold 4. Is that the version you were using before?

At 2000000 units from the origin, I think this is a floating point precision problem.

Your best bet may be to offset your scenes back to the origin again for rendering. eg using a locator parent, or with Render Settings > System > Offset Origin

[thiago.ize]

32-bit floats at 200,000 units away have precision at most of roughly 200,000*1e-7 == .002 units. When I print out the y dimensions of the vertices of the black shaded triangles that have been moved out 200,000 units, I get values like: 200000.562, 200000.562, and 200000.578. Notice how two of these vertices are identical and the other one is roughly our minimum 0.002 units away. There simply was not enough precision to represent these tiny triangles at this extreme distance.

Some computations in the renderer are done in object space and those might end up being ok. But other computations are done in world space and these will clearly fail as the above math shows. It's possible we might be able to do something clever to minimize this particular issue, but this problem would still manifest in other areas. As Stephen said, it would be ideal if you can try to keep things located about the origin.

[lennart.oberscheidt]

Just as a follow up to my last post (which for some reason seems to again be awaiting moderation… weird). Having tested the displaced cube in Basic and Wireframe mode, the triangles appear to roughly be where they should be even with the cube at 200.000 units. The problem seems to rather come from the light/shadow computation producing artifacts, and appears similar to the representation of the object during -2 -1 samples. Something seems to be off, even though it might just be a limitation of some of the calculations involved.

By the way: Have you guys noticed that the arnold documentation online links to https://localhost/docs.arnoldrenderer.com/ ? I've noticed this for several weeks now. Removing the localhost from the URL is not much of an issue but still i thought I'd mention it… 😉

[thiago.ize]

The ray-triangle intersection is done in object space, so ignoring shading, what the camera sees should look just about perfect. However, once we need to do more work, such as shading and casting new rays from this far away surface, then these precision problems can start to appear since some of these require some world-space computations.

In fact, the wireframe also shows these issues since if you zoom the camera into the object, so that you can see individual triangles, you'll see some locations where the wireframe gets blurry or otherwise clearly bad, similar to where we have bad shadows.

[lennart.oberscheidt]

Hey guys, thanks for your reply!

As mentioned here https://answers.arnoldrenderer.com/questions/19675/displacement-precision-issues-20186-mtoa-32x-and-... we're aware of float precision and have moved objects back to the origin during long takes before (mental ray, vray, c4d, arnold 4) . The cube at 200.000 is, frankly, an exaggerated example and you're right that we should expect some precision loss. However, we're getting almost as extreme displacement variations at 4000 units off the origin. I've since checked the scene and noticed that several transforms in the newest version of the shot are buffered in groups that have a scale of 15 while the asteroid (in the other thread) itself is scaled 1/15 to keep its world space size. The precision issues of the asteroid as well as the intersection imprecision on the spaceprobe landed on the asteroid (both are previz versions of the asset) seem to come from the fact that they are scaled in object space. Unparenting, scaling and freezing transforms on them leads to more expected results. There are precision artifacts but within acceptable ranges, although more noticable then i would expect at 4000 units for objects 30m large with a camera distance of roughly 0.5 units. I would have expected ray-intersection and displacement to be always computed in worldspace.

A displaced 1x1x1 unit cube for example in Cinema Standard or Physical Renderer at the orgin and moved 200.000 units off the origin does not exhibit any visible shading artifacts (pictures attached).

0,0,0

0,200.000, 0

Of course, both render engines are very different but I did not expect arnold to show such severe artifacts.

What makes me think that there might be something sketchy with our asteroid meshes (or maybe the translation from Maya to Arnold) is the fact that a 0,4000,0 units our asteroid seems to not get subdivided (6 subdivs) during -2 -1 samples in the IPR, but absolutely does a 0,0,0. Both asteroids render fine and seem subdivided at the origin and 4000 units, although at 4000 units off the origin there is a very visible shading difference in specular highlights and shadows, while its actual subdivided resolution seems fine. Or is this some kind of optimization in the IPR that you are doing for displacement at negative Samples?

Anyway, the issue is fixed having moved the scene back to the origin. However, I'm still quite curious on why the precision loss is quite more noticable then in other render engines, where working at 4000 units never posed much of a problem as far as I remember. I could not test arnold 4 yet. Having worked with arnold for a few years now, I never noticed such severe issues before, but granted, most projects usually are more or less centered around the origin. Unfortunately I won't be able to do much testing the next couple of days but I'd still be curious about the huge difference in precision between for example C4D (or other engines) and Arnold. Just out of curiosity and to avoid problems in the future.

Cheers,

Lennart

[lennart.oberscheidt]

Hey guys, thanks for your reply!

As mentioned here https://answers.arnoldrenderer.com/questions/19675/displacement-precision-issues-20186-mtoa-32x-and-... we're aware of float precision and have moved objects back to the origin during long takes before (mental ray, vray, c4d, arnold 4) . The cube at 200.000 is, frankly, an exaggerated example and you're right that we should expect some precision loss. However, we're getting almost as extreme displacement variations at 4000 units off the origin. I've since checked the scene and noticed that several transforms in the newest version of the shot are buffered in groups that have a scale of 15 while the asteroid (in the other thread) itself is scaled 1/15 to keep its world space size. The precision issues of the asteroid as well as the intersection imprecision on the spaceprobe landed on the asteroid (both are previz versions of the asset) seem to come from the fact that they are scaled in object space. Unparenting, scaling and freezing transforms on them leads to more expected results. There are precision artifacts but within acceptable ranges, although more noticable then i would expect at 4000 units for objects 30m large with a camera distance of roughly 0.5 units. I would have expected ray-intersection and displacement to be always computed in worldspace.

A displaced 1x1x1 unit cube for example in Cinema Standard or Physical Renderer at the orgin and moved 200.000 units off the origin does not exhibit any visible shading artifacts (pictures attached).

0,0,0

0,200.000, 0

Of course, both render engines are very different but I did not expect arnold to show such severe artifacts.

What makes me think that there might be something sketchy with our asteroid meshes (or maybe the translation from Maya to Arnold) is the fact that a 0,4000,0 units our asteroid seems to not get subdivided (6 subdivs) during -2 -1 samples in the IPR, but absolutely does a 0,0,0. Both asteroids render fine and seem subdivided at the origin and 4000 units, although at 4000 units off the origin there is a very visible shading difference in specular highlights and shadows, while its actual subdivided resolution seems fine. Or is this some kind of optimization in the IPR that you are doing for displacement at negative Samples?

Anyway, the issue is fixed having moved the scene back to the origin. However, I'm still quite curious on why the precision loss is quite more noticable then in other render engines, where working at 4000 units never posed much of a problem as far as I remember. I could not test arnold 4 yet. Having worked with arnold for a few years now, I never noticed such severe issues before, but granted, most projects usually are more or less centered around the origin. Unfortunately I won't be able to do much testing the next couple of days but I'd still be curious about the huge difference in precision between for example C4D (or other engines) and Arnold. Just out of curiosity and to avoid problems in the future.

Cheers,

Lennart

[Anonymous]

Could this world space precision issue cause banding in a z depth renderpass?

[thiago.ize]

I have some hopefully good news: Arnold 6.0.1, which was released today, should have fixed this precision issue you reported. Please try it out and let us know if you still notice issues with this particular problem. As I mentioned before, there are other world-space effects that still will fail when far from the origin, but hopefully Arnold 6.0.1 will be good enough for your use cases.

And thanks for reporting this problem to us, along with the simple repro you included -- it definitely helped!

[743398708]

是的，DEEP也将受到影响