Hi Eric,
thank you for your answer regarding the rendering updates. Asynchronous
updates are definitely the way to go.
Currently I am wondering how to asure that input interrupts from mouse and
keyboard interaction are channeled into the ProcessInputs() method from
the proposed rendering pipeline from the official documentation:
void RenderCallback()
{
if (gScene && !bPause)
{
GetPhysicsResults();
ProcessInputs();
StartPhysics();
}
// ...
}
Did you already find a solution for this problem?
Could you please give me some details how you update the position and
rotation of OpenSG objects?
Right now I am experimenting with distance joints for picking and moving
objects around the scene. I am using the PhysX raycast report to determine
the appropriate picking points.
Take care
Philipp
Am 05.06.2007, 18:00 Uhr, schrieb Eric Maslowski <[EMAIL PROTECTED]>:
> 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
