Discussion for NxOgre 0.6 and 0.7

**Split from the April fools thread**


Roughly these will be the features for 0.6:

- Thermodynamics (Heat).
- Fake water (using triggers).
- Gas (non-movable, using triggers).
- Weather effects, rain, wind, etc.
- Soft bodies, (won't be a prefab though).
- Fragmenting shapes.
- Stages (if I push it back).
- Chemistry System (see next reply). Each shape is made roughly from one element say lithium, if it falls into some water it'll react and move around violently. Combine this with gas, or heat and it can be quite powerful, however I really need to get out my chemistry school books for this! This would be pretty much an extension of the state system for this to work, however as states is already implemented, it's just writing state rules.


After that, 0.7 will be just bug fixes and new tutorials, 0.8 will be then declared as stable.

I'm just thinking how heat could be a pretty much an amazing thing if it could be properly implemented.

Basically, it would need a super-body class Matter:- With a temperature, and points for when it's a solid, liquid and gas.

Gas; Would require any bodies to be deleted then turned into particles.
Fluids; Would require any bodies to be deleted, and turned into some sort of liquid system, perhaps soft bodies mixed with particles.
Solid; Would be just a body, any liquids or gases would deleted.

However, transitions between the states would be difficult (but not impossible).

Then we have elements, which define the melting, and evaporation points for it, then any rules for when it hits another piece of matter.

It would be a damn nice effect if we could just have flying balls of ice suddenly liquify when it hits a flame.

[Edit]

Now, your gonna be a mover and shaker with these new implementations. Seriously. I won't even start rambling on about the ideas that are accumulating in my head, but your basic example of solid ice hitting some fire and turning into liquid is prime.

I have one question/suggestion: Ragdoll->Animation blending... Something you don't see too much, you know when you can shoot a guy, he falls down, but then gets back up- but when he fell, it wasn't an animation, it was pure ragdoll. Then when he gets back up from the ragdoll state, it blends back to animations. I think I need to read up more on PhysX, but perhaps you know if this is possible. Would be another badass feature if you ask me...

Though, what you have so far would be an awesome upgrade! I can't wait

Agreed, it won't be a wrapper anymore, but a physics and chemistry framework based upon PhysX.

And I think you've hit the nail on the head there with the ragdoll animations, you'd just pre-calculate the next frame, then transition the state between a solid ice cube, to a liquified flying mess in the next frame or two. So really it would be two bodies, a frozen solid mass suspended in space, then a moving liquid, all you would need to do is move the vertices on the entities to suit the moving liquid.

With the ragdoll/animation blending, I was actually referring to skeletal animations, or rather character animation blending. So I can't really take credit for that idea, that was all you You think that would work? I mean, I know it could work- but would the performance and visual quality be that good? I think to get good performance out of fluids, at least with the solution stated, you'd need a good GPU, or would have to sacrifice visual quality- like you were saying in your diagram, it would be more like jelly than water. I've been hunting down some articles, papers, etc on real-time fluid simulation solvers (RTFSS) and have come across some pretty interesting reads. I'll start posting some of them, maybe I should send you a private message with them, rather than post here? Or would here be ok?

I was wondering- if we could find a RTFSS library/sdk, would it be feasible to write a wrapper for this? It could be very lite, and would it be possible to link it to nxOgre? This way, we can have performance and quality. Damn the 2.4 SDK for not being public .

If this was all possible, then your chemistry addition to nxOgre could possibly become more powerful- or rather, perform quite alot better. I know we can do fluids with what you have, but it would be at the cost of quality, using workarounds due to the fact the PhysX SDK doesn't quite pave the way for us. Which is the only reason I bring up 3rd party libraries. I totally understand (and I think I've already solved my own questions here) if you want to keep nxOgre totally... what would be the word? In-house? Lone ranger? I think you get my drift.

My only feelings on your plans for the new nxOgre is that they rock... I just don't want to see you having to settle for less or hack things in, when there could be a way to fully achieve the quality and power that your seeking. I mean, it would be awesome to see a cube hit some fire and turn to water, but not a cube hit some fire and turn to putty or jelly . Now, I'm not complaining- these new features would be far more than a majority of other physics engines/wrappers/libraries make available, and we would still be able to do some amazing things with them.

Perhaps though, we could be happy with this, get to know it's power... Then, hopefully... Maybe... When 0.7 is on the horizon, the 2.4 PhysX SDK would be made public domain? Then, you could really smash some faces in, with style... With real fluidic detail

Another possible path, which I'm surprised didn't pop in my head right away, was 'smoothed particle hydrodynamics' or 'SPH'. You've already got physical particle systems working, so this might just be a good one. Though as I read back over things here, it seems this was the path you were going anyhow! If this is the case, then I'm guessing the whole chemistry system would be using particles? Aside from solids of course... I'm guessing creating an SPH system would be a lotta work for you

Thing with SPH is, every paper I've read on it, that has images, has all the particles as basic blobs... I'm trying to understand how it would actually look like water (or whatever liquid solution)... Shaders perhaps? A shader that, when all the particles are combined it would act somewhat like a metaball, making all 'connected' particles look as one. Then you wouldn't be able to tell it was a bunch of particles. Ooh... gases could have a 'heat-haze' effect .

Anyhow, here is one cool fluid demo/source I found:
http://www.ss.iij4u.or.jp/~amada/fluid/

Sorry I went on a rantiful-rage again

No, you've hit me on the head with this one - Metaballs.

Problem is when you introduce your own fluid system, it could be a one-way collision system so that the fluid would not, or have a simplified collision model with PhysX.

Perhaps, we are going the wrong route with particles, but have it has a dynamic convex trigger (assuming triggers can use convex), re-define the trigger say every n frames for updated motion forces, etc. But then again it would only be suited for large volumes of water.

Smaller ones would be particles/meta-balls, which then we'd just use the particle system for edges of the water, and if any body is in between or touches those particles would do something funky.

We need to do some investigation with meta balls, because this can be applied to the gas system too.

The way PhysX does liquids I believe is through voxels, which is similar to the particle/meta-ball system so it could be a good starter.

Now only if I had a PC I could try these wonderful things out on.

Okay, I see where your going here- Large bodies of water such as oceans/lakes could be dynamic convex triggers, and smaller things such as ponds could be particle/meta-balls. I'm mighty curious to see some meta-ball physics action, even something simple. Did you look at that demo I linked to? Sadly there is no documentation on the controls, and I had to figure them out one my own-


Space starts the simulation (also 'splatters' the water, or removes the container)

If you hold RMB and drag, you can move the fluid's container.

Holding Shift+LMB and moving up/down allows you to tip the fluid's container.


Now, this demo looks like it's using meta-balls... And it looks gooood. Most fluid demos I've seen, have the fluid as one whole entity, but this demo actually has seperating blobs that mush back into the rest. This is what makes me think it's using meta-balls. The more I think about this, and using this method for fluids + nxOgre... I keep drooling on myself. And my keyboard.

Get your computer fixed!!!

EDIT:
In case you can't run the demo, here are some screenshots:

Can't see it. Computer completely broken. Using Macintosh.

Ponds would be would be dynamic convex triggers too, Oceans and Lakes would be fixed triggers though because of the size.

Puddles, flying water and zero-g water would be metaballs/particles.

And I'll get it fixed if I have a cash injection of £500.

Alright, I've been working on how the interface will work and what changes will be needed.

Some of these changes are in the NxOgre source now, but won't be commited to the CVS after the release of 0.5

Anyway, so let's say we want to create an iron girder, the non-matter way:-


myGirder = mScene->createBody("girder", "girder.mesh", new cubeShape(0.15,8,0.15), Elements::Iron.density, Vector3(0,4,0));


Or through the matter way:


myGirder = mScene->createMatter("girder", Elements::Iron, "girder.mesh", new cubeShape(0.15,8,0.15), Vector3(0,4,0));


Ooh, I like that... Since all the elements will be defined, with properties such as density... Those will correlate with other properties such as friction, bounce, etc. That's sweet. See I already find a need for some sort of mesh exporter specifically tailored to nxOgre; having to define all the matter properties in a complex scene could get pretty tedious. Wait, I take that back- there are many ways to simplify this process now that I think of it...

So now, with this system, rather than materials we could define a prefab's matter properties, which would give it it's weight (based on size * matter compostion?) and other various properties. When you create your world, set your gravity and such, your all set. Each object you'd add would be ready to go, and if you wanted to tweak anything, you could do it by way of material or matter settings... Oh man I think I just wet my pants again

Keep the details/ideas rolling in! I'm writing up a post on my forums about the game engine/first game project I want to work on, and this is keeping me entertained inbetween

Oh, I never though about bounce and friction. I have a several molecules in there, known as complex elements; Water, Wood, Petrol, etc.

But adding bounce and friction, especially to the more complex elements makes my mind go crazy!

You can if you wish want to create you're own element/molecules, as long as you write the code for any rules it may have (it may hate water, or cause a nuclear explosion when it touches iron). However you must be a little confused about mass, as it's always calculated when the body is created from the density of the body and it's shape.

But, I'm thinking that an element should be defined per shape rather than body, because a body would be made out of more than one type of elements; a Plastic chair with metal legs for example.

But I think you need a change of pants again and if I post anymore soon you'll run out!

Think , but it is my own thougts that it could be good to finish ( more documented and cleaned code ) the blueprint vehicle, and the '.dot scene nx Ogre' systems.
I don't say that the water, chemistry system are not good, but i think that before extending the capabilities of NxOgre it could be wiseful to finish say at 110% the existing features

Those will be finished in 0.5 and 0.5.1, these things discussed will be added in 0.6.

So i will wait for 0.5.1, and light a candle for you


btw, Do you have little, even microscopic idea of the release date ??

Probably a few weeks after I get my new computer.

These weather effects sounds very very very well!!! but, will framerate slow down too much?

Not sure, rain would just be "slow ray casting" but would only be implemented if I can change the material indexes of a mesh Shape at runtime, so there wouldn't be too much of a loss there.

Snow would require the particle system, which would probably slow down the frame rate as 100's of actors are being calculated where they fall.

Then, those effects sound better .

WOW, I leave this project a few days and boom, what a changes.

Batajaen, congratulations. I really want to try the chemistry set.


Bye!

Well no changes yet, this is all theory and C++ prototyping.

However, I have been working on the code again from scratch (don't worry 0.5 is all safe and un-touched!) using TextMate on the Mac.

But I've come up with some things:

- The "Matter" class, is an all in one solid/liquid/gas body which changes to what ever phase of matter depending on temperature, think of it as an super-body. Matter can be created on the fly, or you can create a blueprint and create many at once. Not all matter does need to change it's state of matter, but the matter object will be slowly replacing the body class.

- The "Surface" class, which replaces the material class which is a mixture of the surface properties and the element.

- No more passing on densities per body, it's get's itself more accurately from the element.

- Elements, are basically what the matter are made out of, NxOgre supports every element known so far and some other complicated things such as Plastics, Woods, Glass even carbon nanotubes. Not only it contains the densities, boiling point and melting point temperatures, but also simplified reactions i.e. Hydrogen coming in contact of Oxygen and fire, as Elements are basically an extension of the states system it's easy to implement!

- States will need to become more intelligent and know when to automagically create contact pairs, as elements are states too they will need to do such things through surfaces so that basic chemical reactions can happen (hydrogen+oxygen to water,etc.) as well as other things, such as bridges giving way after intense heat, etc.

From a code point of view it'll be a little more in depth and will require some more lines, this is all theory so it'll change.

Let's create a bunch of iron girders, that can melt.



mWorld = new world(mRoot);
mScene = world->createScene("Main");
mScene->hasGravity();
mScene->hasFloor();
mScene->setTemperature(20.0f celsius);
mScene->setAtmosphere(elements::Air, 100);

Iron = mScene->createSurface("Iron_Girder", elements::Iron, 0, 0.3, 0.4);

IronGirder = mScene->createMatterBlueprint("IronGirder", Iron, "girder.mesh", "liquid_iron", "gas_iron", new shapes::cube(15cm,2,15cm));


for (int i=0;i < 30;i++) {
mScene->createMatter("Girder" + StringConverter::toString(i), IronGirder, Vector3(i,1,0));
}


Again, all theory and prototyping

Alrighty.

I was going to draw a UML class diagram to help me work with, but it's more effort to do that than prototype the class in C++ itself.

So I present the header files for 0.6

http://p.betajaen.com/0.6/

But there are so many changes in there, that any NxOgre program will need to be upgraded, even if it is as simple as capitalising each class name.

Another thing that is interesting that the materials system has been scrapped and reinvented into Surfaces and Volumes, which are half materials and half the elements system.

Bodies may be split into 3 (regular, soft and static) and put into the "simple" namespace.

Instance is a new super-class for every instance of a SceneNode/NxActor combo with some helpers, so it's handy for people who want to expand onto NxOgre with their applications.

The states system has been improved, and the rules for states for triggers and contacts have been moved onto the states themselves.

And there is a few more in there.


[Secret Ninja Fake Edit]

This is more or less the hierarchy of NxOgre 0.6, World to Scene(s) to Stages(s) to Instances of Matter, Bodies, Raycasters, Triggers, and so on.

The image would be a lot better, but I can only have 20 objects on a page with the OmniGraffle Demo

Well now... Very interesting and exciting! I like the change from materials to surfaces/volumes. Obviously not the biggest change, but I like none the less.

I see that we will be able to set the element of the atmosphere; This will make for interesting scenes indeed. I'm thinking someone would be able to make a space sim, have the interior of a big cruiser equalized with an atmosphere of oxygen, with the cold exterior of space being completely void of oxygen- thus, we cold have a reaction that could tear a ship apart if, say, a window were to be broken?

With elements, I was wondering if they will be actually 'real' in the sense that we would have some way to visualize them? Perhaps in a debug mode? Or, say, you had a sci-fi game where you could wear some goggles to see invisible elements as specific color signatures. Some sort of visual debugger would be very useful in setting up scenes that make use of gaseous elements.

I see a nice future for NxOgre, first thing that comes to mind is the fact that all 'bodies' will be making the change to matter- this screams totally realistic physics to me. Having everything in a scene be comprised of realistic matter and elements will be very cool, and very powerful.

Well now... Very interesting and exciting! I like the change from materials to surfaces/volumes. Obviously not the biggest change, but I like none the less.


I like it too, it makes so much more sense this way too.


I see that we will be able to set the element of the atmosphere; This will make for interesting scenes indeed. I'm thinking someone would be able to make a space sim, have the interior of a big cruiser equalized with an atmosphere of oxygen, with the cold exterior of space being completely void of oxygen- thus, we cold have a reaction that could tear a ship apart if, say, a window were to be broken?


I'd be wetting my pants if I could of something like that. I assume the implementation would be via states and insane forces implemented by a custom state machine, infact I never thought about pressure, I just assumed that the atmosphere would be a simple shape volume.

But ripping the ship apart, my god. It would be an insane amount of matter and breakable joint combinations. It defiantly can be done but if I could pull it off, I expect to be Knighted by the Queen.


With elements, I was wondering if they will be actually 'real' in the sense that we would have some way to visualize them? Perhaps in a debug mode? Or, say, you had a sci-fi game where you could wear some goggles to see invisible elements as specific color signatures. Some sort of visual debugger would be very useful in setting up scenes that make use of gaseous elements.


No, as with NxOgre from the beginning the visualisations is all up to the User and Ogre. Maybe in debug mode, but as PhysX has nothing to do with the Chemistry system, I'd have to create my own debug system to replace it.


I see a nice future for NxOgre, first thing that comes to mind is the fact that all 'bodies' will be making the change to matter- this screams totally realistic physics to me. Having everything in a scene be comprised of realistic matter and elements will be very cool, and very powerful.

Well not all bodies, for legacy and memory reasons the body class will still exist which is still handy for things such as static objects, or objects that would never melt or turn into a gas; Wood for example.

But it is encouraged for all dynamic objects to do so, even if they don't melt or evaporate just purely for semantics.

But ripping the ship apart, my god. It would be an insane amount of matter and breakable joint combinations. It defiantly can be done but if I could pull it off, I expect to be Knighted by the Queen.


I'm sure you've played a good classic known as "Soldier of Fortune"? Both 1 and 2. They used what they dubbed the "Gore" engine. Basically models were made up of a bunch of pieces, and when you shot say, a baddies ear, the side of his face would fly off. Particle effects followed, spraying blood out of that area.

I would think something similar to this would do the job quite well, where you could make a ship comprised of many parts that could be ripped off or blown away. Now, the ship itself wouldn't have to be a physics object, but once it got blown up for example, the parts that fly off would become physical objects. Partical trails for debris and smoke and flames. As per the performance hit of this 'simple' task, who knows. I'm sure there is a very neat and tidy way to achieve it.

Now as far as actually using the pressure and atmosphere to do this, I guess you could just fake it. No one would know the difference really anyways.


Well not all bodies, for legacy and memory reasons the body class will still exist which is still handy for things such as static objects, or objects that would never melt or turn into a gas; Wood for example.


Heres an idea; When wood catches fire and is engulfed in flame, you could have it disappear after time (make it look good with smoke and mirrors - no pun intended ) then create a particle system of 'ashes'. Just an idea, not sure how easy this would be. I'm assuming its a menial task though.

I would think something similar to this would do the job quite well, where you could make a ship comprised of many parts that could be ripped off or blown away. Now, the ship itself wouldn't have to be a physics object, but once it got blown up for example, the parts that fly off would become physical objects. Partical trails for debris and smoke and flames. As per the performance hit of this 'simple' task, who knows. I'm sure there is a very neat and tidy way to achieve it.


That is pretty much general easy-way how to do it. A second way would to generate a special model for fracture points, stengths/weaknesses, areas for collapse, even surfaces per polygons both a mesh and physics model at the same time. Something I won't do however, but I'd be prepared to kill for the code though.


Now as far as actually using the pressure and atmosphere to do this, I guess you could just fake it. No one would know the difference really anyways.


It is better to fake it. Simulating gasses moving between atmospheres would so be overkill, and your processor would crawl to a halt anyway.



Heres an idea; When wood catches fire and is engulfed in flame, you could have it disappear after time (make it look good with smoke and mirrors - no pun intended ) then create a particle system of 'ashes'. Just an idea, not sure how easy this would be. I'm assuming its a menial task though.

Very easy to implement via the states system, and how you do through Ogre I'd assume is what you said above.

Very easy to implement via the states system, and how you do through Ogre I'd assume is what you said above.


I should have assumed, even with my lack of experience, that the states could accomplish this task.

On a somewhat side note, I read in another post on the main forums that the PhysX 2.4 SDK was to be publically release in June. This is good news- and I think it will be awesome for future editions of NxOgre! Perhaps by then you'll have your machine running again too.

Excellent news, and I hope I have my computer soon. However it's my birthday in 2 weeks time so I shall ask for money for any relatives who want to contribute to the Betajaen's 24th birthday fund!

In news related to this as such. I have started some (really really basic) work on my own Physics Engine, purely for the things we mentioned above. It's sort of top secret at the moment, however NxOgre will be a trial to get what we want in 0.6, then my Physics Engine to optimise it rather working around PhysX.

We shall see though.

Well happy 24th man! I wish you luck on the aquisition of a new computer

So you say your working on a new physics engine eh... Well now, thats interesting indeed. And this new physics engine will be working alongside PhysX/NxOgre? They need to make an emote just for me, :wetspants:

It's called Cake, based on nothing and it's so abstract it can work without Ogre, or OpenGL or DirectX. (Seriously).

I was going to post more about how it works, but I'll leave you to wonder for a while. But I'm learning lots of new things all about simulating Physics as I'm doing it, and it gives me more appreication to Aegia, and all the other Physics developers of what pain they went through.

But I think you need get a :wetspants: emoticon when I post more about it

I'll just break the ice, or rather de-virginize this little emote real fast, because your last post is plenty deserving:

Oh god, you actually made or found one.

Perhaps you can persuade Sinbad some how to add it to the Emoticon selection?

Ha-ha, yeah I actually made one yesterday just for NxOgre posts . I'll send a note to Sinbad sometime and see what he says.

Now... Just out of curiousity, what is driving you to write a new physics engine? If I were more adept at coding, and better educated on physics, I would write a physics engine for the main purpose of making things "easier". I wouldn't just write a physics engine itself, but tools... Or rather an IDE if you will, for editing various physics objects/characters/vehicles. Here are some of my ideas (just rambling here, perhaps you'll fetch a few good ideas):

* The physics engine would be capable of both per-vertex and per-pixel collision/detection.

* Physics simulations would have a sort of "LOD", which can be scaled. This could be useful for many, many things.

~Lights up a smoke and thinks more in-depth~

* Static, dynamic, character, and vehicle physics would all be seperate... Hmmm, basically classes I guess. Though each would be easily changed seperate from the others, and the others would not be harmed. Perhaps a dll for each class of physics. I dunno, not the greatest programmer .

* The IDE/Editor would have seperate modules or rather editing windows to handle various things. For example, the vehicle editing would be activated by clicking on a button. Once in the vehicle editing interface, you can edit existing vehicles or create a new one. You can define a main body model, which will be shown in a 3D preview window. Then, you can add wheels, or other parts onto the vehicle (perhaps parts than can be blown off, etc.). You would also be able to define things such as speed for the "main" vehicle options, then for the wheels (as an example) define friction, etc. After you have a completed vehicle, you could click "preview" and drive the vehicle around on an infinite plane- perhaps have a few different types of "terrain" to test it on actually. I believe the Battlefield 2 mod kit has something similar, though I haven't gotten to check that out yet. The same sort of functionality could be applied to the other "classes" of physical objects.

Yeah, I could go on for hours about this but I'll spare myself and others the pain. I'd end up repeating myself more than once too, I'm sure .