Points Are Not Exactly At Zero

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
  2 Weeks Ago
Points Are Not Exactly At Zero

Hi,

While sitting here waiting for the SuperBowl to start. I decided to crank out some code that checked point positions. And I came across something unusual.
When I model things I often use the loop tool to select the middle points of a mesh and set them all to X=0 in the AM field as a method to line them up. But apparently C4D does not set them at X=0 100% of the time.
It turns out that setting points to 0.0 in the AM doesn't always set them exactly at 0.0. And you can't tell when it happens because the AM displays them as 0.0 even when they aren't.
When I looked for points at X= 0.0 with code. It couldn't find some of them. And I was like what the heck is going on here? How can this be?
It led me on quite the goose chase trying to figure out why my code wasn't working until I eventually found where the problem was coming from.
I had to add a small code routine into my project in order to find and fix any of those stray points.

I'm still using R13 . So I'm wondering if this was a known problem with older versions of C4D and was fixed in newer versions?
Has anyone ever seen this before?

-ScottA
__________________
My Gallery
 
  2 Weeks Ago
I don't know if my "problem" is similar to yours but... In R18 you can sometimes cut a line but once you commit it it will change its position randomly. Even more than that, the snap tool sometimes just doesn't snap exactly to the vertex you'd like - at least not when you are selecting / cutting. Once you commit the action then it works.

Odd stuff.
 
  2 Weeks Ago
I think I know how this happened.
I'm fairly certain that this happened from using importers/exporters.
I don't know if it's from the ones in C4D, or some other program. I'm leaning towards MudBox being the source of where this is coming from.

The big problem is there's no way to see them in any of the C4D fields. So it's very easy to not even know that there's errors in the positions. And C4D probably won't throw any errors about it.
Or it might throw an error at you in only some use cases. And you won't know where the error is coming from....OUCH!
The only way to see them is by writing code to check them. And not everyone knows how to do that. Or even thinks to do it. Why would they?
So I guess this is a heads up warning for people who use importers/exporters that you might want to check the integrity of your files if you do that kind of thing. Even if they don't throw errors.
It might bite you one day like it did me.

The bad position values end with e-16. This is very common value to get from an exporter. I've seen it a lot when using the FBX SDK and also when writing .bvh files.
If the position value is very small. Something like 0.000001 for example. An exporter will very commonly write a value ending in e-16 for it rather than the actual value.

Here's a basic script example that checks the point positions:
import c4d
def main():
 
 obj = doc.GetActiveObject()
 if obj is None or obj.GetType() != c4d.Opolygon:
 return False
 
 pntCount = obj.GetPointCount() 
 pnts = obj.GetAllPoints() 
 PointS = obj.GetPointS()
 
 for i in xrange(pntCount):

 #This prints the vector values with the x == 0 even if they are not perfectly at 0.0
 #This is also what gets displayed in the C4D AM fields..OUCH!
 print pnts[i]

 #This prints the actual true values for the X positions
 #Some have e-16 values and I don't know how they got there. Possibly from using importers/exporters
 #But more importantly. You cannot get this value by looking at anything in C4D
 #You can only see these values by writing code...OUCH!
 print pnts[i].x

 #This fails to select all of the points C4D tells you are set at X=0
 #Because some of them have e-16 X values
 if pnts[i].x == 0:
 PointS.Select(i)
 
 obj.Message(c4d.MSG_UPDATE) 
 c4d.EventAdd() 
 
if __name__=='__main__':
 main()




And here's a simple script that will fix the points if they aren't perfectly at X=0 just in case anyone needs it:
#Sometimes points are listed as being at x=0 in the C4D fields. But they are actually a very tiny bit off
#This script will find those hard to find points and set their x positions to zero

import c4d
def main(): 
 
 obj = doc.GetActiveObject()
 if obj.GetType() != c4d.Opolygon: return False
 
 c4d.gui.SetMousePointer(c4d.MOUSE_BUSY) 
 
 pntCount = obj.GetPointCount() 
 pnts = obj.GetAllPoints() 
 PointS = obj.GetPointS() 
 
 #Loop through all of the mesh points
 for i in xrange(pntCount):
 
 if pnts[i].x < 0.0 and pnts[i].x > -0.01:
 #PointS.Select(i)
 p = pnts[i]
 obj.SetPoint(i, c4d.Vector(0, p.y, p.z)) 
 obj.Message(c4d.MSG_UPDATE) 
 if pnts[i].x > 0.0 and pnts[i].x < 0.01:
 #PointS.Select(i) 
 p = pnts[i] 
 obj.SetPoint(i, c4d.Vector(0, p.y, p.z))
 obj.Message(c4d.MSG_UPDATE) 
 
 obj.Message(c4d.MSG_UPDATE)
 c4d.gui.SetMousePointer(c4d.MOUSE_NORMAL)   
 c4d.EventAdd() 
 
if __name__=='__main__':
 main()



-ScottA
__________________
My Gallery

Last edited by Scott Ayers : 2 Weeks Ago at 04:05 PM.
 
  2 Weeks Ago
When working with floating point values, you will always have some imprecision and testing for == 0.0 will most likely fail if you did any operation with the value. Are we talking 0.05 wrong or 0.000000000001 wrong? The later is to be expected and will be the case in every program you ever used.
Regards
Fritz
 
  2 Weeks Ago
The problem is that the values in C4D were displaying as 0.0 when they were actually floating point values ending with e-16 values.
Which are the typical kind of value that some exporters default to if it encounters a FP value that's too long .
I'm guessing the mesh points were off in MudBox by roughly 0.00000001 or something really tiny value like that. And the MB exporter converted them to e-16 values.
Then when the mesh was opened in C4D. I guess C4D is set up to default to 0.0 whenever it gets fed these kinds of e-16 values.

When I used the point loop selection tool on them. And set the X size to 0 to try and fix them and line them up. C4D wouldn't fix them.
Then when I used code to get the point vector positions. It still didn't give me the actual correct values. It printed this: Vector(0, value, value). But the actual X value was something like this: -200000100e-16.
It wasn't until I pulled out each individual vector value that I got the actual true values for them. That's when I finally realized where the problem was.

In short.
If you load files from other programs into C4D. It's very possible that there's some point values in it that might have gotten converted into ending in e-16.
So It's probably a good idea to check your files for this. By using a C4D script. Or whatever file readers you like to use.
I'm personally going to check every single file for this from now on.

-ScottA
__________________
My Gallery
 
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:56 AM.


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