Ogre/NxOgre relationships - beginner questions

I'm fairly new to Ogre but I feel I've gotten the basics down. I've got a start going in plain Ogre and working fairly well. I hadn't planned on using physics much and doing just some simple collision tests manually but with the amount of collision tests I'll be doing and the amount of things I'll want the player to collide with and fall and such it seems best to use one of the physics addons.

PhysX I felt was the most stable so I started working a bit with NxOgre but I'm having some problems understanding certain things.

1) I understand that a "World" object needs to be created, but some posts have also mentioned a "WorldManager". Is this something I'm just not seeing that is in there or is it something that people are coding on their own? If people are coding it on their own, what makes it necessary?

2) What's the relationship between a World Scene and a SceneManager's Scene? Do you put the physics stuff in a World and the non-physics stuff in the SceneManager and there's no interaction between the two, they simply both exist on the screen and are completely independent? Or do you put everything in the World, and just disable physics for stuff that doesn't need to collide, have gravity, or move?

3) The terrain system is also confusing me. I know it's generating off a heightmap, but what's a .xhf file? Why not just generate it off a greyscale PNG? Any support for repeating or really large terrain? Anybody integrated nxogre with PLSM2?

4) Character system...I've read in another post that CharacterController is missing a few things. Apparently it'll be completed in 1.0'23, ETA? What's the difference between how it will work, and how the nxActor controller works?

5) I plan on having an entire level in a cave. Is there any way to do this within the built-in terrain system? I'm assuming I will have to have a mesh with all the normals facing inwards, would there need to be any special considerations in dealing with this in regards to the physics system? Will Ogre cull the mesh so that my entire level isn't loaded/drawn every frame?




I'm using PhysX 2.8.1, nxOgre 1.0'21, Ogre 1.49 Source, Visual Studio 2005 SP1



I've tried to keep these questions to things that I haven't found in other posts, and that I can't solve by simply glancing at the source code (which I'm reading through right now). My apologies if I've asked one that has been answered nicely someplace else. I also know some of the questions are related more towards Ogre and not nxOgre, but I've tried to ask only the ones that are at least in some way related.

No need to apologize. We all once new at this.


1. WorldManager is not part of Ogre. It must be part of someones application.

2. Scene holds all the Actors, Cloths, Characters, etc., it is rendered into a SceneManager. It's usually a 1:1 relationship, but you can have two or more scenes per SceneManager but the results may be a little crazy! They are held by the world. Just think of them as Sci-fi concept of alternate dimensions, and World is all of existence as we know it. But nothing physical goes in the World, it's all in a Scene.

3. Because it would be muggins here to write the code for it, besides "xhf" is more optimized than PNG for terrain. It also holds material information, and placement of holes in the heightfield. The terrain system is pretty open and you can easily have more than one heightfield/terrain in a scene so if someone has written it you can have PLSM2.

4. It will be more robust than the 0.9 system; It will have more features and allow you to more fluid like. My muse at the moment is the game "Mirrors Edge".

5. I'm pretty sure in Half-Life 2 they use terrain inwards for terrain. It would have to be four of them for each of the walls. I would try using a TriangleMesh before hand though.

Thank you very much, I've found this very helpful.


Now if only I could get ogre to work in debug. I had it working...then added NxOgre and I'm getting an Exception in ogreroot.cpp. It's saying that configFileName is a <badptr> even though it works fine in release (I have working dirs set and everything).

I have a question involving the tutorial by Italo Mendes. This is related to NxOgre/Ogre and not the tutorial itself so I'm asking it here rather than the tutorial thread.

Why does the plane in the tutorial here: http://ogre.irados.org/textos/bibliotecas/NxParte3.htm

Cause collision? Not so much callbacks and such, but if I place a body with y == 10, it falls, and stops on the plane. The plane is attached to Ogre's SceneManager, not NxOgre's Scene. So how does the actor stop at the plane? Is there hardcode somplace to make it stop at y=0 so that I need to make sure my ground is >= 0? I see no connection between that plane and NxOgre, so why is the NxOgre object landing on it like it's solid, and not just a mesh that it just slips through? Unless I'm mistaken the plane doesn't even exist in the NxOgre world. Insight on this?

Good Question.

What creates it is the "floor: yes" params in the SceneParams, which is a simple shortcut for the user for NxOgre to create an Actor in the Scene constructor for you.

createActor("Ground", new GroundShape(), Pose(), "static: yes");

You can try it by setting "floor: no" and using that code there with your mScene

AH!

So it's not the plane that it's colliding with at all, it's simply an actor with no mesh automatically created by the Scene constructor based on "Gravity: yes, Floor: yes" that is passed into it.

Okay, So that would explain why the model stops there, but I'm not sure why the SmartCamera from http://www.ogre3d.org/phpBB2addons/viewtopic.php?t=7615 doesn't, nor does it affect the mesh.

Edit: It seems like as I'm coming closer to the mesh I am actually nudging it in the slightest little bit, could it be the camera moving too fast? Searching more on the forums...

No, you won't be able to nudge it around. The ground plane can never move as it's "static".

Er...not nudging the ground...It seemed to be nudging another body that was also in the scene. After looking again it's not even doing that.

I was expecting the camera to stop...it's going straight through, that's what I'm confused about.

If you inherit from ExampleFrameListener, remove or comment the original camera position computing (no more need to compute this...), leaving keyboard and mouse inputs and if the camera is not attached to another node, don't forget to set it's new position based on to the attached actor.


bool frameStarted(const Ogre::FrameEvent &evt)
{
bool ret = ExampleFrameListener::frameStarted(evt);

if (!ret) return false;

... camera actor translations and mouse mapping code...

mCamera->setPosition(gCameraActor->getGlobalPositionAsOgreVector3());
...


The camera will collide with all defined static or dynamic actors. (or body...)

If is a static body, the camera will stop, else PhysX is applied.

Edit: mcaden, consider in using the visual remote debugger tool, all PhysX stuff is rendered into this tool, so you can easily compare the effective render and your PhysX world.

If you have attached the camera to another node (like the SmartCamera example code), there is no need to set the position manually.

Thanks Rasengan, that worked like a charm. I just got rid of all example stuff dealing with key input since I deal with all of it on my own based on the SmartCamera code.

BTW, I plan on using a lot of what I learn in this thread and working on my own in order to make some tutorials/guide. Hopefully it'll be of use.

EDIT: Re the debugger. I'll certainly do that For now I'm heading to bed but next on my todo list is to do the debugging thing, then figuring out how to make my new SmartCamera not apply its force to other objects. Since it's supposed to be a 3rd-person view rather than a first person view I want objects to be able to push eachother, but the camera should only slide along them. Then I'll work on attaching the camera to the player and moving the actual player.

I'm not using directly the SmartCamera class but some parts of translations and rotations code from it, so thanks to BJ for helping me most of the time

I'm certain I'll evolve away from it. As I said in my above edit (although it might not have been up by the time you replied) I need a 3rd person view camera...I'm thinking similar to World of Warcraft for camera controls.

SmartCamera is merely a start.

I would attach the Camera to the Body of the SmartCamera's scenenode, combine that with interpolation it should smooth things out.

As for one way collisions; you could try messing around with dominance groups; The SmartCamera would be less dominant than the other actors, and will not be able to push things around.

I was planning on attaching the a yaw and pitch node to the Character's SceneNode and attaching the SmartCamera to those nodes...That way I could have fully controllable camera movement while still moving with the character and colliding with objects.

And the dominance groups sound like exactly what I need.


EDIT: And thanks for the debugger tip Rasengan. I got it working after searching the forums. I'll work on the camera stuff tomorrow. My dilemma at the moment is whether or not to implement my own character system, or wait for NxOgre 1.0'23...decisions, decisions...

Dominance groups...

The only code examples I can find to show syntax and working between the 2 apparently don't work in 1.0'21. Structure has changed or something.

I'm still working towards it at the moment but if somebody can point me in the right direction I'd appreciate it.


EDIT: I also started looking into scene loading. A thread was started about 2 years ago about converting from dotscene to work in NxOgre and one of the last posts says a release would be finished 'soon'...then nothing. In addition to that there's like 3 dotScene loaders I've seen on the forums/wiki and again the posts are about 1-2 years old. I've seen posts referring to NxScene but there's no converter to, or exporter that I can see, nor file specification.

From what I understand there is a file format/loader for NxScene? I can write an exporter from Blender if there's demand but it'll take a bit more research on Blender's API on my part. I haven't coded anything in Blender in about 2 years I know python fairly well, but not the Blender API for objects, a GUI for the exporter, nor the best way to go about settings like mass, density, and dominance groups (which I still don't understand).

Re: Dominance groups. I've found a member variable, but no interface really to it, nor way to know what to set that variable to. It's obviously an unsigned int, but what do I put there? Is 0 lowest in some sort of hierarchy, or is it simply a group number with different group numbers not transferring force?

EDIT2: Meshes, by using .mesh am I slowing down Ogre? Do I need to convert ALL my meshes using flour or just certain ones?



I really am trying to stick to questions that can't really be found on the forums. And as I learn about things I'm trying to write down topics, explanations, concepts and such that I can turn into some tutorials or at the very least a FAQ about how to use NxOgre.

Dominance groups:

actorParams.mDominanceGroupAsIndex = 1;

Simple enough. 0 is default, and apparently the highest. Each number higher is one level less dominant.

I haven't worked on scene loading yet.

Camera control in 3rd person is tougher...I wanted it to collide with the wall and objects, but as a 3rd person camera there doesn't seem to be a good way to implement it if the camera is colliding. you can move it forward/backward/left/right by duplicating the force attached to the player, but there's huge problems foreseeable before that's even implemented like turning the player, and rotating the camera around the player, or if you're moving the player and the camera hits something...it will become mis-aligned.

It seems I'll have to implement the camera using raycasting and parenting scenenodes.

As for the .mesh question - still looking.

Nope, the ID is just an ID.

You create two (or more) dominance groups, and pair them together. Then you specifiy (as a float) how one group is dominant over another. Say a Horse is more dominant than a Fly. So when a Fly hits a horse - the horse won't move, or when the horse hit's a load of flies - it's velocity won't slow down.

DominanceGroup* mHorse = mScene->createDominanceGroup("Horse");
DominanceGroup* mFly = mScene->createDominanceGroup("Fly");
mScene->setDominanceGroupPair(mHorse, mFly, 1.0, 0.0f);

It's all in the PhysX documentation.

Now THAT makes much more sense.

Setting it to 1 worked though... Well, it didn't 'work' I suppose but it accomplished what I wanted it to do. Since I'm gonna remove the physics from the camera (unless somebody can show me a better way) I don't need it for the camera, but I'll definitely use it for other parts of my game, thanks.

I had a question about Flour: is the format it changes triangle meshes to intended to replace the .mesh? or is that merely what is used for collision?

Ogre Mesh are used for rendering in Ogre. I only used them in 0.9 because everyone used them, it has to be converted into a native format anyway. And I dropped it completely in Bleeding when I developed flour.

Personally; I would like to remove converting Ogre meshes in flour completely and replace it with a more modeler friendly format such as obj. At least then I can drop the Ogre dependency and the file size and compile time will be shorter.

So if I understand this right, if I convert using flour it will be faster, but I use NxOgre to load it, not Ogre.

Is the flour-generated mesh used in collision, or merely display?

And if going for ease of use, why not just add a command line call in the ogre exporters to flour at the very end? It'd more or less be a :modeler tool:-to-NxOgre converter (albeit inefficient due to the intermediate step of the modeler already converting to the ogre format...but it automates a step).


Ah well, Next I start dealing with raycasts between the player and my camera to deal with camera collision that way.

It's used for collision. NxOgre tries to avoid using Ogre as much as possible, and if it does it's done through the RenderSystem abstractly.

Ok, After every post I research more.

So Ogre uses the .mesh to display it, and NxOgre uses the .nxs for the collisions.

Triangle meshes only work on static actors (so - buildings, a small bit of terrain not attached to a heightfield, a tree that is too big to be pushed over...yes?). So for things that should be movable I need to use a convex shape.

This brings up another quests, convex meshes don't animate or anything based on a .skeleton file, so they present a bit of a problem for a character right? For a human I suppose this wouldn't really be too much of an issue...not a lot of "in-between" space, but what about something like a dog where the legs move a lot when running...do you usually just settle for colliding as an "at rest" pose?

Convex for dynamic actors - to a point. Sometimes you can't use them; such as a concave i.e. a rubbish skip, then you would use several cubes or several convexes.

Animated ragdolls for dogs most likely, but that's a tricky subject.