Problem Compiling My Own Test Demo... [Solved]

Hi,

I finally got everything all setup right, and compiled both nxOgre_d.lib and nxOgre.lib. Took me awhile because I'm kinda fresh when it comes to C++. Anyways, I first ran into a huge load of errors, but then looked on the "having trouble" section of the nxOgre Wiki, and solved this problem by putting nxOgre.h above Ogre.h. That made me happy needless to say. But then, after following the first tutorial, and mimicking the 101.cpp file, I run into 8 errors pertaining to "world" and "scene". I'm using the latest release of nxOgre and Dagon. Here's the createScene() snippet followed by the errors I'm getting:


void createScene(void)
{
world* mWorld = new world(mRoot, mSceneMgr);
scene* mScene = mWorld->createScene("Main");
mScene->hasGravity();
mScene->hasFloor();

mSceneMgr->setAmbientLight(ColourValue( 0, 0, 0 ));
mSceneMgr->setShadowTechnique(SHADOWTYPE_STENCIL_ADDITIVE);

// Lights
mLight = mSceneMgr->createLight("PointLight1");
mLight->setType(Light::LT_POINT);
mLight->setPosition(Vector3(0,256,0));
mLight->setDiffuseColour(0.9,0.9,0.9);
mLight->setSpecularColour(1.0,1.0,1.0);
}



c:\storage\avlabs\avdev\avengine\alpha\source\core.cpp(48) : error C2065: 'world' : undeclared identifier
c:\storage\avlabs\avdev\avengine\alpha\source\core.cpp(48) : error C2065: 'mWorld' : undeclared identifier
c:\storage\avlabs\avdev\avengine\alpha\source\core.cpp(48) : error C2061: syntax error : identifier 'world'
c:\storage\avlabs\avdev\avengine\alpha\source\core.cpp(49) : error C2065: 'scene' : undeclared identifier
c:\storage\avlabs\avdev\avengine\alpha\source\core.cpp(49) : error C2065: 'mScene' : undeclared identifier
c:\storage\avlabs\avdev\avengine\alpha\source\core.cpp(49) : error C2227: left of '->createScene' must point to class/struct/union/generic type
type is ''unknown-type''
c:\storage\avlabs\avdev\avengine\alpha\source\core.cpp(50) : error C2227: left of '->hasGravity' must point to class/struct/union/generic type
type is ''unknown-type''
c:\storage\avlabs\avdev\avengine\alpha\source\core.cpp(51) : error C2227: left of '->hasFloor' must point to class/struct/union/generic type
type is ''unknown-type''


Help?

Hi again,

I figured out what I did- I was using the Ogre namespace, and didn't put nxOgre::world* mWorld/scene* mScene. Doing this fixed it. However, now I have a second problem: When I exit the program I get an 'Assertion Failure', and it points to ogresingleton.h line 68. Reading the OgreLeaks.log file I see the first line is pointing towards "Core.h" (which is really ExampleApplication.h) line 44- which is:

virtual bool setup(void)
{
// Line 44 Below
mRoot = new Root();

setupResources();

bool carryOn = configure();
if (!carryOn) return false;

chooseSceneManager();
createCamera();
createViewports();

TextureManager::getSingleton().setDefaultNumMipmaps(5);
createResourceListener();
loadResources();
createScene();
createFrameListener();

return true;

}


Any ideas whats going on here?

Try adding:

using namespace NxOgre;

At the top somewhere

[Edit]

The assertion is only an issue when you quit when compiled as Debug. It's either a fault with NxOgre or the Ogre Singleton class, but since that has been around since ages and I haven't seen any other problems; I expect it's a problem with NxOgre.

The solution for now is to compile in release.

But if I remember correctly. I think I fixed the assertion problem but it may not be on the CVS.

But working in Debug mode isn't advisable as PhysX crashes when it cooks meshes or convex shapes anyway.

Ah, beautiful! Thank you very much. Now if I could just get my infite plane to be drawn . The whole scene is pink, sky and all. Can't even tell if a plane is being drawn or not, I'll have to re-check the triangle counts as I look around. Thanks again!

Could your Camera be at 0,0,0 which then the plane would not been seen?

That was the first thing I checked, but its at 10,10,10 looking at 0,0,0. Defaults I believe. See, didn't start from scratch with this code, but rather started massaging it into existing code I wrote following the tutorials on the Ogre Wiki. Hell I'm happy that I got rid of all my errors, but I'm affraid I won't be able to go to sleep until I get a cube that has physics . Perhaps I should post a link to my 3 modified files? They are basically "ExampleFrameListener.h", "ExampleApplication.h", and "Main.cpp". I'm pretty sure I have ExampleApplication.h and Main.cpp in good condition, however it's the ExampleFrameListener.h that I think is giving me problems here. My window is being rendered, and if I change the background color the changes are apparent. It's just that the simple plane isn't there. Also, I'm having a hard time moving in the 'input' stuff, so I don't really have any control whatsoever, save for the esc key exiting. I'll post a link to the files real quick here.

Geese... Yet another stupid mistake- I omitted these lines:

createPlane("grid","nx.grid",Vector3(0,0,0),Vector2(1000,1000),Vector2(100,100));
createPlane("axis","nx.axis",Vector3(0,0.-0.04,0),Vector2(8,8));

I didn't think those lines did anything at first glance except slap materials on, but then I noticed the Vectors when I was rescanning your code . Ok, another one down. It shows up completely white... Think I may have this one though: I need to apply a material. A question about the plane though, specifically the 2 lines above- what do all the values mean? I'm guessing Vector3 would be the position, Vector2 the size? That covers "grid". Axis, I don't get... Vector3 is position again, and Vector2 is the subdivision?

That function creates the mesh for you and applies the materials.

"nx.grid" and "nx.axis" are the materials to use, as they are showing up as pure white the materials don't exist. So you'll have to copy them over as well as the images it uses.


Vector3(0,0,0),Vector2(1000,1000),Vector2(100,100));


Basically:
- Position
- Size
- Subdivisions (optional - Default 1,1)

I hope you can sleep now.

Ah, gotcha... Well looking over the other sample source, I managed to get a material on the ground plane. Wish I had checked back here sooner, no biggie but there was a bit of trial and error. I now have a clean demo running with 1024 cubes (textured at that! ) in a straight line. I call it "Raining Cubes", lol. Very nice work betajaen, very friggin nice.

I still have a bit of stuff to learn, starting with convex meshes. I can't wrap my head around the whole [verts.push_back] thing... I made a simple barrel in 3DSMax, took into MilkShape and exported as mesh. Counted the vertices, totaling 306. But I have no clue how to get the [verts.push_back] coordinates. Is there possibly a maxscript that will output this to the listener window? That would seriously rock the halls of valhalla.

I toyed with particles a bit, smoke to be exact. Particle collisions... Man this thing just keeps getting better. No way I'm gonna sleep. For at least 17 days. How do you size the particles? The smoke acts great, just the particles are a bit small. I had a cool idea to make a little demo scene once I got alot of the basics done, with some crates around a barrel that would explode and send em flying. Then have some smoke after that would be colliding with the boxes and what not.

I didn't look too hard, but... Cloth? Any access to that? I know the PhysX stuff has it available, at least I'm pretty sure. Again, this would rock. This actually brings to mind another question about adding functinality to nxOgre. Is it easy? Like if I wanted to add new particle effects for example. How would I go about this?

Okay, last thing. I thumbed through the x01-x06 tutorial sources, and that stuff was pretty intriguing. The vehicle example reminded me of when I was trying to wrap my head around the Half-Life 2 source. The vehicles had similar setups. I'm definitely going to work on making/obtaining some cool vehicle model to do a nice little demo here too.

Geese, this should have spanned a few topics I think. Hopefully other novices with nxOgre find this post, as in my opinion alot of good help is here.

I think I may submit the "Raining Cubes" demo to Showcase, mainly because it shows what a complete moron can do in one day. Again, you rule betajaen- keep it up.

Well, I uploaded a little preview of "Raining Cubes" you can view the post here, and the screenshot here:

Ah, gotcha... Well looking over the other sample source, I managed to get a material on the ground plane. Wish I had checked back here sooner, no biggie but there was a bit of trial and error. I now have a clean demo running with 1024 cubes (textured at that! ) in a straight line. I call it "Raining Cubes", lol. Very nice work betajaen, very friggin nice.


I didn't lie when I said it was easy



I still have a bit of stuff to learn, starting with convex meshes. I can't wrap my head around the whole [verts.push_back] thing... I made a simple barrel in 3DSMax, took into MilkShape and exported as mesh. Counted the vertices, totaling 306. But I have no clue how to get the [verts.push_back] coordinates. Is there possibly a maxscript that will output this to the listener window? That would seriously rock the halls of valhalla.


I'm going to add a second constructor for convexShapes to accept meshes and read the vertices from that for 0.5

As for Max, I'm not sure. But there must be some thing in there to dump the vertices, even if you save it as an xml file then just copy it over to the code and edit it slighty.


I toyed with particles a bit, smoke to be exact. Particle collisions... Man this thing just keeps getting better. No way I'm gonna sleep. For at least 17 days. How do you size the particles? The smoke acts great, just the particles are a bit small. I had a cool idea to make a little demo scene once I got alot of the basics done, with some crates around a barrel that would explode and send em flying. Then have some smoke after that would be colliding with the boxes and what not.


I can't remember how to set the size, I think it's hard coded at the moment, but you can create your own particle system if you like as long as you subclass the particleEmitter class.


And if you like the particles, you're going to wet your underpants when you discover the state system.


I didn't look too hard, but... Cloth? Any access to that? I know the PhysX stuff has it available, at least I'm pretty sure. Again, this would rock. This actually brings to mind another question about adding functinality to nxOgre. Is it easy? Like if I wanted to add new particle effects for example. How would I go about this?


There is a PhysX tutorial or two dedicated to cloth, basically it's just dynamic bodies such as flattened cubes, with lots of joints.

I'm going to wrap it of course, and write it as a prefab. But since there is a PhysX tutorial already you can experiment.

And it's wet your pants bloody easy to extend NxOgre, most of the systems; Particles, States, Controllers and Prefabs all have a master class which you extend, then just use the factory method to create them.


Okay, last thing. I thumbed through the x01-x06 tutorial sources, and that stuff was pretty intriguing. The vehicle example reminded me of when I was trying to wrap my head around the Half-Life 2 source. The vehicles had similar setups. I'm definitely going to work on making/obtaining some cool vehicle model to do a nice little demo here too.


I haven't messed around with Source yet, but I like the idea of blueprinting prefabs such as cars or ragdolls, it makes sense in a real world perspective.



Geese, this should have spanned a few topics I think. Hopefully other novices with nxOgre find this post, as in my opinion alot of good help is here.


Nah, we've got a dedicated forum here, talk away!


I think I may submit the "Raining Cubes" demo to Showcase, mainly because it shows what a complete moron can do in one day. Again, you rule betajaen- keep it up.

I saw, and I like. Try adding some other things in it as well, spheres or convex's for example.

Cheers!

I'm going to add a second constructor for convexShapes to accept meshes and read the vertices from that for 0.5
(How do you actually quote someone?)

I'm pretty sure this is what your saying, but do you mean that you will just have to reference the .mesh file and it will do all the work for you? If so, rock on.

But there must be some thing in there to dump the vertices, even if you save it as an xml file then just copy it over to the code and edit it slighty.

I'm going to look into this. If I find and test anything that proves to be effective, I'll let you know.

I think it's hard coded at the moment, but you can create your own particle system if you like as long as you subclass the particleEmitter class.

I look at the particleEmitter source, and it's slightly above my head (only really glanced at it for a minute). Once I get a deeper understanding of both programming and the PhysX api, I'll see if I can't contribute to the particle system in some way. I love particles. I love robust and highly configurable particle systems even more. I would love to add basic templates onto the existing system, and extend the functionality.

There is a PhysX tutorial or two dedicated to cloth,

On the hunt as I write this.


I'm going to wrap it of course, and write it as a prefab.

Before you get to working on releasing the next nxOgre, were you aware that the 2.4 SDK came out? I'm sure you are, but just in case. I was reading over the details and new features/improvements. Sounds like it might be worth upgrading to, I dunno.

And if you like the particles, you're going to wet your underpants when you discover the state system.

Would the state system allow me to, for example, hit a button to pause the simulation, or hit a button to make an 'explosion' (as of in force)? I know you can do that, just wondering if that's what your referring to. I still need to learn how do these types of things, and are some of the things that I want to add into my demo test-bed. Being able to pause the demo mostly.

And it's wet your pants bloody easy to extend NxOgre, most of the systems; Particles, States, Controllers and Prefabs all have a master class which you extend, then just use the factory method to create them.

Oh please, please point me in the direction of that party.

I haven't messed around with Source yet, but I like the idea of blueprinting prefabs such as cars or ragdolls, it makes sense in a real world perspective.

I agree, being able to debug and implement some prefabs quickly and easily, in a no-nonsense pattern is essential nowadays. Source did a good job of this, and as robust as it's physics system was (geese I wish Havok was like PhysX with it's SDK) I think nxOgre + Ogre + other added functionality could blow it away. At least at it's core. Content would take some hard work, but playability is what I'm aiming for first. I couldn't run a simple scene with 1024 cubes falling in Source with near as good a frame rate as with my little demo.

I saw, and I like. Try adding some other things in it as well, spheres or convex's for example.

Most definitely. I have many more features I want to implement. Just need to learn more ^^. I finally got the demo uploaded, which you can find below. I must have worked another 2 hours just trying to get it uploaded somewhere, and finally landed on bestsharing.com (I highly recommend them too, no registration required, unlimited bandwidth up/down) after filefront.com failed to email me my confirmation, wouldn't let me log in, and finally ended up having a server crash that still seems to be in effect.

Anyways, you'll find this demo is a little different than the screenshot visually, and functionally it is too- though you can't see that from a screenshot.

http://www.bestsharing.com/files/ms0011 ... s.rar.html

One last little comment- I was tweaking the distance between the cubes and was working my way down to 0 distance. I had put in something like 0.15, checked it, and something really cool happened. The whole line of cubes all the way up started spiraling... Only way I can explain it well is that it had the same action as an ice cream machine, you know when you pull the lever, and spiral it on your cone. It looked sweet. Maybe I'll make a short video of it (would upload a demo just for this, but I'm on 56k :/)

Anyhow, I think I'll start a new thread once I have a new version out, just so I can work things out with you on how to add new things and how things work- that is, if I'm not bugging the sh*t outta you yet

(How do you actually quote someone?)




[quote="Name"]So I said...[/quote]
Wrong, Wrong Wrong, Wrong Wrong Wrong, Wrong. You're Wrong!




I'm pretty sure this is what your saying, but do you mean that you will just have to reference the .mesh file and it will do all the work for you? If so, rock on.


Yep.


I think it's hard coded at the moment, but you can create your own particle system if you like as long as you subclass the particleEmitter class.

I look at the particleEmitter source, and it's slightly above my head (only really glanced at it for a minute). Once I get a deeper understanding of both programming and the PhysX api, I'll see if I can't contribute to the particle system in some way. I love particles. I love robust and highly configurable particle systems even more. I would love to add basic templates onto the existing system, and extend the functionality.


NxOgre API you mean. PhysX doesn't have particles out of the box (well not a nice factoryMethod like NxOgre does)

I want other types of particles such as ticker-tape/leaf, sparks, small explosion and a few others.


There is a PhysX tutorial or two dedicated to cloth,

On the hunt as I write this.


It's in there, and you'll be kicking yourself with how it's implemented. It's really easy.



Before you get to working on releasing the next nxOgre, were you aware that the 2.4 SDK came out? I'm sure you are, but just in case. I was reading over the details and new features/improvements. Sounds like it might be worth upgrading to, I dunno.


No, I wasn't. I can't upgrade or test it out as my PC is non-existant at the moment hence the lack of NxOgre work. You can be my guinea pig if you like and try it out though.

I know Aegia will be remove parts of the joints system and a few other things to make it cleaner, but is it in 2.4 or will it be later?


And if you like the particles, you're going to wet your underpants when you discover the state system.

Would the state system allow me to, for example, hit a button to pause the simulation, or hit a button to make an 'explosion' (as of in force)? I know you can do that, just wondering if that's what your referring to. I still need to learn how do these types of things, and are some of the things that I want to add into my demo test-bed. Being able to pause the demo mostly.


Yeah, but that's not what states are for.

Imagine; A bunch of planks of wood, and one which is on fire. By being a little clever, and assigning a IS_FLAMABLE flag to those pieces of wood, when they touch something that is on fire, or enters a stateTrigger of fire, that piece of wood goes on fire.

The state system is immensely powerful once you get your head around it, and there is a x0? demo dedicated to it. Might be in the CVS though.



And it's wet your pants bloody easy to extend NxOgre, most of the systems; Particles, States, Controllers and Prefabs all have a master class which you extend, then just use the factory method to create them.

Oh please, please point me in the direction of that party.


Source, there's no documentation as of yet, but apart from the Particles and States, you probably won't need to work with the other parts. However just looking at the other classes of that system will help you anyway.


I couldn't run a simple scene with 1024 cubes falling in Source with near as good a frame rate as with my little demo.


Really? Either Source is a slow render, or PhysX is faster than Havok, either way WOO-HOO!


Anyways, you'll find this demo is a little different than the screenshot visually, and functionally it is too- though you can't see that from a screenshot.

http://www.bestsharing.com/files/ms0011 ... s.rar.html

One last little comment- I was tweaking the distance between the cubes and was working my way down to 0 distance. I had put in something like 0.15, checked it, and something really cool happened. The whole line of cubes all the way up started spiraling... Only way I can explain it well is that it had the same action as an ice cream machine, you know when you pull the lever, and spiral it on your cone. It looked sweet. Maybe I'll make a short video of it (would upload a demo just for this, but I'm on 56k :/)


A video would be nice (Just fraps it then save it as an XVid in virtual dub), as the PC is borked and I can't try it out.


Anyhow, I think I'll start a new thread once I have a new version out, just so I can work things out with you on how to add new things and how things work- that is, if I'm not bugging the sh*t outta you yet

Nah. NxOgre is getting popular now and it's great to see how people are using it.

Enjoy!

Just looked at the brief release notes of 2.4.

- Joints on Hardware, excellent.
- Dedicated terrain shape now. Fantastic!
- Enhanced collision detection. Awesome.
- Visual remote debugger. Interesting, I'll need to play with this.
- PML Exporting/Importing, I thought it already did this. However I need to support COLLADA - probably the same way how NxScene was implemented.

Yes, all pretty cool- and supposedly a new cloth api that dominates. You were saying that I would kick myself because cloth was so easy, but I'm having a hard time finding anything in the PhysX SDK documenation. Reading the compiled .chm at least, using search for "cloth" returned nothing. I looked through every single page of the documentation, but it seems they don't cover it, or I'm blind as a bat.

Ah, real quick- http://www.bestsharing.com/files/ms0011 ... p.avi.html

Now, I have some more questions. You were right about the particle size being hard coded. Default is 0.5, I changed it to 2.5 and re-compiled both nxOgre and a new little demo (using same base as raining cubes, just took out the cubes and copied over the snippet from particle tutorial source) and voila. Now here comes the questions:

First some code...
// nxOgre_particleEmitter.cpp

smokeEmitter::smokeEmitter(Ogre::String _name, Ogre::String _materialName, Ogre::Vector3 _pos, int _maxParticles, float _maxTime, scene *_scene) : particleEmitter(particleEmitter::PARTICLE_SMOKE, _scene,_maxParticles, _maxTime)
{
mBillboardSet = mScene->mSceneMgr->createBillboardSet(_name + ".bset",256);
mBillboardSet->setMaterialName(_materialName);
mBillboardSet->setDefaultWidth(0.5f);
mBillboardSet->setDefaultHeight(0.5f);
mBillboardSet->setAutoextend(true);
mBillboardSet->setCastShadows(true);

mNode = mScene->mSceneMgr->getRootSceneNode()->createChildSceneNode();
mNode->attachObject(mBillboardSet);
mNode->setPosition(_pos);

mStartingVelocityScale = (1.0f / NxReal(RAND_MAX) * 0.5);
mNextParticleTime = 0.5;

A little more...
// ogrebillboardset.h

// Is this what is referenced at [mNode->setPosition(_pos);]?
virtual void setPosition(const Vector3& pos);

// If so, would be able to configure a particles scale be like the same? ie:
virtual void setDefaultHeight(Real height);

// would then be like this?
mNode->setDefaultHeight(_height);
mNode->setDefaultWidth(_width);


Now here is how we create a particle system...
mScene->createParticleEmitter(new smokeEmitter("Smoke","nx.smoke",Vector3(0,1,0),128,5.0f,mScene));

How can I make this line simply create the particle system, and then have lines that follow to configure it? Basically I want to be able to do this:

mScene->createParticleEmitter(new smokeEmitter("Smoke");
smokeEmitter->setPosition(Vector3(0,1,0));
smokeEmitter->setHeight(2.5f);
smokeEmitter->setWidth(2.5f);
smokeEmitter->setDensity(0.9f);
smokeEmitter->setParticleLife(1.5);

Oooh, how about having it get bigger over time? Like this:
smokeEmitter->setScale(mParticleLife * 0.3);

If this is how one adds functionality, then I may end up going crazy. If I can wrap my head around script parsing, I may even figure out a way to add a new particle script, just for nxOgre particle systems. I plan on tweaking all the current particle templates (prefabs?) and making them prettier. First off is smoke. I'd like to add some "twist" (or torque?) to the whole smoke emitter (not per-particle), which would also be tweakable.

Heres a screenshot of the modified smoke size:


Also I was wondering if I could make an emitter that spawns shapes, for example, cubes.

On the note of testing out the 2.4 release of the PhysX SDK, I will definitely do this once I get to know a little more of nxOgre and how to operate. Just so that if there are any problems, I'll be able to outline them a little better. Of course, I could always just post them here, and I assume from previous comments thats acceptable . Once I get it downloaded I'll make a second project just for this.

Yes, all pretty cool- and supposedly a new cloth api that dominates. You were saying that I would kick myself because cloth was so easy, but I'm having a hard time finding anything in the PhysX SDK documenation. Reading the compiled .chm at least, using search for "cloth" returned nothing. I looked through every single page of the documentation, but it seems they don't cover it, or I'm blind as a bat.


Did you download the training documentation? It's a separate installer which installs over the PhysX install and adds lots and lots of tutorials. Those tutorials match then the NxOgre tutorials so PhysX 101 is NxOgre 101.


Ah, real quick- http://www.bestsharing.com/files/ms0011 ... p.avi.html


Woah, fast computer. Mine always slowed down when it hit a 1000 cubes. I can see why you are so impressed and happy.



Now, I have some more questions. You were right about the particle size being hard coded. Default is 0.5, I changed it to 2.5 and re-compiled both nxOgre and a new little demo (using same base as raining cubes, just took out the cubes and copied over the snippet from particle tutorial source) and voila. Now here comes the questions:


I can do it, but I can't program it blind without a x86 compiler. But I think the particles do scale based on the life time.

I'll have a go later though (I've had lots of new goodies arrive in the post today which I want to try out!)

But it's really easy to do anyway.


If this is how one adds functionality, then I may end up going crazy. If I can wrap my head around script parsing, I may even figure out a way to add a new particle script, just for nxOgre particle systems. I plan on tweaking all the current particle templates (prefabs?) and making them prettier. First off is smoke. I'd like to add some "twist" (or torque?) to the whole smoke emitter (not per-particle), which would also be tweakable.


I wouldn't implement script parsing for NxOgre; when Lua was part of NxOgre even if it wasn't used at all, just "idling" in the background it would reduce the frame rate by 100.

Also the Emitters are very heavy stuff, it's re-positioning, re-orientating every particle for every other frame per second so it needs every processor cycle it can get


Also I was wondering if I could make an emitter that spawns shapes, for example, cubes.


Yep, just base the code on the smokeEmitter. Make sure you clean up all the entities and scenenodes when the particle dies else you'll have some massive memory leaks.


On the note of testing out the 2.4 release of the PhysX SDK, I will definitely do this once I get to know a little more of nxOgre and how to operate. Just so that if there are any problems, I'll be able to outline them a little better.


Chairs! I'm sure it'll work fine, but you never know.

wouldn't implement script parsing for NxOgre; when Lua was part of NxOgre even if it wasn't used at all, just "idling" in the background it would reduce the frame rate by 100.

Also the Emitters are very heavy stuff, it's re-positioning, re-orientating every particle for every other frame per second so it needs every processor cycle it can get

What if I made some sort of preloader? Just to load all the particle/object properties at runtime, that wouldn't be taxing would it? Perhaps it would even speed things up?

Did you download the training documentation?

D'oh No I didn't, but I did save every tutorial page from the Ageia support area (which in my opinion is crap, no support really unless your a registered developer :/) in an archive format.

Did you see... One sec here... Lesson 411? Fragmenting objects? I ask because of your post on CellFactor, might be a better way to do breaking objects?

Mine always slowed down when it hit a 1000 cubes.

Well if I zoom out, and the triangle (polygon?) count hits upwards of 100k+, it starts to hit the 25fps and lower mark. I'm sure there are ways to make things run even better, but I'm still green when it comes to this stuff . But here are my machine specs if they help you with benchmarking a little:


WinXP SP2
AMD Athlon XP 3200+
1.5 Gigs DDR Ram
256MB Nvidia GeForce FX 5600


I really want to upgrade my card, and swap out my ram for 2 1gig'rs. Sigh...

Ah, and the particles (at least I'm pretty sure) have a static size, staying x.xf size until death. Like I say, I could be wrong though. If I follow the particles as they rise up, until death, they look as if they stay the same size. Perhaps the scaling is just very minimal and innoticable?

Also, the Ageia site SAYS that 2.4 is available, and the download link brings you to the support area, just like 2.3.2 yet 2.4 is nowhere to be found. I looked all over. I searched on the site. Nothing. So I sent a message to support and got a reply saying that I basically am a nobody and they are going to ignore me if I'm not paying them a gazillion dollars to be a register developer .

Well, got a 'real' reply from Ageia about 2.4:

"It's only available to licensed developers. Read the Forum and Knowledge Base for more details."

That's wonderful. Like when you get socked in the ear. Guess we can't prototype anything afterall...
-----

I'm having trouble figuring how to 'pause' a simulation. I want to bind this to a key, so people could stop/start it at will. This brings up another problem- If I put the 'addForce' functions in my framelistener, everything compiles fine. The 'addForce' is being added to the right thing (in my case mCube). But if I hit the program errors and quits. No report, and nothing in the log.

And this should be my last question for a while- where would I add new shapes, or for example if I wanted to make some cloth that I could call just like you would a cube prefab. What file am looking for? I'm guessing nxogre_shape.h, but I want to be sure.

With the 2.4 being mostly upgrades to the cards and bug fixes, perhaps they assume that developers who use that card would have a commercial license. However they should give it out to us poor people, however it's there commercial library and they can do it as they wish.

If it's quitting then most likely mCube instance isn't set up correctly, double check you have mCube = mScene->createBody(...)

Cloth wouldn't be a single shape, it would be several bodies with many joints to pretend to be a soft one.

Like in this crudely done ASCII drawing:-


B--B--B--B--B
|..|..|..|..|
B--B--B--B--B
|..|..|..|..|
B--B--B--B--B
|..|..|..|..|
B--B--B--B--B

B = Body with a flat cube shape (i.e. 1x0.05x1 metres)
-- or | = Hinge Joint


And you won't be able to expand on the shapes system unfortantly, unless you modify the body and trigger (if you wish) code as well (it's particularly hard coded).

I just read over the cloth tutorial from Ageia, and that ASCII drawing fits the basic overview perfectly . As far as Ageia and 2.4, I hope they release the SDK to the public someday at least, perhaps when a newer version comes out. Maybe they like to let license holders stay ahead of the game? Well, I guess as far as adding new shapes, I'll have to wait until nxOgre 0.5 comes out- you said you were planning on adding cloth?

Now that I have a basic understanding of nxOgre, I want to get a basic understanding of a few other things, such as OIS, openAL, etc. So that I can put together a more 'complete' framework that I can add onto and improve as I gain more knowledge.

I managed to get my own mesh loaded, just another basic cube. To me thats a big step. Later on I'll try getting more advanced meshes loaded.

Thanks for all your help so far, and the awesome wrapper that is nxOgre.

Always happy to help.