[Mess]NxOgre 1.5.2 and BloodyCakes released, for Ogre and GL

This is NxOgre 1.5.2 and BloodyCake for Ogre and OpenGL only. There is no Ogre involved apart from the name. You don't even need Ogre on your computer to run it. Just PhysX.

This release is a completely and totally brand new version of NxOgre; it's very different from the previous NxOgre we are all used to. Apart from being a complete rewrite, it does not use Ogre anymore in the core library.

Release notes

1.5.2 - Released on 04-12-2008, at http://www.ogre3d.org/phpBB2addons/viewtopic.php?p=50900

Authors:
[Betajaen] Robin Southern, Lead developer of NxOgre.

Summary:
Added the kinematic actor controller, and ported the NxCharacter.dll (CharacterController) into NxOgre
as the Kinematic Controller class.

Changes:

[1] Added KinematicActor class (Betajaen)
[2] Added KinematicController class. (Betajaen)
[3] Filled out the Actor functions. (Betajaen)

Warnings:
[1] Due to a strange bug, avoid using the Quaternion functions in the Matrix4 and real33 classes. (Found by Betajaen)

Download

I have zipped up BloodyMess and BloodyCake both in the same zip file, which can be downloaded from here - NxOgre.1.5.2.zip (323KB)

Install and Play

If you still have the PhysX environmental variable; You can unzip BloodyMess and BloodyCake into any folder and compile them both. Currently; the dlls and libs for both release and debug both called NxOgre.dll/NxOgre.lib, so be careful with that.

The NxOgre Solution is at.

- BloodyMess/compiler/windows/NxOgre.sln

Make sure you compile every project in there. GLCake needs GLUTRenderSystem, and OgreCakes needs the OGRE3DRenderSystem.

The BloodyCake solution is at:

- BloodyCake/BloodyCake.sln

Make sure you have NxOgre.lib and NxOgreGLUT.lib compiled.


Including and Linking to NxOgre and NxOgreOGRE3D or NxOgreGLUT

For now on all you have to do is link and include to the BloodyMess/sdk/ folder. Both the headers and libs will be copied into there.

Don't bother with the real headers folders; because eventually each platform will have their own specific headers.

You don't need to link or reference to PhysX at all. Don't even need the DLLs anymore. Seriously.

BloodyCake for OpenGL or OGRE

Once you've compiled them both, go into the release or debug folder in the BloodyCake folder. Just run the application; it should be good to go.

By default will spawn 401 NxActors (30 in OgreCake); 400 Actors and 1 SceneGeometry at once. Obviously you can look at the source code to see how it works.

There are no camera controls or any keys. Just click on the exit button to quit.

If you want benchmarks. I used Fraps on it, and it stayed steady at 30FPS, with no slowdown.

A very quick tutorial

Everything is a little rough at the moment; But it's fun to play with:


World is created via a static function now.

World* mWorld = World::createWorld();

Destroying via:

World::destroyWorld()

If you don't destroy world, or you cause a crash. The MemoryDebugger will dump a log to the console. In the future it will be logged to a file.

Parameters are replaced by descriptions.

WorldDescription wd;
wd.mNoHardware = true

Scenes are almost like the old ones; they can be created via a description or prototype.

mWorld->createScene();

Actors are now split into four categories, linked together via a common class called RigidBody.

- Dynamic (Actor); Moves around
- Geometry (SceneGeometry); Never moves at all.
- Kinematic (KinematicActor); Moves around but doesn't do physics
- Trigger (Trigger); Never moves around, and things can move through it.

Creating an Actor; is almost like before. Names aren't important, so they've been demoted into the RigidBodyDescription (if you have to use them).

Actors:

Can only use Boxes, Capsules, Spheres, Wheels and Convexes.

mScene->createActor(new Box(1), Matrix44(0, 1, 0));


SceneGeometries:

SceneGeometries can only use Meshes and Terrain. It is designed to be a multi-shape Actor. So it is best to dedicate most of the geometry of a room to it.

Shapes shapes;
shapes.insert(new PlaneGeometry(0, real3(0, 1, 0));
mScene->createSceneGeometry(shapes, Matrix44(Matrix44::T_Identity));


Usual rules apply. Do not discuss this outside this thread.

Will NxOgre still run with D3D RenderSystem?

Yeah?

Your changes listed don't seem to include the render system, is it there?

Yep. I forgot to put it in.

SceneGeometries can only use Meshes and Terrain.

Why ? I thought capsule + sphere/convex would be ideal for trees description.

SceneGeometries can use all shapes, but I like to keep it a secret. (Stops the newbies trying out triangle meshes in cars and stuff)

so evil

hi betajaen
NxOgre 1.0'22T5 will no long more have support?
if not, i'll have to change right now to Bloody Mess

Well I can answer posts to it, but I have no desire to continue working with that source though.

So when do you plan some kind of "final" release for Bloody Mess?
Lets say a tested version of NxOgre, Flour and Cake, ready for use.
Without the need to look for patches a, b and c from thread x, y, z?

I´m asking seriously... for same reason like almondega.

Flour most likely won't be upgraded to BloodyMess, there is no need. Cake is just an example and not that important. I don't know, a few months.

My schedule has gotten a little weird recently so things have to be shifted around.

I am trying to keep up with it, just things may get a little slow for a while.

I don't know if it's me, but when I start OgreCake I have a strange feeling when I run it. Not you?

EDIT:

a screenshot:

Nobody have the same problem that me?

Yeah, I noticed it too.

Very strange

Not really. It's a minor fixable bug, which I'm working on.

i think the problem comes from the initial unstable frame rate

No, it's size of the cube being weird, or the sleep damping being to high. All the cubes tend end up in the same position regardless of the frame rate.

Also there is no visible floor, so we don't have a good frame of reference here.

i wonder if i can use bloody mess in ogre without ogrelicious

Er, yeah.

The OGRE3D RenderSystem for NxOgre doesn't even use Ogrelicious. BloodyCake does, but both are examples of how to use NxOgre.

I really wish people would read things.

Ooppss...
Sorry that I was a bit losing track when looking at BloodyCake.
I saw too many *Smart* things inside.

I ran into a weird problem.
I created a stack of boxes but they don't seem to be stable and eventually fall down.
What had happen?

I think it's related to the other "bug". I expect the default values for the RigidBodydDescription, or the description to blueprint code is slightly mixed up.

I compiled NxOgre with Visual C++ 2008 Express Edition and put those yellow boxes into my Ogre 1.6 project, they don't have the rendering problem that OgreCake does.

Also I am unsure how to use shapes to give the terrain I used in setWorldGeometry(); physics

Is it still possible to link with the remoteDebugger?

betajaen
this version 1.5.2 has all that new and older stuffs from version T5 (Bleeding) ?
i mean, CCD, Collision Callbacks, accumulator controler?

tks

no.

I don't know if Im getting this right. Will this version of nxogre work with D3D & OpenGl? Are there any significant limitations in this version compared to nxogre 1.0'21? I mean, can I do everything in 1.5 that i can do in 1.0? Please let me know because I prefer to use supported version ..

edit: didnt notice there was a second page on this thread /edit

I'm trying to run a first simple NxOgre app similar to Cake (in fact the same NxOgre stuff but without Ogrelicious. That's what I do:

m_pWorld = NxOgre::World::createWorld();

NxOgre::SceneDescription sceneDesc;
sceneDesc.mGravity = NxOgre::Real3(0, -9.8f, 0);
sceneDesc.mName = "DemoScene";

m_pWorld->createScene(sceneDesc);

m_pRenderSystem = new OGRE3DRenderSystem(m_pScene);

So far so good, all the initialization is done (Ogre is initialized as well).

Now I want to add content but it crashed at runtime in the third line, trying to generate the SceneGeometrie:

Shapes shapes;
shapes.insert(new PlaneGeometry(0, Real3(0, 1, 0)));
m_pScene->createSceneGeometry(shapes, Matrix44(Matrix44::T_Identity));

m_pScene->getMaterial(0)->setStaticFriction(0.5);
m_pScene->getMaterial(0)->setDynamicFriction(0.5);
m_pScene->getMaterial(0)->setRestitution(0.1);

OGRE3DBody* body = m_pRenderSystem->createBody(new NxOgre::Box(1,1,1), Real3(0, 10, 0), "cube.1m.mesh");

Any ideas?

Looks like m_pScene don't posses an address. Try make it:


m_pScene = m_pWorld->createScene(sceneDesc);

m_pRenderSystem = new OGRE3DRenderSystem(m_pScene);

OMG...what a mistake . I've checked it again and again, looked at Cake again and again and then it is such a trival mistake (that was the least that I would have doublechecked...)!

Thanks!

ok.. how about trianglemesh and adding a custom .mesh file as a shape in scene geometry?
I used 0.9 before and this is very very new, i see a lot of things have changed. Rather than:

Shapes shapes;
shapes.insert(new PlaneGeometry(0, Real3(0, 1, 0)));
mScene->createSceneGeometry(shapes, Matrix44(Matrix44::T_Identity));

i need to create the shape from a .mesh terrain from 3dsmax not an infinite plane. How can i create that custom shape? I've looked through the nxogre classes and found nothing but primitives and the simple_things aren't classes.
i might be blind (or not) but i've looked through all the things nxogre namespace contains and couldnt find something for .meshes.. only primitives. Any guidelines on how to do this? Cheers

[edit]
ok so no trianglemeshes for now. still waiting for them ^^ good luck with your projects.

I can create an OGRE3DBody, but how can I access its Ogre::Entity or the Scenenode? There member variables, but they are protected. Do I have create an own class inheriting from Ogre3DBody and there define my own getter methods?

Do'h. I must of forgotten to put them in. I'll put them in the next release, but if you want to add "getNode()" to the class now. Go for it.

Just want to ask that when will be the next version with bug fixes come out?

After the new year. I want to spend Christmas working on the new website wiki code, and transfer it to a new server.

any ETA on trianglemeshes? really need them to start implementing the physics part ^^

Same answer.

cheers! can't wait for a new webiste / wiki also

Subtle hint of what will be happening in the New Year.

Apparently the new year will bring lots and lots of purple

Is NxOgre 1.5.2 usable in serious games or applications or have I to wait for an final release?

EDIT: I got some errors trying to compile it:
1>c:\programmierung\nxogre_1_5_2\bloodymess\compiler\windows\source\nxogreclasses.cpp(82) : error C2065: 'NX_MEMORY_SortedSet_NameBinding' : undeclared identifier
1>c:\programmierung\nxogre_1_5_2\bloodymess\compiler\windows\source\nxogreclasses.cpp(82) : error C2051: case expression not constant
1>c:\programmierung\nxogre_1_5_2\bloodymess\compiler\windows\source\nxogreprototypefunctions.cpp(111) : error C2039: 'backgroundThreadPriority' : is not a member of 'NxSceneDesc'
1>c:\programmierung\nxogre_1_5_2\bloodymess\compiler\windows\source\nxogreprototypefunctions.cpp(115) : error C2039: 'dynamicTreeRebuildRateHint' : is not a member of 'NxSceneDesc'
1>c:\programmierung\nxogre_1_5_2\bloodymess\compiler\windows\source\nxogrereason.cpp(146) : error C2039: 'dynamicTreeRebuildRateHint' : is not a member of 'NxSceneDesc'
1>c:\programmierung\nxogre_1_5_2\bloodymess\compiler\windows\source\nxogrereason.cpp(147) : error C2039: 'dynamicTreeRebuildRateHint' : is not a member of 'NxSceneDesc'

Wow, why do libraries never compile.. Can't you just include the libs?
fatal error C1083: Cannot open include file: 'Nx.h': No such file or directory
1>Project : warning PRJ0018 : The following environment variables were not found:

Almost every project in the solution gives an error.

Those headers are part of PhysX. Which you need to download anyway.

@Fred

Your probably using an older version of PhysX, or your linking to it in your application (which you don't need to do).

Alright, i figured out my problem was the environmental variable, fixed and compiled now

Am I blind or is there no documentation?

take a look at the cake and function briefs. other than that.. we are our own (for now)

I'm working on the new wiki code now. Once that's settled, I can start writing documentation for it again.

I'm working on the new wiki code now. Once that's settled, I can start writing documentation for it again.

Nice! Good job by the way, lets just hope you don't change the API too much now

Wow, why do libraries never compile.. Can't you just include the libs?
fatal error C1083: Cannot open include file: 'Nx.h': No such file or directory
1>Project : warning PRJ0018 : The following environment variables were not found:

Almost every project in the solution gives an error.

You're lucky, I'm getting compile errors like these:

1>e:\nxogre.1.5.2\bloodymess\rendersystems\glut\include\GLUTCommon.h(67) : error C2039: 'Real3' : is not a member of 'NxOgre'
1>e:\nxogre.1.5.2\bloodymess\rendersystems\glut\include\GLUTCommon.h(67) : error C2146: syntax error : missing ';' before identifier 'Colour'
1>e:\nxogre.1.5.2\bloodymess\rendersystems\glut\include\GLUTCommon.h(67) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>e:\nxogre.1.5.2\bloodymess\rendersystems\glut\include\GLUTCommon.h(67) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>e:\nxogre.1.5.2\bloodymess\rendersystems\glut\include\GLUTCommon.h(71) : error C2039: 'Real3' : is not a member of 'NxOgre'
1>e:\nxogre.1.5.2\bloodymess\rendersystems\glut\include\GLUTCommon.h(75) : error C2039: 'Real2' : is not a member of 'NxOgre'
1>e:\nxogre.1.5.2\bloodymess\rendersystems\glut\include\GLUTCommon.h(75) : error C2146: syntax error : missing ';' before identifier 'Size2'
1>e:\nxogre.1.5.2\bloodymess\rendersystems\glut\include\GLUTCommon.h(75) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>e:\nxogre.1.5.2\bloodymess\rendersystems\glut\include\GLUTCommon.h(75) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>e:\nxogre.1.5.2\bloodymess\rendersystems\glut\include\GLUTBody.h(34) : fatal error C1083: Cannot open include file: 'NxOgreRigidBodyDescription.h': No such file or directory

Is this compile error in your application, or in the NxOgre solution?

If it's your application; then you set the project settings for the headers and libs to the sdk folder only.

I don't know if it's me, but when I start OgreCake I have a strange feeling when I run it. Not you?

EDIT:

a screenshot:


I don't know if you found this strange box bug yet or not. But it's really stupid, look at the initOgre() method, you have the farClip set a 0.5 and the nearClip set a 500, switch them around and it's all nice after that.

Yes you are right!!! Thank you

I've already had that reported here, but I had the impression that it did not totally solve this issue...will need to have a look again on it.

Is this compile error in your application, or in the NxOgre solution?

If it's your application; then you set the project settings for the headers and libs to the sdk folder only.


I'm trying to built the NxOgre solution.

I was able to get the last version of Cake working pretty well and even edited the code a bit to mess with it.

I just tried out simulating a NxOgre Scene on my new graphics card and it worked. The scene wasn't complicated or special though so speed seems to be just the same as it's on the CPU. I imagine it would vary on how populated it is, and how much normal graphics data is being sent to the GPU also. But a good start either way.

I think once I have more time, I'm going to have a good read of the OpenMP documentation and implement multi-core threaded scenes into NxOgre.

Is it possible to tell what scenenode an actor should use? Much alike the "inherit Actor to your own class" thing in 1.0 !?

Is it possible to tell what scenenode an actor should use? Much alike the "inherit Actor to your own class" thing in 1.0 !?

Actor's don't use SceneNodes, Actors don't use NxOgre. Neither does NxOgre.

You create a class and inherit the Actor. Very very much like the example body class that comes in the Ogre3D rendersystem. You should use that; or make your own. Pretty easy really.

Ok, looks good. Thanks

I looked into Ogre3d render system and it seems simple and easy. I have one question though. As I understand it now, an Actor can only be build up by an external entity/manager because the constructor requires a Shape or prototype instantly. This means that a class Rock which inherits Actor cannot create itself within its own constructor. In previous version of nxOgre you could do this by first call Actor constructor supplying the scene and then call _createActor() and supply the shape. This is handy in this case when class Rock know by itself that it should use a NxOgre::cube() or whatever instead of let someone else decide. Any tips on what I should do to achieve something like this? Perhaps I should not inherit Actor but rather have it as a member in the class?

Here's some code about what I'm talking about:
class Rock : public Actor {
Rock(Scene* scn) : Actor(scn) {
// make some shapes..
Actor::_createActor(new Cube(10.0f));
} // this is not possible in nxogre 1.5 ?

// you must do something like this?: (pseudo)
class Rock : public Actor {
Rock(Scene* scn, Shapes &shapes) : Actor(scn, shapes) { ....}
}

Shapes shape;
shape.insert(new cube(10));
new Rock(mScene, shape);


I've noticed with this version that visual studio 2008 intellisense is having lots of issues parsing NxOgre. I fixed it by replacing "__nxogre_begin" with "namespace NxOgre {"

New question: How can I convert Real33->Quaternion ..?

New question: How can I convert Real33->Quaternion ..?

There isn't a direct way. You'll have to put it into an identity Matrix44 then convert it. But I'm pretty sure there is a bug with the quaternion conversion code at the moment, but your welcome to try it out. I just worked around it by just copying the Matrix44 into an Ogre one, and using that math library.

Ohh I meant Quaternion->Real33. I'll have a look on that.
I need the conversion for mActor->setGlobalOrientation(mCurrentYaw * mCurrentPitch);

Ohh I meant Quaternion->Real33. I'll have a look on that.
I need the conversion for mActor->setGlobalOrientation(mCurrentYaw * mCurrentPitch);

Personally, I would use the Ogre Quaternion/Vector classes; then convert them into a real4 once done.

The NxOgre math classes are a bit pants at the moment.

So now I'm done with all the refactoring for the new nxogre test. As I expected, Im running into an assertion when Im trying to create a Scene. The scene description seems valid as it returns true. When Im running the OgreCake I get the same error. The ogrecake console says that scenedescription is Not valid? Any ideas? What Physx SDK/system software version should I use? Currently, Im using the 2.8.1 SDK and system software 8.10.13.

Let's have a look at the SceneDescription.

SceneDescription scene_description;
scene_description.reset();
scene_description.mUseHardware = false;
if(!scene_description.valid())
SPELPRJ_LOG(WARNING, "Scenedescription not valid", "PhysicsManager::createScene");

mWorld->createScene(scene_description);

Very very odd. Although you don't need the reset, and useHardware is false by default.

What happens if you do:

SceneDescription scene_description;
if(!scene_description.valid())
SPELPRJ_LOG(WARNING, "Scenedescription not valid", "PhysicsManager::createScene");
mWorld->createScene(scene_description);

I know that works, but what about you?

Doesn't work. Thing is, OGRECake generates the same error and I suppose OGRECake works on your machine. That would lead us to some kind of file/dll corruption on my side. I will go through my files again and delete everything related to old Physx/NxOgre files.

I should also mention that the Physx SDK samples works perfectly.

Okey, problem solved. It's a real mess but I think I linked the NxOgre to Physx SDK 2.8.0 and used the wrong dll for that Something like that ...
Anyway I did a clean build of everything (NxOgre, OGRE3DRendersystem, and OgreCake) with clean installation of PhysX SDK 2.8.1. Also using Physx system software 8.10.13!
Thank you for your time.

How can I create a connection to the Physx Remote debugger in nxogre 1.5?

How can I create a connection to the Physx Remote debugger in nxogre 1.5?

Not at the moment. Unless you want to do it manually; in that case. You need to include the PhysX headers/libs, which to be fair. I've never done with the mess, so I wouldn't know what would happen.

Not at the moment. Unless you want to do it manually; in that case. You need to include the PhysX headers/libs, which to be fair. I've never done with the mess, so I wouldn't know what would happen.
Okey!

I have a new question. Now when you have separated Ogre and NxOgre in this version it feels like the pipeline to PhysX is longer. The layers is like myEngine->MineOrYoursRenderSystem->NxOgre->PhysX. So Im just curios about the performance decrease(?) versus integrate PhysX directly into my project. But then the loss would've been Increased development time on my side. I know that you've spent a lot of time on NxOgre and if I was to make my own PhysX binding, I would've spend as much as time as you have. But then it cross my mind. NxOgre is made to suit a wide difference of project types. So perhaps making my own direct PhysX binding is not that hard? I'm not having any concrete plans on doing this at the moment, im too far unexperienced. But Im just curios, that's all (What exactly does NxOgre besides the PhysX->Ogre Rendersystem..? is one question I need an answer for first).

Correct me if Im doing any big assumption...

I've actually found it's faster than Bleeding, and most of the well used functions are optimised for speed anyway.

The current Ogre RenderSystem I wrote a bit pants at the moment. Once I do interpolation, cloth, fluid rendering, etc. It'll be much better.

Why create your own wrapper? The same reason why you wouldn't write a DirectX one instead of using Ogre. NxOgre does have some internal code working on; the accumulator for example, is one part you'd have to develop yourself. Managing shapes, and actors are another. People who use NxOgre don't want to do all of that.

@betajaen:
You just mentioned fluid rendering - do you have an idea when you will do that or which method you will use for rendering?
I'm curious because I'm just preparing a presentation and a paper about 'Real-Time Fluid Simulation and Rendering' for a seminar at my university.
And I thought about implementing some rendering algorithms (like Marching Cubes and Screen Space Meshes) myself later with the PhysX Particle Fluids and Ogre (and probably NxOgre^^) to see what looks best while having acceptable performance.

I did give it some thought a while back, and though about marching cubes. But it was all reading and thinking, so nothing came of it.

Probably not for a few months at least, I'm afraid. My life at the moment is sadly busy. Besides I have a commitment to the character code before I start on anything new.

I might start working on it around April (after I finish this semester's projects etc. and made some progress on my Ogre game project)...

Why create your own wrapper? The same reason why you wouldn't write a DirectX one instead of using Ogre. NxOgre does have some internal code working on; the accumulator for example, is one part you'd have to develop yourself. Managing shapes, and actors are another. People who use NxOgre don't want to do all of that.

Okey, I see. Nothin to worry about then.

When will there be Joints available in Mess? I need it for my project but I can't find anything in Mess. I'm thinking about write it my self (into NxOgre ofc). However, I don't want to waste time on something that you, betajaen, might already working on !?

I pesonally could need Triggers. Did I miss something or don't they exist yet?

WTF?

Ogre: 1.6-SVN trunk
NxOgre: 1.5.2
MSVC Prof 2008
Bck (it's 3 a.m, so maybe I do not see something obvius, so easy on me ...)


1>------ Rebuild All started: Project: OGRECake, Configuration: Debug Win32 ------
1>Deleting intermediate and output files for project 'OGRECake', configuration 'Debug|Win32'
1>Compiling...
1>OgreCake.cpp
1>Ogrelicious.cpp
1>c:\sdk\nxogre\bloodycake\ogrelicious.cpp(546) : error C2664: 'Ogrelicious::fill_all_ptr' : cannot convert parameter 2 from 'Ogrelicious::FastConstIterator<T>' to 'Ogrelicious::FastConstIterator<T> &'
1> with
1> [
1> T=Ogre::RenderSystemList
1> ]
1> and
1> [
1> T=std::vector<Ogre::RenderSystem *,std::allocator<Ogre::RenderSystem *>>
1> ]
1>c:\sdk\nxogre\bloodycake\ogrelicious.cpp(685) : error C2664: 'Ogrelicious::fill_all' : cannot convert parameter 2 from 'Ogrelicious::FastConstIterator<T>' to 'Ogrelicious::FastConstIterator<T> &'
1> with
1> [
1> T=Ogre::StringVector
1> ]
1> and
1> [
1> T=std::vector<Ogre::String,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char>>>>
1> ]
1>Generating Code...
1>Build Time 0:12
1>Build log was saved at "file://c:\sdk\NxOgre\BloodyCake\Debug\BuildLog.htm"
1>OGRECake - 2 error(s), 0 warning(s)
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========

add an & to that operator when parsing it, check the definitions and it should work.

The problem is, that it compiles nicely with Ogre 1.6 stable. It is problem only, if I compile it against Ogre 1.6-svn-trunk. That is interesting ...

Maybe a stupid thing to ask, but ...

Let's say we want to model a car. It is made of about 100 .mesh file. What direction should I start thinking, if I want to attach the whole together, like if I move the base of the car, all physical and visual parts would move with it? Is it possible to attach actors/ogrebodies together with the tools already exist, or should I deploy a specific class for it?

BTW, how to load .nxs into 1.5.2?

Kevin, You should use bleeding/1.0.Tx, there are no wheels or triangle meshes in Mess yet. Bleeding is pretty much finished for the core parts; actors, shapes, joints, triggers, etc, that goes for everyone else who is thinking of using mess for their latest project.

And Apologies to everyone for my lack of presence; I've been very busy with something else, and it looks like I will be busy with it for a while. I haven't even opened the NxOgre Visual Studio project in a week, although I did test out hardware support - which went really well.

If only someone could invent a longer day.

When will there be Joints available in Mess? I'm thinking about write it myself (into NxOgre ofc). However, I don't want to waste time on something that you, betajaen, might already work on !?

and it looks like I will be busy with it for a while.

A while. Use Bleeding.

Okay. I'm back.

But in small amounts, in the evenings for about an hour. I've started work on the Mesh and MeshManager classes.

Just a question: Can you approximately say when Triggers will be done?

I'm thinking of a small game not needing more than simple actors and triggers. As I'd like to get used to the new version, I prefer to do it with Mess if this feature comes in the next time, otherwise I'd have to go back to Bleeding .

Not for a while.

Use Bleeding for now.

Although, I'm still extremely busy. I did work on Bloody Mess last night for a good few hours.

- I've been working on the ResourceSystem, Mesh loading and even writing some NXS functions (to identify a NXS file if given).

Eventually you will be able to load in meshes via archives (folders, zip files or websites) - provided you have the correct resource system loaded and written as so.

World* world = World::createWorld();
ResourceSystem* rs = ResourceSystem::getSingleton();
rs->registerProtocol(new Win32FileProtocol());
rs->registerArchive("media", "file://myMediaFolder/");


Load a mesh from an archive (media) so it can be used with a Convex shape or TriangleGeometry:

MeshPtr mesh = MeshManager::getSingleton->load("media:bunny.nxs");

Or if I had a load of nxs files, and didn't know what was what, I could find out:
ResourcePtr resource = rs->open("media:bunny.nxs");
Enums::MeshType type = Enums::MeshType_Unknown;
if (Functions::NXSFunctions::isNXS(resource))
{
type = Functions::NXSFunctions::getMeshType(resource);
}
resource->close();
return type;

Hi, Im planning on using NxOgre in the future. However, I cant get bloody cakes to compile ( I want to test i can get it working). I get the following error when compiling in debug:
1>Performing Post-Build Event...
1>The system cannot find the file specified.
1>The system cannot find the path specified.
1>Project : error PRJ0019: A tool returned an error code from "Performing Post-Build Event..."

And the following in Release:
Performing Post-Build Event...
1>The system cannot find the file specified.
1>'opy' is not recognized as an internal or external command,
1>operable program or batch file.
1>Project : error PRJ0019: A tool returned an error code from "Performing Post-Build Event..."

What am i missing. Whats OPY?

Cheers

Scratchy

Copy and NxOgre DID compile it just couldn't copy the DLL into the BloodyCake directory (which should be in the same folder as BloodyMess is in). As long as the headers and libs were copied to the SDK directory, then it's fine. You can just copy the NxOgre dll by hand using explorer if you want to.

The NxOgre math classes are a bit pants at the moment.
Only 1.5.2 or 1.0.22T5 too ? I found out, that rotating some objects f*cks up the quaternions, and actors stop coliding. Heavy colisions (like placing some actor within another few times) also screws quaternions/shapes.

The screenshot shows the problem


It was a well fited box on the robot. Then i let it colide with the tree triangleshape around 15 times (it was spinning between the branches, then it fell on the ground and began sliding*. I picked it and rotated once more, and then the box ended not even being a box... the quaternion is Quaternion(0.0683712, 0.446115, 1.54455, 0.283466) which seems wrong for me. Now the actor falls through the ground)

* sliding = quaternions f*cked up...

Maybe this are precision issues ? I used physx system software 8.10. Just installed 9.09 and the problem persists (or it needs a system restart which I haven't done yet).

PS don't care about the "character" shape type in the right menu. It's actualy just a box within the editor. The game will create a character for itself.

It's MY Matrix44 Quaternion conversion code. I found out months ago, but haven't gotten around to fixing it yet.

What you need to do is, get the Matrix4 directly from Ogre and just copy the values directly over to a Matrix44. If your using the OGRE3DRenderSystem, there is a function already written.

I've been away a while. Glad to see progress. I look forward to using 1.5 in my game when it's usable.

Hi, i have a (probably very very dumb) question... im looking into implementing physics into my app, but im deciding between wich physcs wrapper/engine to use...

Im looking into using this one... but im a little bit confused cause in the Nxogre page says the latest version is 1.022 then i come here and find there's a 1.5.2 version (wich acording to my super developed powers of deduction should be newer than 1.0.22), but it seems that threre are quite a lot of features missing in this version.

So... i'd like to know wich one should i use/evaluate for use in my app??

<edit>is there a feature's page somewhere that i missed/overlooked ??</edit>

Thanks in advance

As far as i know, This 1.5.2 is a complete rewrite of the original, and is not complete. 1.0 has the most features tho.

Cheers

Scratchy

Ok, then... i should use 1.0 for now and then switch to 1.5.2 ??
is this safe... i mean are these 2 versions compatible?? or will i have to rewrite all the physics stuff once the 1.5.2 catches up to 1.0.22 ??

Best regards

You will have to rewrite the physics stuff, as it's a complete rewrite and API-breaking. With the new version 1.5.X, NxOgre has been made render system independant, so you could also use it without Ogre (although there are special calsses for Ogre in it).

Basic features are already implemented in BloodyMess ( = 1.5.X), but Bleeding ( = 1.0.2TX) has a lot more atm.

Some more information can also be found here: http://www.ogre3d.org/wiki/index.php/Nxogre (is still in development this page; only exists for two days right now).

For the moment im mostly interest just in collision detection for a small RV demo, but we're looking into simulators development, so we want a physics engine that is as complete as posible... right now im inclined to use physx SDK directly, but if there's a reliable binding to ease our work we would surely use it (what i mean is how long will it be till it is fully usable?)

Or should i stick with Nidia physx SDK??

Thanks in advance