Deformer Evaluation Inaccuracy

Become a member of the CGSociety

Connect, Share, and Learn with our Large Growing CG Art Community. It's Free!

 
Thread Tools Search this Thread Display Modes
  09 September 2015
Deformer Evaluation Inaccuracy

Hi,

during a production last year we encountered an issue with Mayas Skin Cluster. As we worked on real world scale, where 1 unit is 1 centimeter, our characters moved across a environment approx. 1 kilometer length. This means our characters moved 500 meters to each side of the worlds origin. So far there was nothing obvious going on the scene. But at one point we had to troubleshoot some jittering with simulated nHair curves.

And we found out: The farer we move away from the world origin, the more inaccurat the evaluation of the meshes vertices gets.

I know that you have to be careful, when it comes to scene scale and decimal places. But I always thought, that this is a general issue with the evaluation in 3D space.

But when created a testscene, I found out, that direct transformation value change with constains are not a problem at all. No matter how far an object is placed or moved from the world center, there are always enough decimal places for a correct evaluation. However, if there is either a lattice, cluster, skin cluster or wrap moving a meshes shape components away from world center, decimal places are cut off relatively to the unit by 10. So, I assume that the effect will be always occur, becoming more and more visilble, with increasing distance to world center.

In our case an object moved by a skin cluster 400 meters away from the world center caused an inacuracy by a few milimeters, which results in vertices jittering. When I did an extreme displacement of 1000000 meters (which is a lot, I know), there are no more decimal places left and the vertices will always be moved by 1 unit, which results in extreme vertex jitterung. The effect not only shows up be moving the object, it also happened, when navigating the camera. A third Display evaluation inaccuray then was added by Viewport 2.0. (Which is less a problem, while not rendered, a least with renderers, thar are not the Hardware Renderer)

Getting back to our hair problem: I think the inaccuracy in deformer evaluation could cause the hair curves to jitter. This also could be an issue when rendering a velocity pass. Because often, when a non moving object (no camera movement either) still had velocity changes, which resulted in a slightly blurred image.

Long Story short:
If anyone has similar stuff happen, or some workaround or knows something about this issue, i appreciate the help. This happen more or less with cluster, skin cluster, lattice and wrap deformers but not with translation values. I did not tested the wire, shrinkwrap, wrinkle or jiggle deformer.

Test Scene Results:

See attachment

Thanks
Georg & Peter
Attached Images
File Type: jpg deformerIssue2.jpg (60.5 KB, 32 views)
 
  09 September 2015
Its a known limitation, but there is a possible workaround.

http://knowledge.autodesk.com/suppo...rom-origin.html

David
__________________
http://www.djx.com.au
 
  09 September 2015
We had this problem some time ago. With large distances, it is always a good idea to try to keep the interesting parts at the origin. Renderers will start to behave strange as well if objects are too far away from the origin that's the reason why Arnold offers a way to move the whole scene around in rendering. In one of our last movies, we had a strange problem with inaccurate renderings and really high rendertimes. Then we moved everything to the origin, and everything worked fine again.
__________________
www.renderwiki.com - www.openmaya.net
 
  09 September 2015
Originally Posted by djx: Its a known limitation, but there is a possible workaround.

http://knowledge.autodesk.com/suppo...rom-origin.html

David


I just tried this on a simple rig... and it appears to work fine. Skin cluster performed without visible jittering even when the rig was moved 800000000 units (cm) away from the origin. Pretty cool!

Such distances might be tough on any render engine though. So it's still best to avoid very large offsets.
__________________
"Even the Christmas vacation will be darkened by New Zealand scripts…"
~ J.R.R. Tolkien, The Letters of J.R.R. Tolkien, Letter 34
 
  09 September 2015
A common solution is to have the deformation layer of your rig do it's work locally, then connect your shapes nodes to another mesh that's just "carried" along with the world layer of the rig.
(similar to the workaround, but your deformations happen on origin from the get go, and you're going to save yourself all the extra MultMat nodes. As well as having it work well for other deformers).

I think this was first discussed by Eric Miller in a really old DVD (can't remember which). But it still works really well.
__________________
ollarin.com
 
  09 September 2015
Hi guys,

thank you for your help. I really appreciate it. We are going to have a deeper look at all the information and give the noted workarounds a try.

By the way, it's not just a Maya issue, we did discover similar problems in Houdini as well. It seems to be a common optimization.

Originally Posted by haggi: We had this problem some time ago. With large distances, it is always a good idea to try to keep the interesting parts at the origin. Renderers will start to behave strange as well if objects are too far away from the origin that's the reason why Arnold offers a way to move the whole scene around in rendering. In one of our last movies, we had a strange problem with inaccurate renderings and really high rendertimes. Then we moved everything to the origin, and everything worked fine again.

Thank you, Haggi. Yes, we definitely plan changing the workflow by keeping deformed assets as much as possible close to the origin. Quite interesting and good to know that the rendering generally will do trouble too. Did you already used Arnold in your last movie?

Peter
 
  09 September 2015
Originally Posted by Ollarin: I think this was first discussed by Eric Miller in a really old DVD (can't remember which). But it still works really well.

I'm a little curious which DVD this is. Any chance figuring something out?
 
  09 September 2015
Originally Posted by DutchDimension: Such distances might be tough on any render engine though. So it's still best to avoid very large offsets.

Not on Appleseed. I saw a test where the famous raptor model was moved several billion units away from the camera and it worked fine
__________________
www.renderwiki.com - www.openmaya.net
 
  09 September 2015
Originally Posted by ThePistolPete: Thank you, Haggi. Yes, we definitely plan changing the workflow by keeping deformed assets as much as possible close to the origin. Quite interesting and good to know that the rendering generally will do trouble too. Did you already used Arnold in your last movie?
Peter


No, not yet.
__________________
www.renderwiki.com - www.openmaya.net
 
  09 September 2015
Originally Posted by haggi: No, not yet.

What render engine did you used then? I'm just a little curious because, we are maybe going to switch our renderer too and trying to figuring out if Arnold is the right choice for our upcoming project.
 
  09 September 2015
Originally Posted by ThePistolPete: I'm a little curious which DVD this is. Any chance figuring something out?

Not yet, I tried taking a quick look around and couldn't find it. I'll keep searching though.

If you'd like I could explain it in more detail, if it didn't make sense?
__________________
ollarin.com
 
  09 September 2015
Originally Posted by ThePistolPete: What render engine did you used then? I'm just a little curious because, we are maybe going to switch our renderer too and trying to figuring out if Arnold is the right choice for our upcoming project.


We had these heavy problems with mentalray. But in our Arnold tests, we had other distance based problems. But Arnold is a good choice in any case.
__________________
www.renderwiki.com - www.openmaya.net
 
  09 September 2015
Originally Posted by Ollarin: If you'd like I could explain it in more detail, if it didn't make sense?


Sure, if you don't mind. Thank you in advance.

Originally Posted by haggi: We had these heavy problems with mentalray. But in our Arnold tests, we had other distance based problems. But Arnold is a good choice in any case.

Thank you haggi for this deeper insight. I hope we will do a test run for Arnold soon too.

Peter
 
  09 September 2015
Hey Pete,

Just posted up a quick blog post regarding this here (Sorry, not really promoting anything. Figured I should start writing about some of the stuff I've learned in a central location. Starting with this. :P)
__________________
ollarin.com
 
reply share thread



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
CGSociety
Society of Digital Artists
www.cgsociety.org

Powered by vBulletin
Copyright ©2000 - 2006,
Jelsoft Enterprises Ltd.
Minimize Ads
Forum Jump
Miscellaneous

All times are GMT. The time now is 11:42 AM.


Powered by vBulletin
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.