Hi Philipp, We basically recreate our PhysX primitives in the correct coordinate system at load time. Since most of our PhysX objects come from 3D Studio Max, we might just modify the exporter to handle this. For now, we basically just rebuild them with the correct size and orientation. We rely on our artists to do most of the sizing work in Max.
Updates are very tricky. We're using VRJuggler so things are even more complex in relation to updates since we need to synchronize the data across our cluster combined with other application data. Ideally, you want to: 1) grab results & apply to objects 2) start next sim step 3) draw objects from #1 This will set it up in an asynchronous way allowing the PhysX to do it's calculations while the scene draws. This is great for complex scenes or if you have a PhysX card. It also prevents stalls in the CPU/GPU/PPU pipelines. We're currently fighting a lot with getting the clustering working in VRJuggler, so our development with PhysX stopped after RigidBodies and Joints, but will continue once the clustering is resolved. E. --- Eric Maslowski Research Computer Specialist University of Michigan 3D Lab Autodesk 3D Studio Max Certified Trainer email: [EMAIL PROTECTED] office: 734-615-9699 mobile: 734-730-9904 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Philipp Roßberger Sent: Tuesday, June 05, 2007 04:11 To: [email protected] Subject: Re: [Opensg-users] Ageia PhysX integration Hi Eric, good to know, that there is somebody out there who is trying the same as I do ;-) I spent the last days with some raycast experiments to get PhysX and OpenSG work together. It seems just like you said: PhysX objects are twice the size as their OpenSG counterparts. Beside the scaling problems, I am struggling with some other problems. Would be great to hear how you solved them. 1)Position and rotation of OpenSG objects. At the moment I am doing this to transfer the position and rotation of objects from PhysX to OpenSG: NxVec3 boxPos = box->getGlobalPosition(); NxQuat boxRot = box->getGlobalOrientationQuat(); boxMat.setTransform(Vec3f(-boxPos.x, boxPos.z, boxPos.y), Quaternion(Vec3f (-boxRot.x, boxRot.z, boxRot.y), boxRot.w)); Do I have to use box->getCMassGlobalPosition() and box->getCMassGlobalOrientation() instead? How do you transform your OpenSG primitives? 2) What the best place to update the graphical representation? Is the following method invocation order ok? Where do you this? void display(void) { // Update physics objects if (gScene) { GetPhysicsResults(); ProcessInputs(); StartPhysics(); } UpdateOpenSG(); // Render scene objects mgr->redraw(); } I am looking forward to your reply! Philipp Am 04.06.2007, 16:15 Uhr, schrieb Eric Maslowski <[EMAIL PROTECTED]>: > Hi there. We're working on integrating PhysX with OpenSG as well. Sorry > if > some of this has already been covered... > > 1) We are currently converting the coordinate system of PhysX objects at > load-time and setting up the PhysX sim to operate in OpenSG's coordinate > system. We may modify the exporter for 3D Studio Max so that it can do > this > conversion for us at export, but the current solution is working well so > far. The "quick start integration guide" has a thorough example of > converting from one coordinate system to another when using NxStream. > > 2) PhysX specifies it's primitives from their center point in halves. > So, if > you want a 1m cube, you would specify the distance from the center of the > box. Think like you're defining the radius of a sphere. It's a little > annoying, especially when defining the height of a capsule since it grows >> from the center, but at least it's consistent. When creating objects via > code, we just take the values specified by the user (1m) and halve them > for > Ageia. > > Hope this helps some. > > Cheers > > E. > > --- > Eric Maslowski > Research Computer Specialist > University of Michigan 3D Lab > > Autodesk 3D Studio Max Certified Trainer > > email: [EMAIL PROTECTED] > office: 734-615-9699 > mobile: 734-730-9904 > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Philipp > Roßberger > Sent: Friday, June 01, 2007 08:09 > To: [email protected] > Subject: Re: [Opensg-users] Ageia PhysX integration > > Am 01.06.2007, 13:31 Uhr, schrieb Marcus Lindblom <[EMAIL PROTECTED]>: > >> Philipp Roßberger wrote: >>> Am 30.05.2007, 14:12 Uhr, schrieb Marcus Lindblom <[EMAIL PROTECTED]>: >>> >>> >>>> Philipp Roßberger wrote: >>>> >>>>> 1) Coordinate system differences >>>>> >>>>> OpenSG and PhysX coordinate systems' use different axis orientations. >>>>> While the coordinate system in OpenSG looks like this >>>>> >>>>> z >>>>> ^ y >>>>> | ^ >>>>> | / >>>>> -----> x >>>>> >>>>> >>>>> the coordinate system in PhysX looks like this: >>>>> >>>>> y >>>>> ^ z >>>>> | ^ >>>>> | / >>>>> x <----- >>>>> >>>> Both are righthand system. Does this PhysX care about the "front" of >>>> an >>>> object? (OpenSG does for the camera & lights, but little else, I >>>> think) >>>> >>> So far I didn't find anything in PhysX where an object front is >>> defined. >>> >> Ok. Maybe it's up or right? Or if PhysX doesn't care about that, what is >> the actual problem? >> >> What I'm getting at, is, that you might be able to use OpenSG >> coordinates within PhysX? (i.e. just set the gravity to be in -z). > > > I got no problem at this point. I just wrote about the differences in > hope > that other people trying the same will recognize the difference earlier > than I did ;-) > >>>> In any case, it's not hard to transform back-and-forth between these, >>>> is >>>> it? >>>> >>> Not really. Here a short example, that shows how I use values computed >>> by >>> the PhysX engine to transform OpenSG objects: >>> >>> //PhysX part >>> NxVec3 pointerPos = pointer->getGlobalPosition(); >>> NxQuat pointerRot = pointer->getGlobalOrientationQuat(); >>> >>> //OpenSG part >>> mPointer.setTranslate(-pointerPos.x, pointerPos.z, pointerPos.y); >>> mPointer.setTransform(Vec3f(-pointerPos.x, pointerPos.z, pointerPos.y), >>> Quaternion(Vec3f (-pointerRot.x, pointerRot.z, pointerRot.y), >>> pointerRot.w)); >>> >> Either that, or you could define a matrix which rotates from one system >> to the other: >> >> static OSG::Matrix msPhysXtoOpenSGmtx(...); >> >> mPointer.setTransform(PointerPos, Quaternion(PointerRot)); >> mPointer.mult(msPhysXtoOpenSGmtx); // or multLeft() perhaps >> >> It's a basis change matrix, so either build it from two rotation >> matrices (it looks like it could be done that way) or set the bases >> directly. I.e. set each of the first three columns to each x,y,z vector >> of the other coordinate system, or vice versa (I can never remember >> which way it goes. :) >> >> It's a bit tricky, but you should be able to get it done. Understanding >> transformation matrices well will make your life a lot easier, so read >> up on it if you feel you need it. (I don't know enough either, as you >> can see.) > > Well I think I have to dig deeper into this topic. You are right, it's > much easier to do all this stuff, when you know what you are actually > doing. > >>>>> 2) Object scaling >>>>> >>>>> Objects instantiated in PhysX with default scaling are twice the size >>>>> as >>>>> their OpenSG counterparts. Here an example: >>>>> >>>>> Box in OpenSG | Box in PhysX >>>>> ----------------------------- >>>>> 1,1,1 = 0.5,0.5,0.5 >>>>> >>>>> >>>> Yup. Primitives in OpenSG are unit sized, they do not have >>>> unit-coords. >>>> I don't know which is better actually. :) >>>> >>> PhysX parameters are set up by default assuming 1 unit = 1 meter. I am >>> wondering what would be the best way to make sure, that scaling in >>> OpenSG >>> and PhysX is equal. I was thinking about experimenting with the raycast >>> methods in OpenSG and PhysX. Any better ideas? >>> >> Right. However, OpenSG doens't care about units. So if you want one unit >> to be one meter, that's perfectly ok. (You could have an OpenSG unit be >> one furlong as well, but that's just weird :-) >> >> I think this problem is just a mismatch between the vertex values of >> each library's box-primitives. Without knowing what you are doing in >> detail, these are some ideas: >> >> * Make your own boxes in OpenSG, with correct values. (might be simpler >> & probably faster, if you can do this) >> * Export the OpenSG box to PhysX, as a generic mesh. (avoids any such >> problem, but generic meshes might be slower in PhysX) > > I will go with solution 1) and scale the boxes in OpenSG with correct > values. I just managed to get the raycast reports working in PhysX and > now > make some tests to determine the acutal scaling differences by comparing > the raycast values of OpenSG and PhysX. > > Solution 2) looks a little bit scary to me ;-) > >>> By the way: is there a method in OpenSG that allows you to convert >>> world >>> coordinates into the local coordinate system of an OpenSG body? I need >>> this to create joints between objects. The anchor points of certain >>> joints >>> in PhysX are defined in the local coordinate system of individual >>> bodies. >>> >> Yes. The inverse of the toWorld() transform will do that, i.e: >> >> OSG::Matrix fromWorld; >> node->getToWorld().inverse(fromWorld); >> >> Pnt3f localCoord = fromWorld.mult(worldCoord); >> > > Cool, that's just what I needed. Thanks for your help and your ideas > Marcus! > > >> Cheers >> /Marcus >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by DB2 Express >> Download DB2 Express C - the FREE version of DB2 express and take >> control of your XML. No limits. Just data. Click to get it now. >> http://sourceforge.net/powerbar/db2/ >> _______________________________________________ >> Opensg-users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/opensg-users > > > -- http://www.placemarks.net ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
