The quartonian specifies the rotation around a given axis. The x y z components specify the vector of the axis, not the rotation around each of those axes. the W component is the amount of rotation around the given axis.
So yes, you'll need to convert the quart to absolute axis rotations.
Tokamak integration
-
Julian
enigmatic: Quaternions aren't simple to understand, yet they are easy to use. They contain an axis and a rotation about it in a more compact form than a matrix. You can find several articles about them on the net (e.g.: http://www.gamedev.net/reference/progra ... /page3.asp). You don't even have to write a quat class, because some people have done it for you, just search the net for it a bit and I'm sure you're gonna find one.
Julian: Merging these engines only requires some new scene nodes derived from ISceneNode, containing the physics initialization and other stuff (like mass, joints, etc). The only problem is that the data types are different (like neM4 vs core::matrix). But you need only a few lines (6..10) of code to pass the values - so it's not that big deal
License: Tokamak too can be used freely in commercial products. I haven't read the license in detail, so I don't know whether it could be distributed in the Irr package...
Back to integration, the class I'm writing will be capable of handling arbitrary geometries, which are stored in Lua scripts. I can process the scripts, so right now I have to write an interactive editor to create some geometry to load Anyone interested write me 
Gonosz
Julian: Merging these engines only requires some new scene nodes derived from ISceneNode, containing the physics initialization and other stuff (like mass, joints, etc). The only problem is that the data types are different (like neM4 vs core::matrix). But you need only a few lines (6..10) of code to pass the values - so it's not that big deal
License: Tokamak too can be used freely in commercial products. I haven't read the license in detail, so I don't know whether it could be distributed in the Irr package...
Back to integration, the class I'm writing will be capable of handling arbitrary geometries, which are stored in Lua scripts. I can process the scripts, so right now I have to write an interactive editor to create some geometry to load
Anyone interested write me Gonosz
-
Guest
That's interesting. I do hope someone will make such a package. It would be a shame to have several people working on the same thing don't you think?Gonosz wrote:Julian: Merging these engines only requires some new scene nodes derived from ISceneNode, containing the physics initialization and other stuff (like mass, joints, etc). The only problem is that the data types are different (like neM4 vs core::matrix). But you need only a few lines (6..10) of code to pass the values - so it's not that big deal
License: Tokamak too can be used freely in commercial products. I haven't read the license in detail, so I don't know whether it could be distributed in the Irr package...
You're right.
But we have another problem. With a couple of classes we can create any type of geometry on the fly, or load from disk. That's okay, if there aren't so many objects. But what happens, if someone wants to load a .BSP map in Irr ? As far as I know, Tokamak can't handle BSP trees, and hundreds of thousands of poly's will certanly slow the physics down... a possible solution could be passing only those portions of the map to Tokamak, which have objects near them. If anyone has a better idea, let me know!
TTYL,
Gonosz
But we have another problem. With a couple of classes we can create any type of geometry on the fly, or load from disk. That's okay, if there aren't so many objects. But what happens, if someone wants to load a .BSP map in Irr ? As far as I know, Tokamak can't handle BSP trees, and hundreds of thousands of poly's will certanly slow the physics down... a possible solution could be passing only those portions of the map to Tokamak, which have objects near them. If anyone has a better idea, let me know!
TTYL,
Gonosz