Game Development Community

hmmm bug in trigger.cpp.....

by Vince Gee · in Torque 3D Professional · 04/16/2013 (6:00 am) · 1 replies

Ok, so I'm working through some final stuff for dnt and happened across the Polyhedron.

Can someone explain why...

When it serializes it writes the data out as 
char* retBuf = Con::getReturnBuffer(1024);
   dSprintf(retBuf, 1023, "%7.7f %7.7f %7.7f %7.7f %7.7f %7.7f %7.7f %7.7f %7.7f %7.7f %7.7f %7.7f",
            origin.x, origin.y, origin.z,
            vecs[0].x, vecs[0].y, vecs[0].z,
            vecs[2].x, vecs[2].y, vecs[2].z,
            vecs[1].x, vecs[1].y, vecs[1].z);

   return retBuf;
}

Yet, when it reads it back in it uses
U32 numArgs = dSscanf(argv[0], "%g %g %g %g %g %g %g %g %g %g %g %g",
                         &origin.x, &origin.y, &origin.z,
                         &vecs[0].x, &vecs[0].y, &vecs[0].z,
                         &vecs[1].x, &vecs[1].y, &vecs[1].z,
                         &vecs[2].x, &vecs[2].y, &vecs[2].z);

Thus swaping vec[1] with vect[2]?

NextNext Thread
PrevPrevious Thread
More from Torque 3D Professional


Associate David Wyand
Gnometech Inc.
#1
04/16/2013 (8:25 am)
This is from T3D/trigger.cpp, correct? It really depends on how the vecs[] arrays are being used. If you look at the surrounding code in ConsoleGetType() and ConsoleSetType(), the Point3F vecs[] arrays are being built from, or are building Polyhedrons. So it really depends on how that deconstruction or construction code is set up.

So the question is: Does the reading and writing of a trigger's polyhedron actually change the polyhedron's winding order? If the answer is "yes" then it is indeed a bug and it would be great if you could submit a fix in a Pull Request.

- Dave