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
