The NxOgre 1.0 development thread

As 0.4 and 0.5 approaches. I have been working on a seperate branch of NxOgre completely and totally rewritten from the ground up.

So far these are the planned features:

(Written 17-Sept-06)

- Removal of the world class.
- Redefining the Scene class which is part Ogre SceneManager and part instance container.
- Creation of the "Simulation" class, which represents the NxScene completely.
- Multiple scene's that share the same SceneManager, are called "SubSimulations"
- Seperate physics thread (no more framelistener)
- Blueprint system everywhere.
- Full support of the YAML fileformat; from scene serialisation to creating bodies/scenes through YAML in C++.
- The "instance" class which is the most concrete physical world presence in the PhysX, rigid bodies to fluids inherit this class.
- Although the Body class exists, it is renamed to RigidBody and discouraged, and now replaced with the matter system.
- Matter system: Fluids, Solids and Gasses. Matter can change phase of matter, such as cubes made of ice can change to solid depending on temperature and/or sources.
- Surface system: replacing material system, which handles materials and basic contacts (i.e. Lithium touching water, would cause a reaction)

And much more.

Also: When it becomes a little more feature rich, I'll add it to the CVS for you real cutting edge beta testers.

Day 3

As World is now removed. I wondered where would I launch the SDK; At the creation of the first Scene, or manually by the user? I decided on Both. But for default start it before "int main()" via a clever Hack. My reason for this is, since Scene is part SceneManager NxOgre would be launched earlier in the code.

The other question is when to shut it down, I've decided on the last Scene destroyed or turning off auto-shutdown via a flag.

So this is the code to open and shutdown the Scene/SceneManager and fiddle around with it:


SceneManager *mSceneMgr;
Scene* mScene;

mSceneMgr = mScene = Scene::create("George the SceneManager");

mScene->getRootSceneNode()->createSceneNode(....);
mSceneMgr->getRootSceneNode()->createSceneNode(....);
mScene->createMatter(...);
mSceneMgr->createMatter(...) // Can't do that, it's a SceneManager!


Scene::destroy(mScene);



It's so crazy, it might just work!

- Seperate physics thread (no more framelistener)


Oh holy cow, it'd be fantastic!

But one thing makes me curious:
What are your plans to assure threadsafety?


- Full support of the YAML fileformat; from scene serialisation to creating bodies/scenes through YAML in C++.

What about NxuStream? What are the major advantages of YAML? First time I heard about it.

- Seperate physics thread (no more framelistener)


Oh holy cow, it'd be fantastic!

But one thing makes me curious:
What are your plans to assure threadsafety?


No idea yet, infact I haven't even implemented a test framelistener yet, but I've been looking how PhysX handles threads via the thread tutorial so it would probably be based off that.


- Full support of the YAML fileformat; from scene serialisation to creating bodies/scenes through YAML in C++.

What about NxuStream? What are the major advantages of YAML? First time I heard about it.

YAML is a text based file format. Which will be able to describe a scene or any part of NxOgre. These can be read in via a blueprint.load(), or even saved via blueprint.save(), You can even write them manually in C++ via blueprint.fromYAMLString()

This would be a typical YAML file describing a scene:

- Scene: George the Scene
- rigidbody: Penguin
mesh: pengiun.mesh
shape:
cube: 1 m³
density: 10 KG
pose: 0,4,0
- staticbody:
mesh: fortress.mesh
pose: 0


Or describing a suface using Yaml in C++

- Surface: Water
Temperatures:
Solid: ABZ
Liquid: 0
Gas: 100
Angular Friction: 0.2
Bounce: 0.1


There will be a secondary optional format called "MDL" which is a binary file of a rigid body loaded in as a blueprint. It can contain a single or many RBs.

The MDL file will contain for each RB:
- The Collision model
- The Ogre Mesh with it's material, textures and shaders.
- Any Extra NxOgre information; States, Dampening, Gravity, etc.

Ok, then YAML does nearly the same as NxuStream (which is by the way open source too).

May be it'd be worth taking a closer look, because the PhysX stuff (scene, actors etc. ) is already implemented in it.

For an actor it looks like this:

__templateActor_0:
globalPose (RowMajor + Trans): 1.000000,0.000000,0.000000 0.000000,1.000000,0.000000 0.000000,0.000000,1.000000 1016.000000,6.000000,999.000000
hasBody: true
mBody.massLocalPose (RowMajor + Trans): 1.000000,0.000000,0.000000 0.000000,1.000000,0.000000 0.000000,0.000000,1.000000 0.000000,0.000000,0.000000
mBody.massSpaceInertia: 39.321918 16.985712 39.321918
mBody.mass: 53.080353
mBody.linearVelocity: 0.000000 0.000000 0.000000
mBody.angularVelocity: 0.000000 0.000000 0.000000
mBody.wakeUpCounter: 0.400000
mBody.linearDamping: 0.000000
mBody.angularDamping: 0.050000
mBody.maxAngularVelocity: 7.000000
mBody.CCDMotionThreshold: 0.000000
mBody.flags: 384
mBody.sleepLinearVelocity: 0.010000
mBody.sleepAngularVelocity: 0.010000
mBody.solverIterationCount: 4
density: 0.000000
group: 5
flags: 0
userData: 0
name: __templateActor_0
numShapes: 1
Shape_0:
type: 3
localPose (RowMajor + Trans): 1.000000,0.000000,0.000000 0.000000,1.000000,0.000000 0.000000,0.000000,1.000000 0.000000,0.000000,0.000000
group: 0
materialIndex: 0
mass: -1.000000
density: 1.000000
skinWidth: 0.001000
shapeFlags: 8
mCCDSkeleton: -1
groupsMask.bits0: 0
groupsMask.bits1: 0
groupsMask.bits2: 0
groupsMask.bits3: 0
name: null
radius: 0.800000
height: 1.040000
flags: 0

Woah, the syntax is pretty close to YAML. I shall investigate.

- Seperate physics thread (no more framelistener)


Oh holy cow, it'd be fantastic!

But one thing makes me curious:
What are your plans to assure threadsafety?


No idea yet, infact I haven't even implemented a test framelistener yet, but I've been looking how PhysX handles threads via the thread tutorial so it would probably be based off that.

I don't really know how they do it in the PhysX tutorial and am too lazy right now to look it up, BUT I would definitely vote for a multiplatform thread implementation like BOOST provides it. Have a look here: http://www.boost.org/doc/html/threads.html

As more and more dual and soon quad core processors are becoming the new standard, it makes totally sense to use that extra (core)power for physics. Looking foward...

Good work betajaen!

Thanks for boost.thread, I was looking at it last night actually.

Looking into PhysX more, I discovered that by default a scene is actually threaded; Which runs along side Ogre which then NxOgre polls for the latest position of the NxActor's.

Reading into the tutorials a bit more you can tell it not to, and just calculate when called, or run in your own threaded system. I tried the first and didn't get an FPS hit at all, but I'm going to try my own threaded system probably using boost.threads. This thread would be the PhysX calculate thread which hopefully can utilitise dual-processors, and update the body positions. This way I can get away without using a framelistener.

I suppose the only big problem is moving the scenenodes of the bodies at the right time without breaking anything.