bug in EggVertex ?

Hi.

I’m trying to modify and write some Egg file.

I finally find this strange behaviour:

given an EggPolygon el…

>el.getVertices()
[polySurfaceShape2.verts:118, polySurfaceShape2.verts:99, polySurfaceShape2.verts:101, polySurfaceShape2.verts:121]
>el.getVertices()[0] == el.getVertices()[1]
True
>str(el.getVertices()[0]) == str(el.getVertices()[1])
False

It’s true for an awful lot of vertices. ( about 90%)

Can you show us what they look like?
Can we have the egg you loaded them from?

I suppose:

>el.getVertices()[0].getPos3()
Point3D(2.87054, 1.41183, -14.2688)
>el.getVertices()[1].getPos3()
Point3D(4.77011, -0.0196518, -14.2688)

I found the same case of stuff with all the model that I’ve try, all have been exported with maya.
dl.dropbox.com/u/3519076/yellow_first_floor.egg

>>> from pandac.PandaModules import *
>>> model = EggData()
>>> model.read('yellow_first_floor.egg')
1
>>> node = model.getFirstChild()
>>> node = model.getNextChild()
>>> node
EggTexture phong1SG.tref2
>>> node = model.getNextChild()
>>> node
EggTexture phong1SG.tref1
>>> node = model.getNextChild()
>>> node
EggTexture phong1SG
>>> node = model.getNextChild()
>>> node
EggGroup groundPlane_transform
>>> node = model.getNextChild()
>>> node
EggGroup pCube2
>>> node = model.getNextChild()
>>> node
EggGroup polySurface1
>>> node2 = node.getFirstChild()
>>> node2
EggVertexPool polySurfaceShape2.verts
>>> node2 = node.getNextChild()
>>> node2
EggPolygon
>>> node2.getVertices()
[polySurfaceShape2.verts:86, polySurfaceShape2.verts:79, polySurfaceShape2.verts:80, polySurfaceShape2.verts:92]
>>> node2.getVertices()[0] == node2.getVertices()[1]
True
>>> node2.getVertices()[0].getPos3(), node2.getVertices()[1].getPos3()
(Point3D(5, 0, -14.0077), Point3D(3.00888, 0, -14.0077))

It’s not a bug, it’s simply that when you compare two floating-point numbers, they are allowed to differ a bit, because floating-point numbers are not infinite-precision. So it is expected behavior that (str(i) == str(j)) will not always be the same as (i == j).

Actually, it’s more than that: the EggAttributes class, which EggVertex inherits from, has a special definition of ==, which is designed to compare equivalent attributes as equal. So if two attributes have the same properties, they considered equal, even if they are not actually the same object. This is used internally by the egg library.

It happens that EggVertex doesn’t override this definition, so it inherits it; and you end up comparing two vertices based on their attributes alone, ignoring position. This is arguably a bug. I can check in a fix.

David

I’ll think a difference of (2,0,0) will be enough if that was just a precision problem !

I was suspecting this. Since what I need now is just the identity, comparing the str() works and comparing the pointer

vertex1 is vertex2

should work.

Comparing the pointers may not work, because that’s comparing the pointers of the Python wrapper objects, not the underlying C++ objects. Since you get a new Python wrapper object with each call into C++, it will fail: el.getVertex(0) is not el.getVertex(0). But you can compare v0.this == v1.this for a reliable comparison of the underlying C++ pointers.

David

thank for the info. good to know. For now, I will kept comparing the string then.

If I may ask a question on the subject:

I have parse an egg file an modified it. Then write it on a disk.
Ans then load it using the loader

But is there a solution to load directly from the eggData ?
( a way to do eggData -> NodePath without writing on disk ? )

np = NodePath(loadEggData(myEggData))

David