bullet

[lgromanowski]

Hi everyone,

I know how to use bullet, and I would like to contribute to this project. But I don't know exactly where to start (to be honest, the source code is a bit overwhelming). I figured out that it might be best to do something like the render stuff in the oengine, but for bullet. Am i right?
Also, while reading the source code, i noticed that almost everything was related to rendering, and there is no mention of physic, so i am a little lost^^


BTW:the .exe i downloaded crash woth some OpenAl related error.

hi,

Let me explain "no bullet stuff". Old D code had this, new code does not. The problem is that nobody knows how to scale up and down meshes for bullet. We need this because it's morrowind feature and without it the game won't work fine.

The good place to start is right here: find the correct, effective and performance wise way to scale up and down collision meshes.

I think i can manage to scale shape with bullet.
I don't know how morrowind works, so are there some special mesh for collisions?

I found how to scale things with bullet:
when you create a shape, just call:
yourshape->setLocalScaling(btVector3(x,y,z))

BTW: why do you need to scale shapes?(for which kind of object?)

Edit:I don't really understand how objects are stored. For exemple, let's imagine there is an book in a cell. How is it's position stored? is it independent of the rendering? And if the physic Engine make the book move, to who must the physic engine tell that the book moved? The rendering engine? Or something else?
I am under the impression that the "game engine" is realy dependent of the rendering part.

Welcome!

To get started, you may want to get yourself set up on github (see wiki dev setup) and get familiar with everything.

I've already done that (thanks to the wiki, which is really helpful for that!), but i am still a little lost with the overall architecture of the programm. Are there some kind diagrams which explain who is doing what?

Edit: playerpos.hpp is in ther render directory. But:

// This class keeps track of the player position. It takes care of
// camera movement, sound listener updates, and collision handling
// (to be done).

So shouldn't it be outside of the render? And as far as i understand, this class handle everything the player do. Am i right?

I haven't given any thought to the bullet integration. The general idea was, that Nico would do it, since he was involved with the D implementation and therefore has the most knowledge about this topic.

Anyway, after taking a quick look around, this is how I see the task:

1. Integrate bullet into the build system (cmake).

2. Get the collision meshes out of the nif files and into bullet.

You should look at components/nif and components/nifogre. The later one is handling the Ogre-integration. I would expect that Bullet is best handled in a similar way, probably even with a new nifbullet component.

3. Initialise the bullet library and get collision data into bullet using the component mentioned above.

I suggest we "abuse" the mwrender subsystem for this task. Rendering via Ogre will largely work in parallel to sending the collision data to Bullet. Therefore it would be wasteful and make everything more complex, if we set up a new sub-system here.

A few points to note:

- The top-level Bullet object (I assume there is one; no clue about Bullet) would best go into mwscene.
- The implementation must be able to remove collision meshes per cell.
- Given a collision mesh, the Bullet implementation must be able to provide the matching object handle (a std::string).

4. Replace the Ogre raycasting for the activation function (working with axis-aligned bounding boxes) with something from Bullet (working with the real collision meshes).

At this point it is probably best to take a break. We are not ready yet to implement actual collision detection for the player.

Lol. too many edits. Almost missed this one:

Edit:I don't really understand how objects are stored. For exemple, let's imagine there is an book in a cell. How is it's position stored? is it independent of the rendering? And if the physic Engine make the book move, to who must the physic engine tell that the book moved? The rendering engine? Or something else?

The physics subsystem can't move objects. For now its purpose will be to handle player movement and the activation function. If we make objects moveable this would probably break tons of mods and maybe even Morrowind.
At a later point we might consider a special "physics-enabled" flag, but that is post 1.0 stuff.

Edit: playerpos.hpp is in ther render directory.

The playerpos class is on the refactoring list. Most likely it will be gone soon. I wouldn't bother with it.

BTW: why do you need to scale shapes?(for which kind of object?)

Any kind of object. There is a script function, that lets you scale objects at will. Also each reference contains a scale factor (see components/esm/loadcell.hpp).

I've already done that (thanks to the wiki, which is really helpful for that!), but i am still a little lost with the overall architecture of the programm. Are there some kind diagrams which explain who is doing what?

At the moment, we take tasks in an ad-hoc sort of fashion, but current tasks are on the roadmap with assigned folks. (not written in stone, of course, feel free to help and cooperate with each other.)

This is where my commitment has failed - There are currently some class and function charts generated by deoxy laying around someplace, as well as some of my own work in "Star's guide", which is really in an early phase of development and requires a lot of input from our current coders.

There was a chart laying around someplace, but it's probably changed a bit and we'll be needing many more.

One week left until I'm done with the semester, folks. then you'll see a lot of work integrated into the wiki and a real push to get more help.

I've started to read the doc of the .nif files (i am a complet noob with this file format), and it's weired because the only info about collisions i found where bounding boxes
And i was wondering: the exterior is stored in a highmap, and the interior is just .nif, right?

The landscape (in exteriors) is a heightmap, yes. Everything else (interior and exterior) is handled via objects, that have an associated nif-file.

You can ignore the heightmap for now.

Ok.
So far, I see 3 options:
1)I missed something in the .nif doc and there are actualy info about the collision shape.(i only found references to NiCollisionObject for higher versions than morrowind)
2)Morrowind use only bouding boxes.Not really user friendly
3)Morrowind use only trimeshes for collisions.Not really CPU friendly^^

Option 1) seems very likely

So do you know how morrowind handle collisions?

PS: heighmap shouldn't be hard to implement with bullet as long as data are aloready extracted for Ogre

Ps2: excuse my poor english^^

Absolutely no idea. But we had a working implementation in the D version. Have a look at old_d_version/bullet.

if you don't feel comfortable with D you can also check the Crystall Scrolls.

So do you know how morrowind handle collisions?

I don't know if this is what you want to know but I can say from my experience that Morrowind uses the mesh within The NiCollisionNode whenever one is availible.

If there is no NiCollisionNode (applies for many BM-meshes), collision is based on the other meshe/s.

If a NiStringExtraData with the Value NCO is attached to a ninode all of the geometry below it is ignored for collision. If the latter is attached to the first node of the nif-file, the object has no collision at all.

In vanilla morrowind minor plants usually have NCO set in their first ninode. I have seen trees (Vality's bc-trees for example) that have no NiCollisionNode but have a NiStringExtraData with NCO added in the node that contains the foliage. So you collide with the trunk but not with the foliage.

Thanks a lot! that was exactly what i was trying to figure out! You saved me a lot of trouble
Does it use the bounding boxes for geometry sometimes?

And thanks for the tips with the D version/Crystall Scrolls!
In fact, i had a look at the D version, and it seems that it only use bullet for collision detection, and not for collisions responses. I wonder if it would not be better to le bullet also control the collision responses. On the one hand, it would mean easier modifications, but on the other hand, it might give a slightly different result.

As i reread this post, i noticed that i don't understand this:

Given a collision mesh, the Bullet implementation must be able to provide the matching object handle (a std::string).

What did you mean?

(Nearly) Each mesh in the 3D scene belongs to an object (weapon, building, NPC, ...). Each of these objects is identified by a unique string. The collision system must be able to deliver this string upon detecting a collision with an object.

Oh ok!

in ogre_nif_loader, is says:

Manual resource loader for NIF meshes. This is the main class
responsible for translating the internal NIF mesh structure into
something Ogre can use. Later it will also handle the insertion of
collision meshes into Bullet / OgreBullet.

for NifLoader Class. But i think that you need a different ressource Manager for each ressource, so we would need to create another class for bullet. Am i wrong?

You could create another resources manager within the Ogre resources system. But I am not sure how useful that would be considering, that Ogre isn't using the collision data.

I guess Bullet does not have any means of storing named collision meshes that then can be inserted into the physics scene? In this case you have to
- either create your own resources management,
- re-use the ogre mesh resources manager (collision meshes are not much different from meshes for rendering, right?) or
- create a separate Ogre reousrces manager for it.

Which option is most suitable, I can not say, since I don't have any experience with Bullet.

btw. does that mean you have decided to do the physics tasks? IIRC you had problems with integrating Bullet via CMake. Can someone else help him out with that?

I have thought about picking up the task. But to be honest, i sometimes don't feel like I understand the way Morrowind/OpenMW/Nif files works enough to get the job done correctly. So:
1)if someone else wants to pick up the task, i would be glad to help him with bullet related stuff.
2)If absolutly nobody wants to pick up the task, i can try to do it.

I would prefere option 1.

So why am i discussing about that if I would prefere not taking the task? Because i hope it will help others.

I guess Bullet does not have any means of storing named collision meshes that then can be inserted into the physics scene? In this case you have to
- either create your own resources management,
- re-use the ogre mesh resources manager (collision meshes are not much different from meshes for rendering, right?) or
- create a separate Ogre reousrces manager for it.

Which option is most suitable, I can not say, since I don't have any experience with Bullet.

Actually, there is no difference for bullet, as long as it's easy to acces collision shapes. I think we have to use option 3): we could take as a base the NifLoader/mesh ressource manager classes, and adapt them for collisions shapes.

My first choice was option 2),but collisions shape are not rough mesh in all cases (it can be a bounding box for exemple,or a capsule for NPC),and it would avoid names problemes (the graphic mesh would have the same name than the collision mesh).

1)if someone else wants to pick up the task, i would be glad to help him with bullet related stuff.
2)If absolutly nobody wants to pick up the task, i can try to do it.

I guess it will at up as 2), because we don't have that many coders and probably none of them has the time to take up a task of this size in addition to their other work.
I can assist you with advice on the non-Bullet/non-NIF part. Maybe someone else can provide some input on the NIF part.

Ok. So i will give it a try

Question about NIF:
The transfo of a node is the its transfo + transfo of its parent right?

I have done some works with the Nif Loader.
But i need to test it now, so i would like to know if there is some good mesh to test collisions with. For exemple, for the test with Ogre, you used "meshes\\ex_ashl_a_banner_r.nif" , and as i don't know any of the morrowind mesh , is it possible to have a mesh relatively large with collisions? (a house maybe?)

Try ex_hlaalu_b_24.nif. Might be located in a sub-directory.

In fact, i have abolutly no idea of how to open a BSA archive^^ So if you could give me the complete path, it would save me a lot of time!
Thanks

Sorry, I have no means to open a BSA either. I think there are some tools, but I have no idea where to find them. Note, that on the original MW disc (the one with the construction set) there is a complete directory with all resources files, that are found in Morrowind.bsa. Also, if you have access to a Windows box with MW installed on it, you could try to look it up in the CS.

http://www.tesnexus.com/downloads/file.php?id=12189

While trying to compile my test project (and solving millions of linker errors), i saw this in strings.h:

Code: Select all

// Wrapper for MSVC
#ifndef _STRINGS_WRAPPER_H
#define _STRINGS_WRAPPER_H

#ifdef WIN32
#pragma warning(disable: 4996)
#define strcasecmp stricmp
#define snprintf _snprintf
#else
[b]#include <strings.h>[/b]
#endif

#endif

WTF?

and in stringops.cpp i get error C3861: 'strlen' identifier not found.
What should i do?

PS: IMO there should be some separate .lib which handle misc stuff, it would be a lot easier to make some test project.

Your on Windows? Than make sure, that the preprocessor macro WIN32 is defined.

While trying to compile my test project (and solving millions of linker errors), i saw this in strings.h:

Code: Select all

#include <strings.h>

WTF?

Should not be a problem unless you add libs/platform/ as an include path.

gus wrote:
While trying to compile my test project (and solving millions of linker errors), i saw this in strings.h:
Code:
#include <strings.h>

WTF?


Should not be a problem unless you add libs/platform/ as an include path.

Right, but what is the point for a .h file to include itself?

Your on Windows? Than make sure, that the preprocessor macro WIN32 is defined.

I will check this, thanks

gus wrote:
While trying to compile my test project (and solving millions of linker errors), i saw this in strings.h:
Code:
#include <strings.h>

WTF?


Should not be a problem unless you add libs/platform/ as an include path.

Right, but what is the point for a .h file to include itself?

It is not including itself unless you add libs/platform/ to the include path.
If you want to include that one you go
#include <libs/platform/strings.h>

#include <strings.h> will get you the strings.h that is in the include paths, which will probably be /usr/include/strings.h.

So basically what the libs/platform/strings.h do is:
If you have msvc do some defines, otherwise include the normal strings.h.

Thanks for explaining me!

To define WIN32 made it work.

Sorry to bother you with stupides questions,but where is the function addBSA defined?

components/bsa/bsa_archive.hpp

Okay, i got it working!

Currently, it create a new resource type for ogre, and there is a manual loader that load shapes. I've tested it with bullet, collisions work fine.

There are only 4 things left:
1)bounding boxes stuff
2)use RootCollisionNode? does every object has a rootCollisionNode?
3)there is no unloading of ressources for the moment.
4)learn git^^

don't worry about git : http://openmw.org/wiki/index.php?title=GitHub_FAQ

git isn't so bad - it just takes practice and a little knowhow.

Baby steps.

I suggest learning git first. A version control system makes coding more comfortable. Also, it will allow you to show us your work more easily.

Sure, but i'm really not used to this, and i guess i will need some help at some point^^.

I looked in the roadMap,and i saw that you intend to replace Ogre raycasting. Unfortunatly, this can't be done with bullet. Collisions shapes provided by nif files are approximated, and many object doesn't even have a collision shape, so raycasting with bullet won't work. Furthermore, there might be some trouble with animations.
But i found this: http://www.ogre3d.org/tikiwiki/Raycasti ... raycasting
Which improve the current Ogre raycasting (the current Ogre raycasting only use bounding boxes). I think it work for us.

Edit: wrote nonsense. Forget about it.

Right, i think it won't work with batching. There is still another option: create 2 collisions shapes for each object, one for collisions,and the other one for raycasting. The shape of the second one would then be the complete trimesh. This would not require much work, and it might be more accurate than the Ogre one, but it cannot take animations into account.

Edit: you edited your nonsense xD

The loader is finished. It can load/unload resources, use Morrowind collisions mesh, and it's documented.
Now i need to push it on git. I searched the wiki, and i saw that i need to create a new branch. I am trying to do it.

Edit: everything works fine with my fork, but i can't push on zini fork: i get this error:

ERROR: Permission to zinnschlag/openmw.git denied to gugus.
Pushing to [email protected]:zinnschlag/openmw.git
fatal: The remote end hung up unexpectedly

No, you can't push to my fork, because it is mine.

I see your fork, but I also see the following problems:

1. Your git isn't configured correctly. No identity information

2. The 2nd commit is missing adjustments to the cmake file.

3. You are branching off from a very old version. Please merge my master branch in and don't forget to do a submodule update after that.

btw. since the identity part of your git installation isn't configured correctly, you also might want to check, if your line-ending configuration is correct.

2nd try:

looked in the roadMap,and i saw that you intend to replace Ogre raycasting. Unfortunatly, this can't be done with bullet. Collisions shapes provided by nif files are approximated, and many object doesn't even have a collision shape, so raycasting with bullet won't work.

Are you absolutely sure about that? Unless my memory is playing tricks on me, at the Redemption project we had once the situation with a custom model, that had problems with its collision mesh which resulted in problems with activation. This would suggest, that Morrowind is using the additional collision data for activation, which means they must be good enough.

1. Your git isn't configured correctly. No identity information

What is identity information?

2. The 2nd commit is missing adjustments to the cmake file.

That's normal, since i did not touched the CMake file^^. In fact, i had to completly hack(hard coding path , etc) my own CMake file to make it work.

You are branching off from a very old version. Please merge my master branch in and don't forget to do a submodule update after that.

That's strange. I thought i had updated it. Im must have done something wrong. How should i update it?

btw. since the identity part of your git installation isn't configured correctly, you also might want to check, if your line-ending configuration is correct.

What is this line-ending configuration stuff?

No, you can't push to my fork, because it is mine.

Ok


edit:

Are you absolutely sure about that? Unless my memory is playing tricks on me, at the Redemption project we had once the situation with a custom model, that had problems with its collision mesh which resulted in problems with activation. This would suggest, that Morrowind is using the additional collision data for activation, which means they must be good enough.

Almost. I just opened some random .nif, and in many of them, there where no collision info (rings for exemple), but they could be picked up.
Did you saw the alternative approach i proposed with bullet?

github has all the documentation you need. Especially:

http://help.github.com/dealing-with-lineendings/

and

http://help.github.com/git-email-settings/ (only the "Setting user name and email globally in git" part).

As for updating, fetch from my fork and then (while on your branch), merge in my master branch. No idea if it will apply cleanup. Maybe it will produce some conflicts, that have to be resolved manually (consult a git manual of your choice). After you have merged successfully, do a git submodule update.

This one?

There is still another option: create 2 collisions shapes for each object, one for collisions,and the other one for raycasting. The shape of the second one would then be the complete trimesh. This would not require much work, and it might be more accurate than the Ogre one, but it cannot take animations into account.

I don't know. Sounds very inefficient. We would end up with three different representation of each mesh (one of rendering, one for collision, one for raycasting).

That's right, but is memory a problem anymore?
Still, it might not be that inefficient, as Ogre probably store most data in the graphic card memory, duplicating them into the RAM be faster than to read them on the graphic card memory.
And raycasting algorithm might be better in bullet.

Ps: is my git repo better now?

Nope. Your master branch looks okay, but the topic branch is still outdated.

The identity fix will not show up until you make another commit.

The line ending problem (if there was one at all), will not show up, until someone else is using the code you have committed before fixing it (at which point that person has a sizeable headache to deal with).

That's normal, since i did not touched the CMake file^^. In fact, i had to completly hack(hard coding path , etc) my own CMake file to make it work.

That is not what I meant. If you add new source files to the project, you must edit the corresponding CMakeLists.txt files or the project won't build correctly.

btw. any CMake-expert here, who would be willing to give gus a hand with integrating Bullet into our build system?

Git is driving me crazy. In my last attempt, i tried to clean up delete the collisions branch, but i can't! so i created a new collision2 branch, but there are some change of the old collisions branch....
I am now trying to delete my openmw fork to create a new one, but i can't find where to do it..
Edit:This is crazy. I deleted everything: the repo and my local clone. But the changes i did in the old collisions branch are still there

Git is driving me crazy. In my last attempt, i tried to clean up delete the collisions branch, but i can't!

To remove a local branch you use git branch -d <branc> or git branch -D <branc>, the difference is that the first one will try to make sure everything is merged so you don't loose anything.

To remove a remote branch you use push
git push <remotename> :<branchname>

so i created a new collision2 branch, but there are some change of the old collisions branch....

I'm not really sure what you mean here.

Well, looks like you sorted the problem out. With the brute force method, but okay (did that once myself, when I was starting to use git).

There is still another option: create 2 collisions shapes for each object, one for collisions,and the other one for raycasting. The shape of the second one would then be the complete trimesh. This would not require much work, and it might be more accurate than the Ogre one, but it cannot take animations into account.

I checked with an external expert. It seems your original assessment about the collision information handling in MW is correct.

You mentioned, that rings usually don't have collision data. Do I see a pattern here? A ring is a small, simply and compact object. Do all/most of the collision-less NIFs share some of these properties?

Could it be, that MW is using

a) either a bounding box

b) or the original mesh (used for rendering)

for the collision detection when no collision data is available?

For a small compact object like a ring or a coin using the bounding box would yield almost equally good results compared to using the full mesh.

For low-poly objects it wouldn't make much of a difference either if the real mesh is used or a simplified collision shape.

I think this topic needs some more research. If you remember back playing MW, the aiming mechanism doesn't have too much precision. Its usually good enough, but this probably indicates, that MW is reusing the collision information for the aiming too. I suggest we do the same. Maybe we can offer post-1.0.0 an option to do aiming checks against the actual mesh on polygon level or whatever (for people with more powerful machines).
.

From the Redemption forums (from our chief 3D artist):

I don't create a collision mesh as long as it is not needed. I think they are important for creatures, but not for simple statics or activators. If I want to make a model that the player can walk through, I create an object called "no-collision" within the 3Ds Max file. This object (normally a box) is invisible when I export the NIF file and triggers the whole model permeable.

I think that is something we need to consider. Especially the 2nd part.

Could it be, that MW is using

a) either a bounding box

b) or the original mesh (used for rendering)

for the collision detection when no collision data is available?

I checked on morrowind, and there is no collision detection with small objects (ring, books,forks,etc). And the raycasting is very accurate with small object, but not with bigs one.
So my guess is that as I said, morrowind use the collision data for collisions (if there are no data, there are no collision), and it will try to use them for raycasting, but if there are none, it will fall back on the complete trimesh.

For a small compact object like a ring or a coin using the bounding box would yield almost equally good results compared to using the full mesh.

For low-poly objects it wouldn't make much of a difference either if the real mesh is used or a simplified collision shape.

The probleme is that Morrowind provide no bounding box (i checked), and no simplified mesh. As i said before, it seems it use the complete mesh. Of course we could simplify the mesh with bullet (convex shapes) to help performances, but as unsing the complete worked with the original Morrowind, there is no reason it will be too slow now.

I don't create a collision mesh as long as it is not needed. I think they are important for creatures, but not for simple statics or activators. If I want to make a model that the player can walk through, I create an object called "no-collision" within the 3Ds Max file. This object (normally a box) is invisible when I export the NIF file and triggers the whole model permeable.

I think that is something we need to consider. Especially the 2nd part.

I am not sure what it mean exactly (excuse my poor english :s). I am not familiar with activators in morrowind. Could you describe it a little?

To remove a remote branch you use push
git push <remotename> :<branchname>

It didn't work.(weired errors^^). But thanks!

Well, looks like you sorted the problem out. With the brute force method, but okay (did that once myself, when I was starting to use git).

There are still some strange stuffs, but it seems OK.

I am not sure what it mean exactly (excuse my poor english :s). I am not familiar with activators in morrowind. Could you describe it a little?

Just another ID category. Not important. I am talking about this part.

I create an object called "no-collision" within the 3Ds Max file. This object (normally a box) is invisible when I export the NIF file and triggers the whole model permeable.

There must be some kind of flag in the NIFs, that exclude them from collision. Using the 3Ds Max exporter, the flag is apparently set by creating an object named "no-collision".

This is a bit weired, but there are also some strange stuffs with Nif files.

1)there is a RootCollisionNode that indicate collisions mesh
2)but there seems to be flag "NCO" which indicate "no collision". What's the point of this flag as every mesh that is not a child of the RootCollisionNode will not be used for collisions? To be honest, i have checked some Nif files, and i never saw this flag.

Maybe this indicate that the object should not be included in the raycast test too?(as raycast use the real mesh when there is no collision mesh)

Edit:this can't be true. I checked and found some objects you can pick up, with no RootCollisionNode, and with the flag "NCO". But i noticed all these objects seems to be plants.

Quote:
I create an object called "no-collision" within the 3Ds Max file. This object (normally a box) is invisible when I export the NIF file and triggers the whole model permeable.


There must be some kind of flag in the NIFs, that exclude them from collision. Using the 3Ds Max exporter, the flag is apparently set by creating an object named "no-collision".

Could you ask him how he create a collision mesh? I think that's might be the key. My guess: when you don't create this "no collision" object, the exporter will turn your whole mesh in a collision mesh using the RootCollisionNode, and if you create it, the RootCollisionMesh will be empty. That's nasty, but it might be the case.

I suggest we ignore the "NCO" flag for the moment(this can be easily changed), and see what's working, what is not working, and change later if needed.

Hello everyone, I am Spyder, the 3D guy from Redemption. Zini quoted me above. I don't understand everything you talk about here (e.g. I don't know what bullet or git is), but I know a bit about modelling for Morrowind.

Could you ask him how he create a collision mesh? I think that's might be the key. My guess: when you don't create this "no collision" object, the exporter will turn your whole mesh in a collision mesh using the RootCollisionNode, and if you create it, the RootCollisionMesh will be empty. That's nasty, but it might be the case.

I think it works as you say here: if you don't create an object called "no collision", the whole mesh works as a collision mesh.

Now lets say I want to make a bridge consisting of a lot of planks where the player could get stuck (or fall through) while walking over it. In that case I create a simple arch shaped object above the planks that is supposed to work as a collision mesh. Then I hide that object in 3ds max and export the NIF. That works fine in MW.

I think the same thing can be achieved by naming the collision mesh "Bounding Box". I think in that case all other objects in the file are made permeable, but I'd have to try that to make sure. Here is what a tutorial for modelling for MW states about Bounding Boxes:

The Bounding Box: A static mesh does not need a Bounding Box; it will export with no issues. However, an animated NIF will not be able to recognize the Root Bone unless there is a Bounding Box surrounding the entire mesh. The Bounding Box gives the mesh a collision boundary.

If you want me to, I can further investigate how the Bounding Box works. I could also send you some test files where I simply hid an object and where I created a Bounding Box.

EDIT: Okay, I checked it out. If I create a "no collision" object you can walk through the whole mesh (i.e. all meshes in that file). A Bounding Box added to the file becomes invisible in the NIF and does absolutely nothing (it is invisible and can be passed through). If I create a Bounding Box in a file without a "no collision" object also nothing happens. I conclude from that that Bounding Boxes don't do anything for statics. I wonder if they are exported into the NIF file at all.
Sorry if I am not much of a help here, but I can only tell you things I can see from my perspective as a modeller.

You are most helpfull You just told us what bouding boxes where for, and how NPC/creatures/non static handle collisions,which is essential.

Would it be possible to have an exemple of a .nif created with/without "no collision"?

Thanks a lot

I'm glad I could help.
Btw., I figured out that the Bounding Box has a purpose in a non-animated NIF, although it is invisible and can be walked through ingame: It tells the Morrowind Construction Set the dimensions of the mesh. When you click the object in the render window of the CS, the Bounding Box is what is highlighted to indicate the object is selected.
Here are the files you requested:
http://fs05n3.sendspace.com/dl/3c1b730e ... n_test.zip

Sorry, I forgot to log in. The post above was written by me obviously

Thanks!

I think a little more after looking atthe 2 .nif you gave me.

First, there is another flag for collisions: if you click on the flag button on nifskope, you can choose beetween collisions options:
1)none
2)Triangles
3)Bounding boxes
4)Continue

1) and 3) are OK. I don't understand 4).
With 2), i should check if it use RootCollisionNode when there is one(maybe that's the use of 4) ?)

So NCO seems to be the same as setting the flag to 1) . That explain a lot of things!

I will look deeper in 2) and 4).

PS: maybe i should write it somewhere in the wiki?

I think it is the moment to decide how we will handle the player collision response. Here are my proposal:


Bullet Character controller
pro:
-might solve the problem of NPC getting stuck.
-it open new possibilities like dynamic collisions with other objects (like in oblivion)
-might be faster to code

cons:
-might give a slightly different than the real Morrowind. (but is it important if you have a very small difference?)

The old way(as in the D code)
pro:
-exactly like morrowind

cons:
-exactly like morrowind^^ (NPS stucks)
-it will be very difficult to add dynamic collisions if we ever want to
-might take a little longer to code.

I prefer the 1st option.
And you, what do you think?

Generally preferring the 2nd. We already have a large part of the code in place (everything except the actual collision), so it should be less work actually.

Also, I don't know what you mean by dynamic collision.

In Oblivion you can kick almost every object. Objects are none static,so they are dynamic.
In morrowind you can't move objects by running into them, or throwing a fireball.

Assuming its easier to code, what would be the 'slight differences'?

and dynamic collisions are a choice.

The slight difference are:
-maybe a small difference of speed
-a difference in collision behavior. We would use a capsule shape instead of a box shape, which is more suited for NPC/player.

If the collisions are more accurate and NPC's won't have any issues with getting stuck. then im all for it.

when you mentioned speed, is it faster or slower to use method 1?
keep in mind we are trying to accommodate lower spec'd hardware.

I was not speaking of performances, but the speed of the player while running/marching.

But for performances, it should be the same.

Also, i can't guarantee that there will be improvement for NPC, but my intuition tells me it will be the case.

If the collisions are more accurate and NPC's won't have any issues with getting stuck. then im all for it.

NPC's get stuck mostly because they can't jump.

Not only. Last time i played, a creature (i don't remember which one) could not reach me because there were a table between us and it was stupidly trying to get through the table. The bullet solution would solve this kind of behavior i think, as instead of getting stuck, it will slide.

Somehow the forum has eaten up my previous post.

I understand now, what you mean with dynamic collision. And as I said before, I don't think we can use it. Parts (story elements and/or scripts) of Morrowind.esm may rely on objects being in the place the worldbuilder has put them.

As for the implementation route, since you are doing the work it is your decision (both options seem to be a valid choice). But we should make sure, that your code integrates well with the existing player controls.

Not only. Last time i played, a creature (i don't remember which one) could not reach me because there were a table between us and it was stupidly trying to get through the table. The bullet solution would solve this kind of behavior i think, as instead of getting stuck, it will slide.

Oh, man...I do not look forward to Havok Chaos...

I understand now, what you mean with dynamic collision. And as I said before, I don't think we can use it. Parts (story elements and/or scripts) of Morrowind.esm may rely on objects being in the place the worldbuilder has put them.

I can't recall if there are any scripts that require something in a specific place (if the object moves, usually it just requires a range within that object...if anyone can think of something speak up), but I think that we should add things to interface with bullet slowly.

Start with things the player can pick up and put down.

Statics like furniture, or the rest of the stuff in mwclass - probably should be thought about carefully.

I understand now, what you mean with dynamic collision. And as I said before, I don't think we can use it. Parts (story elements and/or scripts) of Morrowind.esm may rely on objects being in the place the worldbuilder has put them.

Dynamic collisions would not be the default behavior, as there is no mass in the .nif files. But it could be a post 1.0 feature: moders could then add a extra flag to tell it's dynamic. This way, it won't break anything.

As for the implementation route, since you are doing the work it is your decision (both options seem to be a valid choice). But we should make sure, that your code integrates well with the existing player controls.

I haven't thought of that. But isn't the player movement implemented as any NPC (with the difference that the inputs are from the keyboard and not from the AI)?

Also with dynamics objects (which would include NPC) bullet would have to tell OpenMW when these objects are moving. How is it done? (i haven't really looked deep in the code yet)


Edit:

I can't recall if there are any scripts that require something in a specific place (if the object moves, usually it just requires a range within that object...if anyone can think of something speak up), but I think that we should add things to interface with bullet slowly.

Sure, but with the effect of gravity, some objects might fall,etc thus breaking the whole game.

Statics like furniture, or the rest of the stuff in mwclass - probably should be thought about carefully.

I suppose we should let them static if we ever include a dynamic mode (that's the way oblivion handle things).

shouldn't we fix the AI of enemies, if there is a damn table it should go around it

dynamic collisions only really affected Items(clutter,weapons/armour etc), NPCs / Creatures and Arrows n Spells. everything else is static.

we don't really need dynamic collisions implemented now(the movement part of it). but a more accurate version(of vanilla) would be nice.

I haven't thought of that. But isn't the player movement implemented as any NPC (with the difference that the inputs are from the keyboard and not from the AI)?

Not really. This is a special case. Look into the MWWorld::Player class (preferably not the one in the master branch, but the one Star and I are currently working on).

Also with dynamics objects (which would include NPC) bullet would have to tell OpenMW when these objects are moving. How is it done? (i haven't really looked deep in the code yet)

Look at MWWorld::World::moveObject. But that is not how we should move the player. As I said the player is a special case (camera handling and such). Theoretically this special case could be handled with a callback, but I would prefer to not get into that, because it would be hard to implement.

So basically it should go like this: A function in Player will calculate a velocity vector. Your code (called from this place) has to adjust the player coordinates according to this vector and the collision data. Then the function will adjust the player position and the camera accordingly.

Sure, but with the effect of gravity, some objects might fall,etc thus breaking the whole game.

DO NOT APPLY PHYSICS TO THE MINISTRY TO TRUTH!



Lemme think about it. If I think of a static or some mwclass item that we don't want to apply gravity or inherited collision for, I'll list it.

Maybe I'll go over scripts and items today if I'm bored.

Oh...there's one. Azura's ring is floating in the statue's hands. (doesn't break game) There's one.

I don't understand why there is a distinction between NPC and the player. NPC also have collisions and such. Why making it different?

In my opinion, there should be a base class with some functions like
moveForward() moveBackWard etc.

And NPC/player should derive from that (maybe even creatures).

Lemme think about it. If I think of a static or some mwclass item that we don't want to apply gravity or inherited collision for, I'll list it.

Maybe I'll go over scripts and items today if I'm bored.

Oh...there's one. Azura's ring is floating in the statue's hands. (doesn't break game) There's one.

I am not sure. For example, if object initial is inside another object (might be the case with furnitures) it will lead to a strange behavior(usually the object will fly at high speed^^)

In my opinion, there should be a base class with some functions like
moveForward() moveBackWard etc.

And NPC/player should derive from that (maybe even creatures).

That would be a good design, yes. But we can't do that, because of a design flaw in the early stage of implementation (the esm record dumb structure problem). It is much too late to fix that. A few months ago I put a workaround in place, but we are still left with a somewhat exotic class design. There are classes for NPCs, creatures and such, but they are stateless and kinda complicated to use.

However you might be right about it, that the proposed approach it not optimal. Give me a day or so to think about it and maybe I can come up with something more suitable, that doesn't require a large scale rewrite or mingling with already overcomplicated parts of the design.

I am not sure. For example, if object initial is inside another object (might be the case with furnitures) it will lead to a strange behavior(usually the object will fly at high speed^^)

That's Havok Chaos. The more two objects' boxes collide, the higher force is applied - it results in really strange things. We have to slow a lot of this stuff down or cap its speed when exiting another's collision box.

Okay. That didn't took a day. We could do the following:

We put a desired movement direction into the NPC runtime data (which can be manipulated from outside either via AI or the input system).

The NPC class gets a function, which calculates (based on this direction and the skills/attribute) a desired velocity vector.

Each frame we go through all the NPCs (player is seen as an NPC here) use this vector as input for bullet, which in turn will move the NPCs via the function I mentioned.

In the Player class we add a function (called once per frame), which compares the player's position with its previous state and adjusts the camera accordingly.

Does that sound reasonable?

This would probably do the trick. I propose here an "improvement":

A bullet Object can be moved by applying forces. You apply forces on your objects, and then you call simulate(time) to calculate the next position of these objects.

A "normal" game Loop often look like this:

Code: Select all

while()
{
DoSomeStuff
Add forces to movables object via AI or Inputs
bullet->simulate(deltaT)
Ogre->RenderOneFrame
} 

bullet->simulate would get the simulation ahead of deltaT, then via a callback system would tell the rest of the program which object moved.

In order to do that, any object should derive from a base class like that:

Code: Select all

class Object
{
virtual void SetTransformation(transfo)
}

then when an object is moved by bullet, bullet would call the SetTransformation function.

For simple objects, the SetTransformation function would just look like that:

Code: Select all

void SetTransformation(transfo)
{
SceneNode->SetPosition(transfo)
SceneNode->SetOrientation(transfo)
}

We put a desired movement direction into the NPC runtime data (which can be manipulated from outside either via AI or the input system).

The NPC class gets a function, which calculates (based on this direction and the skills/attribute) a desired velocity vector.

Each frame we go through all the NPCs (player is seen as an NPC here) use this vector as input for bullet, which in turn will move the NPCs via the function I mentioned.

For NPC, this would mean that the NPC class add forces to the bullet Object representing the NPC. Calculation of the next position would not be in the scope of the NPC class. It would be done when we call bullet->simulate().
Using Bullet->simulate would also avoid going through all the NPC another time to calculate the next position.

In the Player class we add a function (called once per frame), which compares the player's position with its previous state and adjusts the camera accordingly.

For the Camera, it should be easier to attach it to the sceneNode of the player body, thus saving the need of updating manually the position of the camera.
The Player class would be a class which manipulate an NPC, and which display informations.

I have the feeling that i am not really clear, excuse my english..

Edit:

That's Havok Chaos. The more two objects' boxes collide, the higher force is applied - it results in really strange things. We have to slow a lot of this stuff down or cap its speed when exiting another's collision box.

I know, this is the normal behavior. But the point is that even if you cap speed, objects will be thrown away (even if it's not far). I don't think it would be nice to enter the mage guilde and find every book dispersed everywhere in the building.

Why not just have bullet collisions for the NPCs, leaving all other objects as static objects unless defined otherwise.

That's the plan

In order to do that, any object should derive from a base class like that:

Not going to work. You can't manipulate objects directly. You need to go through the world class, because certain kinds of movements require changes to the world data structure (e.g. when an object crosses a cell border).

For the Camera, it should be easier to attach it to the sceneNode of the player body, thus saving the need of updating manually the position of the camera.

Its not that simple. Depending on the camera mode, we need to adjust the camera, when the player moves. Also, we may need to adjust it anyway, if something is between the player and the proposed camera position, that might block the view.

Its not that simple. Depending on the camera mode, we need to adjust the camera, when the player moves. Also, we may need to adjust it anyway, if something is between the player and the proposed camera position, that might block the view.

Ooops as i am always playing in first person mode, i forgot about this^^

Not going to work. You can't manipulate objects directly. You need to go through the world class, because certain kinds of movements require changes to the world data structure (e.g. when an object crosses a cell border).

Is there a function who does move an object in the World class?

Quoting myself:

Look at MWWorld::World::moveObject.

It was right under my nose

So when bullet move an object, it must use this function?

Correct.

What is the state on the collision implementation? Did you managed to sort out your cmake problems or are we still looking for someone to help with it?

Also, do you want me to start with the non-bullet related backend-work? I already have a movement branch, that was intended to improve the current movement controls. But I should be able to implement the backend based on this branch without losing too much work.

I think we agreed on implementing the bullet integration in the mw scene class (MWRender). Can you push the interface for telling bullet about desired NPC movements?

Sorry, i have had a lot of work the last few days, i hadn't been able to work on Morrowind. So no I haven't made any progress. But next week should be different!

Also, do you want me to start with the non-bullet related backend-work?

If you don't have anything urgent, that would be appreciated.

Can you push the interface for telling bullet about desired NPC movements?

Sorry, my english sucks sometimes, I don't understand this^^

I think we agreed on implementing the bullet integration in the mw scene class (MWRender)

Yes we did. Do you want raw bullet stuffs in this class or a nice encapsulation?

What is the state on the collision implementation? Did you managed to sort out your cmake problems or are we still looking for someone to help with it?

I still have problems with CMake, so it would prefer not doing it.

Edit:
I noticed that the Up axis in morrowind is Z instead of Y. And in the mwscene.cpp the RootSceneNode is rotated. But wouldn't it be better to rotate the camera instead of rotating the whole world?
This simple code should do it:

Code: Select all

      mCamera->pitch(Degree(90)); // Quake uses X/Y horizon, Z up
      mCamera->setFixedYawAxis(true, Vector3::UNIT_Z);

Will it break things with the coordinate system used in OpenMW?

Can you push the interface for telling bullet about desired NPC movements?

Sorry, my english sucks sometimes, I understand this^^

The scene class needs an interface, through which the backend is interacting with bullet. But actually I think its better, if I write the interface. Probably tomorrow. Don't have much time for OpenMW today.

I think we agreed on implementing the bullet integration in the mw scene class (MWRender)

Yes we did. Do you want raw bullet stuffs in this class or a nice encapsulation?

Encapsulation. But wait for my interface changes, then you will see for yourself.

What is the state on the collision implementation? Did you managed to sort out your cmake problems or are we still looking for someone to help with it?

I still have problems with CMake, so it would prefer not doing it.

Okay. Any volunteers?

I noticed that the Up axis in morrowind is Z instead of Y. And in the mwscene.cpp the RootSceneNode is rotated. But wouldn't it be better to rotate the camera instead of rotating the whole world?
This simple code should do it:

Code: Select all

      mCamera->pitch(Degree(90)); // Quake uses X/Y horizon, Z up
      mCamera->setFixedYawAxis(true, Vector3::UNIT_Z);

Will it break things with the coordinate system used in OpenMW?

I suggest strongly not to change the current system. The situation is already complicated enough. We don't need even more problems resulting from missing a few spots when doing a complete re-write of the coordinate-handling.

That's fine for me. I will wait for tomorrow then.

Pushed (to movement branch).

The basic idea is, that the setMovement function will be called once per frame with a list of all moving NPCs (handle) and their desired velocity vector. The task of setMovement would be to somehow generate a reasonable force for bullet.
Sometimes afterwards doPhysics will be called, which should then do the actual calculation and adjust the world accordingly.

I haven't added functions for removing and adding objects yet, because:

a) it seems you have done already some work on it (getting collision meshes) and I am unsure, what kind of parameters you need

b) There has been a mess up in another part of the rendering code, that must be cleaned up first.


Unrelated to this I have a question. MW has an enabled/disabled flag attached to each object. Disabled, the object does not exist physically (it is not rendered and can't be interacted with).
OGRE has a visibility flag, that can be used to mirror this MW flag. Does bullet offer something similar? I really hope it does, because else we have quite a bit of additional work ahead of us.

Also, how did we decide to handle the activation check? I am not sure about the outcome of that discussion. AFAIR we are using the full NIF mesh for collision anyway, if the NIF doesn't have separate collision data. Is that correct? If so, that would mean bullet can handle the collision check and we can say goodbye to the old code?

There should also be a function which rotate an object.

a) it seems you have done already some work on it (getting collision meshes) and I am unsure, what kind of parameters you need

I would need the name of the .NIF, and that's all i think.

Unrelated to this I have a question. MW has an enabled/disabled flag attached to each object. Disabled, the object does not exist physically (it is not rendered and can't be interacted with).
OGRE has a visibility flag, that can be used to mirror this MW flag. Does bullet offer something similar? I really hope it does, because else we have quite a bit of additional work ahead of us.

I am almost sure it does.

Also, how did we decide to handle the activation check? I am not sure about the outcome of that discussion. AFAIR we are using the full NIF mesh for collision anyway, if the NIF doesn't have separate collision data. Is that correct? If so, that would mean bullet can handle the collision check and we can say goodbye to the old code?

yes.


Edit:
can someone indicate me a creature .nif and a NPC .nif? I want to have a look at their collisions.

Rotation, Scaling and Movement (script-induced), plus enable/disable, actually.

And since we will be doing the activation check, we also need a function for that (actually a more general raycasting-check, since this feature is used for more than just activation).

Two more questions:

1. Do you want the rotation as a vector or as a quaternion?

2. MW organises its object into cells. At some point all objects in a cell have to be dropped. In the implementation you are working on, is it easily possible to store a pointer to the cell for each object and then call a drop function, that removes all objects within the given cell? Or is this better handled by calling a remove function for each object?

Do you want the rotation as a vector or as a quaternion?

As a quaternion.

In the implementation you are working on, is it easily possible to store a pointer to the cell for each object and then call a drop function, that removes all objects within the given cell?

I'm not sure I understand this. Sure, each bullet object can store a pointer which point on their cell. But i don't see how the drop function would work.


I was thinking that the implementation of bullet and Ogre is nearly the same. So maybe the best way is to use the CellRenderer functions.

Ps: when I look at the function destroy in the CellRender, it only delete the SceneNode, not the Entity attached to the SceneNode.

And another one. I think NPC can't handled in the same way as other objects. Shall I add another function that simply registers NPCs without a mesh for now?

Well i will still need the name of the mesh for NPC, but having separate functions for NPC and other object is a good idea.

Added the missing functions. Will wire up most of them over the next couple of days.

And once the physics work is done, I will get into a redesign of the MWScene class (the non-physics part of it). The current design is just horrible.

I am working on it. I created a new class in the OEngine to manage bullet.

And i thought about the Morrowind/Ogre coordinate problem. It's a problem indeed because bullet doesn't have a root SceneNode that you just need to rotate to make everything work.
With the current implementation, i would have to exchange the z and the y coord for bullet.
I let you imagine the mess, with each lib having it's own coord system. So I strongly recommend using the solution i suggested earlier.
Unless I missed something, it should not change break anything, and it would be much more coherent. I can do it myself if you approve.

Sorry, but I can't follow you. Because the root scene node is adjusted accordingly, everything works with MW coordinates. Bullet gets MW coordinates as input and produces MW coordinates as output. I don't see where the problem is.

OOps my bad,there is indeed no problem I suppose I worked a little too much today^^

how are we handling objects that change of cell? (NPC/ Players, but it should be the same for every object right?)

On the level of the world-model this is rather complicated. I have some ideas, but I need to work on it more, before we get anything usable.

On the physics level we don't handle objects changing cells at all. If the object changes from an active cell to another active cell nothing changes (physics-wise). When an object changes from a passive cell to an active one or from an active to a passive one, we use the add/remove interface, that I added with my latest push.

So I don't need to worry about it. Great

When the player is changing cell, this results in cells being loaded/unloaded, which in turn adds/removes objects.

For you that would mean during the physics simulation (MWScene::doPhysics) changes to the world can happen (addObject, addActor, removeObject).

Can you handle this situation in your code?

As long as the changes don't happen while the function DoPhysic is running, it shouldn't be a problem.

As long as the changes don't happen while the function DoPhysic is running

But exactly that is what would happen. I looked into it a bit more and changing it in the world model would be hard. I suggest the following workaround:

in doPhysics when attempting to modify an object, you first check if it is the player. If so, you store the changes in a variable and not send them to the world for now. At the end of doPhysics you check if changes have been stored in the variable mentioned above and if so, you send them to the world then.

To be safe, i think i will go further than you: i won't send any change as long as the simulation is not over. This way, we ensure that nothing bad happen (even if we change the way we manage cells). It should not cost performances, as very few objects will need to be updated.

Okay, but I would still send the Player changes last, because else some queued up changes might affect objects that don't exist anymore (in an active cell) at the time you send the change request.

Started on integrating Bullet into our build system. Found a FindBullet.cmake file, that unfortunately does not work properly. Shouldn't be too hard to fix, but I have a question:

What is the usual way to include a bullet header?

#include <btBulletDynamicsCommon.h>

or

#include <bullet/btBulletDynamicsCommon.h>


Also, you mentioned that you want the mesh name of actors. That is not a problem for creatures. But NPCs don't have a mesh of their own, if I understand jhooks code correctly. Instead their physical shape is composed at runtime.
I propose, that we pass an empty mesh name string to MWScene in this case. You should then use a default shape instead. We can work out something better later.

What is the usual way to include a bullet header?

#include <btBulletDynamicsCommon.h>

or

#include <bullet/btBulletDynamicsCommon.h>

No idea. I personally use the first one, but there is probably no rule for this. Do as you feel it's the cleanest.

Also, you mentioned that you want the mesh name of actors. That is not a problem for creatures. But NPCs don't have a mesh of their own, if I understand jhooks code correctly. Instead their physical shape is composed at runtime.

Isn't xbase_anim.nif used?I believe there is a bonding box in this file. But we can hard code it too, as every NPC have approximatively the same size.

I propose, that we pass an empty mesh name string to MWScene in this case. You should then use a default shape instead. We can work out something better later.

It would be even better to add a parameter to the function which tell if it's a NPC, a creature, or something else.

No idea. I personally use the first one.

Okay. That is also the solution I implemented in my bullet branch. I suggest you merge it in and try it out. At least on Linux linking bullet works flawless (using Bullet 2.77 btw.). On Windows you may have to set the cached path variables manually again. Or maybe not.

Isn't xbase_anim.nif used?I believe there is a bonding box in this file. But we can hard code it too, as every NPC have approximatively the same size.

I don't know. jhooks?

It would be even better to add a parameter to the function which tell if it's a NPC, a creature, or something else.

Assuming my assumption about NPCs not having a mesh is true, you can use the mesh variable. Not empty -> Creature, empty -> NPC. There is no third option, since non-actors are already reported through a different function.

Quote:
No idea. I personally use the first one.


Okay. That is also the solution I implemented in my bullet branch. I suggest you merge it in and try it out. At least on Linux linking bullet works flawless (using Bullet 2.77 btw.). On Windows you may have to set the cached path variables manually again. Or maybe not.

I will try it tomorrow.

Assuming my assumption about NPCs not having a mesh is true, you can use the mesh variable. Not empty -> Creature, empty -> NPC. There is no third option, since non-actors are already reported through a different function.

Right

PS: does it also take ages to compile openMW for you?

PS: does it also take ages to compile openMW for you?

Nope. Even a full rebuild (which is rarely needed) takes only about two minutes. But on the other hand I have a fairly powerful CPU.

Another question: Would it be acceptable to use velocity vectors relative to the actors orientation (in the SetMovement function)? As far as I understand it, you will keep track of the actors orientation anyway in the physics code. Right?

Yes it's OK.

I also have a question. I added some bullet code to the OpenEngine (much like Ogre code), but can i upload it to git normally?

I also have a question. I added some bullet code to the OpenEngine (much like Ogre code), but can i upload it to git normally?

OpenEngine is in a separate repository added to openmw as a submodule, so you need to fork the OpenEngine repository and add your fork as a remote to the submodule. After that you can push to your fork.

I pushed a couple more commits. The backend-changes are almost complete. We have a new problem though:

I had to attach the camera to the player scene node. Unfortunately OpenEngine doesn't seem to work with this mode of operation. it rotates the camera instead of the parent scene node, which results in the wrong moving direction. Also other aspects of the camera controls seem to be broken now.

I don't have the time to look into this problem right now. I guess we can continue with the physics implementation without fixing it, but a fix will be required before we can have another release.

Sorry, I have been very busy lately, and I didn't had much time to spend for bullet, so it's not going as fast as i wish.
But that's nice to hear the backend-changes are almost complete.
For the camera bug, I think it should not be mush trouble to fix it.

For the camera bug, I think it should not be mush trouble to fix it.

Then you are more optimistic than me. I must admit that I have absolutely no idea about the inner workings of OpenEngine. Didn't even look at the code yet. Feel free to tackle the problem, if you feel comfortable with the task.


Anyway, I just pushed the last set of commits. My work on the physics is done for now.

Besides the camera we still have the following problems:

- the no collision mode is not implemented properly and I am not sure yet how to do it.

- in the "no ground"-situation we talked about before, MW shows a behaviour that needs special attention. If there is absolutely nothing below the player (i.e. he would fall endlessly), the engine pretends he is standing on a flat surface. I think replicating this behaviour is important; mostly for testing during content development.
(this only affects the engine while the collision mode is activated; no changes for no-collision mode).

You can always check if the player is below the hieghtmap.

However, this doesn't solve interior cells. For interior cells you might have the check the lowest point that a static occupies and check if the player is below that.

No idea. I personally use the first one.

Okay. That is also the solution I implemented in my bullet branch. I suggest you merge it in and try it out. At least on Linux linking bullet works flawless (using Bullet 2.77 btw.). On Windows you may have to set the cached path variables manually again. Or maybe not.

Isn't xbase_anim.nif used?I believe there is a bonding box in this file. But we can hard code it too, as every NPC have approximatively the same size.

I don't know. jhooks?

It would be even better to add a parameter to the function which tell if it's a NPC, a creature, or something else.

Assuming my assumption about NPCs not having a mesh is true, you can use the mesh variable. Not empty -> Creature, empty -> NPC. There is no third option, since non-actors are already reported through a different function.

base_anim.nif is used in the new code in the NPCanim branch. In the older code each bodypart was attached to a different scenenode. Now each body part mesh is assigned to a bone of base_anim.nif

the bullet stuff is starting to work: here is a screenshot for you (i know people like screens^^):

What you see are the collision shapes of the object. The player should be able to move, but there is a problem with the camera update i think. I am looking into it right now. There is also a problem with the orientation of the player. Right now, it's done with the camera sceneNode i think, but the "physic" orientation should be updated too.

(BTW i almost fixed the camera bug Zini)

Wow, looking nice!

Daaang! Nice!!

greate to see it!

Ok, collision are working now, and i have a character controller which works!

But you were right Zini, the camera is a pain. I tried many things, and i think we should apply this:
http://www.ogre3d.org/tikiwiki/Creating ... era+system
but not only to the camera but also to every actor in the scene. And the physic system should not , IMO, try to guess the direction in doPhysic(), as it's rather complicated, and it has nothing to do with physic. So the vectors passed to the doPhysic function should not be relative to the actor orientation.

Sadly, i can't really commit my changes as long as the camera bug is not fixed.

Okay, several points to address:

1. The camera: I know this one is a pain. I was hoping we can get by with a minimal implementation for now. The MW camera system has a lot more of complexity (1st person mode, 3rd person/shoulder mode, tab mode, vanity mode).
There is a separate roadmap entry for it and the idea was to put off the implementation until we have the physics and the NPC/player rendering worked out.
If that is not possible, then go for the implementation described in the link.

2. Actors: I don't see the point in applying the same technique to actors. Your typical NPC is rotating only around a single axis. That should be fairly easy to manage.

3. Local vs. MW-global rotation: Okay. Looks like we have to look into this a bit more. The rotation implementation in the world model is pretty rudimentary at its current stage. I was hoping to get by with it for now. But no dice again, it seems.

1. The camera: I know this one is a pain. I was hoping we can get by with a minimal implementation for now. The MW camera system has a lot more of complexity (1st person mode, 3rd person/shoulder mode, tab mode, vanity mode).
There is a separate roadmap entry for it and the idea was to put off the implementation until we have the physics and the NPC/player rendering worked out.
If that is not possible, then go for the implementation described in the link.

In fact i already did it. But i have trouble to get the correct orientation from the camera to get the walk direction, due i think (not sure) to the Y / Z conversion.
Also, the player class in the render part should not only hold the camera, but also the related SceneNode.

Another point: the camera will be attached to the sceneNode of a NPC right? Then the mouse should rotate the NPC node and not the camera node i think (for yaw, not for pitch).
From what i have understood of OpenMW(might be wrong), it heavily rely on the camera to get the orientation. But this can't be apply to NPCs. That's why i think the movement/ orientations should be implemented in the same way for NPC and the player. And then, the camera do whatever is needed to follow the player.

I don't know if i am very clear

2. Actors: I don't see the point in applying the same technique to actors. Your typical NPC is rotating only around a single axis. That should be fairly easy to manage.

Nerver mind. It was a stupid idea.

3. Local vs. MW-global rotation: Okay. Looks like we have to look into this a bit more. The rotation implementation in the world model is pretty rudimentary at its current stage. I was hoping to get by with it for now. But no dice again, it seems.

Yup. I think, for the sake of an understandable design that it's above the scope of the Physic Engine.
Well, if we choose this implementation, i will modify a bit the physic implementation and commit it.

BTW, it's very hard to know who/what is modifying the positions/orientation, etc of actors just from reading the code. Some documentation would be nice^^

Another point: the camera will be attached to the sceneNode of a NPC right? Then the mouse should rotate the NPC node and not the camera node i think (for yaw, not for pitch).

We are talking about the 1st person mode here, right? In this case your idea is correct.

From what i have understood of OpenMW(might be wrong), it heavily rely on the camera to get the orientation. But this can't be apply to NPCs.

That is only the simple placeholder implementation we currently have. It was never meant to last.

That's why i think the movement/ orientations should be implemented in the same way for NPC and the player. And then, the camera do whatever is needed to follow the player.

Correct, but only for the regular mode with collision enabled. With collision disabled we have a free-flying mode, that needs to be addressed separately (at least the orientation part).

BTW, it's very hard to know who/what is modifying the positions/orientation, etc of actors just from reading the code. Some documentation would be nice^^

Its actually not that hard. There is the World::moveObject function. All object movement is directed through this function. The function itself updates the world model data and the ogre scene and the physics (through the mwscene interface). Some of the ogre scene update, that is currently implemented in World, probably should be moved to MWScene.
There isn't really a proper implementation for modifying the orientation yet.

I will see what I can do about improving the orientation part this week.

Its actually not that hard. There is the World::moveObject function. All object movement is directed through this function. The function itself updates the world model data and the ogre scene and the physics (through the mwscene interface). Some of the ogre scene update, that is currently implemented in World, probably should be moved to MWScene.
There isn't really a proper implementation for modifying the orientation yet.

I was more speaking of the game mechanism (like which component tells the world to move an object?), but as i understand now, it's not really implemented right?

There are different sources for calls to World::moveObject. Previously we had the Player class calling it, but that isn't used anymore. So now only your physics code will call the function.


Script controlled movement (which will also call this function) is indeed not implemented yet.

Edit: With the exception of coc and coe instructions, which move the player. This is already implemented.

coc and coe? what are they?

BTW, I committed the change to git (including my Fork of the openengine).

Edit: there is no gravity in my commit, but that's an easy fix.

coc and coe? what are they?

Center on cell and center on exterior. Teleport the player to a specific cell.

I've added raycasting, so the bullet task is pretty much finished. But it's not tested, because as long as the camera is broken, it's hard to do testing. I would rather focus on terrain rendering, if possible.

Well, we need to test that whole thing before we can declare it finished. We need to see, if we can find a volunteer to fix up the camera. If I took the job, with what little time I have available right now, that would probably take weeks. The best I can offer right now is implementing actor rotation on the world-model side.

You are free to start with the terrain task. I think it should not be integrated into 0.10.0. We already have too much stuff for the upcoming release. But doesn't let that stop you from getting a headstart with the terrain implementation.

About the camera: I just had a thought. Can we rescue the old implementation? Decouple the camera from the player scene node again. Then track camera movement and move the player scene node accordingly. Also track the camera orientation and call the rotation function of MWWorld::World (which I am going to add this week) accordingly.

This would still be just a placeholder. We would replace it later with a proper implementation that considers all the camera modes.

I just had a thought. Can we rescue the old implementation? Decouple the camera from the player scene node again.

I think we can, but i don't know the inside of openmw enough to be sure.

Also track the camera orientation and call the rotation function of MWWorld::World (which I am going to add this week) accordingly.

I think the rotation should also be stored independently of Ogre or Bullet. This would give a more logical design.

I think we can, but i don't know the inside of openmw enough to be sure.

Actually that is more a question of OpenEngine and OGRE insides.

I think the rotation should also be stored independently of Ogre or Bullet. This would give a more logical design.

For actors the rotation around the (Morrowind) Z-axis is stored (or will be stored) within the cell data structure. Since actors usually not rotate around other axis and it is only the camera, that rotates here, there is no point in storing it in the actor world model.
The camera implementation might store the other rotations (there is a separate Player class in MWRender, that is supposed to handle all the camera (mode) stuff). It remains to be seen what needs to be stored here. Obviously a placeholder implementation is free to store what ever data it requires.

Ok, i fixed the camera bug, but it's done in a very hacky way. It will work only if we only deal with the player, and no other NPC. It's really only for testing purpose.

But i have a problem to test my work: i start outside of the cave and i can't come in due to collisions... how do i move inside the cave?

Ok, i fixed the camera bug, but it's done in a very hacky way. It will work only if we only deal with the player, and no other NPC. It's really only for testing purpose.

Can't follow you. Other NPCs don't have a camera. This is player specific.

But i have a problem to test my work: i start outside of the cave and i can't come in due to collisions... how do i move inside the cave?

There should be a door or something that you can activate my focussing it and pressing space. If it doesn't work, you broke the raycasting. Also you can coc into other cells. Open the console (F1) and enter coc cellname.

Can't follow you. Other NPCs don't have a camera. This is player specific.

.
In the doPhysic, i assumed a camera was attached to every actor in order to get their orientation (as the player is the only actor which move that's not a problem).

There should be a door or something that you can activate my focussing it and pressing space. If it doesn't work, you broke the raycasting. Also you can coc into other cells. Open the console (F1) and enter coc cellname.

coc crash. I'm investigating this right now.

Heh - no harm in giving the NPCs a camera and simply disabling it - would make for nice functionality later on...

Anyways - nice to see bullet is coming along nicely. Keep it up!

Well, having a camera for every NPC doesn't seem to be a very logical ( I prefer having a logical design, it's easier to understand). No this is just a placeholder.

With bullet, i spend most of the week doing some debuging. I think i found a bug in bullet itself (or at least it look like it), and i'm having trouble with the charactercontroller. I might end up having to do one myself.

Finally found the time to try the new physics code. Does not compile unfortunately. Looks like we have multiple problems. I am investigating. One problem seems to be the use of backslashes in includes. Never do that! Not even on Windows!

Also, please check your editor settings again. It seems you are using tabs instead of spaces at least in some places. Not related to the build problem, but we agreed on using 4 spaces.

Some progress. There are serve const-problems with the new bullet part of OpenEngine. This should have been caught by the compiler (passing a temporary to a function, that expects a non-const reference).

Can someone with experience with the MSVC compiler settings please review the settings currently in use and adjust the cmake files accordingly?


Also, the new bullet part of OpenEngine wasn't added to the cmake files it seems. I am looking into it now.

Giving up for now. I reached a point where I can't continue without starting to read up on Bullet (for which I don't have the time).

The last error I am getting is:

/home/marc/OpenMW/openmw/libs/openengine/bullet/physic.cpp: In constructor â??OEngine::Physic::PhysicActor::PhysicActor(std::string)â??:
/home/marc/OpenMW/openmw/libs/openengine/bullet/physic.cpp:60: error: â??btKinematicCharacterController::UpAxisâ?? is not a class or namespace

I pushed the fixes to github (OpenEngine master branch, OpenMW collision branch).

(I am using bullet 2.77; just in case that has any relevance here)

Getting it to compile was not far away, just remove that enum type name and add nifbullet to the cmake file.

For it to run I also had to move the creation of PhysicEngine instance until after ogre is initialized to make Ogre::ResourceGroupManager::getSingleton not fail.

Comments on what I've seen so far:
BulletShapeManager should probably move to openengine, currently openengine depdends on openmw and we probably don't want that.

btKinematicCharacterController: shouldn't we subclass rather than just copy the entire class from bullet and start changing?

I haven't looked into the code more closely yet, but I agree with your comments. OpenEngine may not depend on OpenMW. And copying/modifying bullet classes is not a good idea.

Finally found the time to try the new physics code. Does not compile unfortunately. Looks like we have multiple problems. I am investigating. One problem seems to be the use of backslashes in includes. Never do that! Not even on Windows!

Strange because it's VC auto completion^^

Also, please check your editor settings again. It seems you are using tabs instead of spaces at least in some places. Not related to the build problem, but we agreed on using 4 spaces.

You are right, i forgot to change this with this computer. Done now.

BulletShapeManager should probably move to openengine, currently openengine depdends on openmw and we probably don't want that.

You are right, and my plan was to move it afterward. But still, is it really needed to to a difference between openEngine and openMW(like having 2 different repo?)? Because it seems rather unlikely that OEngine will be used in any other project than OpenMW.

btKinematicCharacterController: shouldn't we subclass rather than just copy the entire class from bullet and start changing?

It's a different class than the one provided by bullet. It's an implementation of a CharacterController made by someone in the bullet forum, and it's not included in the bullet package.

You are right, and my plan was to move it afterward. But still, is it really needed to to a difference between openEngine and openMW(like having 2 different repo?)? Because it seems rather unlikely that OEngine will be used in any other project than OpenMW.

I never understood the point in OpenEngine either. The idea of a generic game engine component does not work for me. The stuff inside of OpenEngine will either be too specific for a generic engine (i.e. tied to a specific genre) or so minimal, that it is not worth having it.

But since this is how we inherited OpenMW, lets keep up the status quo for now. We can clean up later (probably post 1.0) or simply keep it, if it does not affect the design of OpenMW negatively.

Tested the physics code, including peppe's improvements. Compiles and links, but crashes on the first movement. Here is the stack backtrace:

#0 0x00007ffff5b901a3 in std::string::assign(std::string const&) ()
from /usr/lib/libstdc++.so.6
#1 0x00000000007c23cd in OEngine::Physic::PhysicEngine::rayTest(btVector3&, btVector3&) ()
#2 0x00000000007dcea1 in MWRender::MWScene::getFacedHandle(MWWorld::World&) ()
#3 0x000000000088518d in MWWorld::World::getFacedHandle() ()
#4 0x00000000007d350b in OMW::Engine::frameStarted(Ogre::FrameEvent const&) ()
#5 0x00007ffff797c574 in Ogre::Root::_fireFrameStarted (
this=<value optimised out>, evt=<value optimised out>)
at /home/marc/Tools/ogre-1-7-1/OgreMain/src/OgreRoot.cpp:804
#6 0x00007ffff797d2c9 in Ogre::Root::_fireFrameStarted (this=0x7ffff7ec18d8)
at /home/marc/Tools/ogre-1-7-1/OgreMain/src/OgreRoot.cpp:876
#7 0x00007ffff797d329 in Ogre::Root::renderOneFrame (this=0x7fffffffda20)
at /home/marc/Tools/ogre-1-7-1/OgreMain/src/OgreRoot.cpp:963
#8 0x00007ffff797d39d in Ogre::Root::startRendering (this=0x7ffff7ec18d8)
at /home/marc/Tools/ogre-1-7-1/OgreMain/src/OgreRoot.cpp:956
#9 0x00000000007ab2f7 in OEngine::Render::OgreRenderer::start() ()
#10 0x00000000007d5c97 in OMW::Engine::go() ()
#11 0x00000000007ccc76 in main ()

Looks like the raycasting is broken.

coc crash. I'm investigating this right now.

Any success? This is the stack trace I get.

Code: Select all

#0  0x000000000079911c in btCollisionWorld::ConvexResultCallback::needsCollision (this=0x7fffef2c0980, proxy0=0x0) at /usr/include/bullet/BulletCollision/CollisionDispatch/btCollisionWorld.h:357
#1  0x00007fb608429271 in btGhostObject::convexSweepTest(btConvexShape const*, btTransform const&, btTransform const&, btCollisionWorld::ConvexResultCallback&, float) const () from /usr/lib/libBulletCollision.so.2.77
#2  0x0000000000797063 in btKinematicCharacterController::stepUp (this=0x7fb5f9ee4680, world=0x7fb5f80c8d20, currentPosition=..., currentStepOffset=@0x7fffef2c0bdc)
    at openmw/libs/openengine/bullet/btKinematicCharacterController.cpp:246
#3  0x0000000000797f9f in btKinematicCharacterController::playerStep (this=0x7fb5f9ee4680, collisionWorld=0x7fb5f80c8d20, dt=0.0333333351) at openmw/libs/openengine/bullet/btKinematicCharacterController.cpp:512
#4  0x00000000007994d8 in btKinematicCharacterController::updateAction (this=0x7fb5f9ee4680, collisionWorld=0x7fb5f80c8d20, deltaTime=0.0333333351)
    at openmw/libs/openengine/bullet/btKinematicCharacterController.h:109
#5  0x00007fb6086d37da in btDiscreteDynamicsWorld::updateActions(float) () from /usr/lib/libBulletDynamics.so.2.77
#6  0x00007fb6086d4038 in btDiscreteDynamicsWorld::internalSingleStepSimulation(float) () from /usr/lib/libBulletDynamics.so.2.77
#7  0x00007fb6086d44aa in btDiscreteDynamicsWorld::stepSimulation(float, int, float) () from /usr/lib/libBulletDynamics.so.2.77
#8  0x00000000007a4bb0 in OEngine::Physic::PhysicEngine::stepSimulation (this=0x7fb5f80c5be0, deltaT=0.063000001013278961) at openmw/libs/openengine/bullet/physic.cpp:244
#9  0x00000000007c02a8 in MWRender::MWScene::doPhysics (this=0x7fb5f80c9128, duration=0.063000001, world=..., actors=...) at openmw/apps/openmw/mwrender/mwscene.cpp:145
#10 0x000000000086cadf in MWWorld::World::doPhysics (this=0x7fb5f80c9120, actors=..., duration=0.063000001) at openmw/apps/openmw/mwworld/world.cpp:856
#11 0x00000000007b65cb in OMW::Engine::frameStarted (this=0x7fffef2c13f0, evt=...) at openmw/apps/openmw/engine.cpp:186
#12 0x00007fb60a054cd4 in Ogre::Root::_fireFrameStarted (this=<value optimized out>, evt=<value optimized out>) at ogre/OgreMain/src/OgreRoot.cpp:804
#13 0x00007fb60a055789 in Ogre::Root::_fireFrameStarted (this=0x7fb60a59f8d8) at ogre/OgreMain/src/OgreRoot.cpp:876
#14 0x00007fb60a0557e9 in Ogre::Root::renderOneFrame (this=0x7fffef2c0980) at ogre/OgreMain/src/OgreRoot.cpp:963
#15 0x00007fb60a05585d in Ogre::Root::startRendering (this=0x7fb60a59f8d8) at ogre/OgreMain/src/OgreRoot.cpp:956
#16 0x000000000078de1f in OEngine::Render::OgreRenderer::start (this=0x7fffef2c1408) at openmw/libs/openengine/ogre/renderer.cpp:22
#17 0x00000000007b8c51 in OMW::Engine::go (this=0x7fffef2c13f0) at openmw/apps/openmw/engine.cpp:443
#18 0x00000000007afa84 in main (argc=2, argv=0x7fffef2c16c8) at openmw/apps/openmw/main.cpp:117

Looks like the raycasting is broken.

It works fine for me... i can't really help you.

Any success? This is the stack trace I get.

Yup, I uploaded the change a second ago.

It works fine for me... i can't really help you.

Strange. I could have sworn that you actually reported this crash at some point (and that I gave you wrong advice about it, because I thought it would be the NPC rendering bug).

Anyway, can anyone else confirm this crash. Start OpenMW normally with the default cell. Move the camera a bit and then move forward.

Strange. I could have sworn that you actually reported this crash at some point (and that I gave you wrong advice about it, because I thought it would be the NPC rendering bug).

I don't remember. I might be alzheimer^^

But to start with, maybe you could just comment the code in the OEngine::Physic::PhysicEngine::rayTest function, to see if everything is working.

Also, the characterControler is clearly not finished. It's behavior when climbing stairs and such isn't right for now. Actually if you has the time(or anybody else), you can try to change the parameters in line 61,55,42 of physic.cpp.
There, you can enable/disable gravity, and set many parameters. And i didn't found yet the right values for a realistic behavior.

And i didn't found yet the right values for a realistic behavior.

What values? :-/

Finally got around to have a look at the code again. If I disable the raycasting the rest of the collision code kinda works (at least it doesn't crash). But moving forward/backward leads to up/down movement instead.

The raycasting problem looks suspiciously like an uninitialized pointer somewhere. Gus, could you please merge in peppe's changes, so we have the same codebase (not that I want to blame it one those commits!).

Found a workaround for the crash. It was not an uninitialized pointer but a failed cast.

I replaced the static_cast in PhysicEngine::rayTest with dynamic_casts which turn the crash into an exception (see my code on github).

Lesson of the day: Always use dynamic_cast instead of static_cast, unless the situation is so simple, that an error in the program logic is entirely impossible.

We still have to find out why these casts failed. Looks indeed like a flaw in the program logic. Gus, any ideas?

Anyway, this is the remaining to-do list as I see it:

1. fix the forward/backword, up/down bug

2. test player-collision (once the bug above is fixed and we can move around)

3. test the ray casting function

4. Remove the OpenMW dependency from OpenEngine (unless this has already been done)

5. fix the cast problem mentioned above

6. add the no collision mode

7. add a dummy implementation for player speed (maybe just use the speed attribute for now) and find bullet settings, that produce realistic movement

8. add gravity when not in no collision mode

Once this is done, we can probably have a 0.10.0 release.

Edit: spelling

Sorry, I have been away on ski holiday, with no net. I will address the issues(and answer to every post) as soon as I can.

Okay , i commited some changes. Can you try them?

fix the forward/backword, up/down bug

Strange, i don't have this bug. Let's hope my lastest commit fixed the changes.

test the ray casting function

I have no idea of what can cause the probleme (and i have no problem myself), but i will look into it.

Remove the OpenMW dependency from OpenEngine (unless this has already been done)

That's what i'm working on. Shouldn't be long.

7. add a dummy implementation for player speed (maybe just use the speed attribute for now) and find bullet settings, that produce realistic movement

8. add gravity when not in no collision mode

More or less done

What values? :-/

try line 61,55,42 of physic.cpp.

Dropping like a stone now. Adding gravity without implementing collision mode toggling was probably not such a good idea. Can't test anything.

try coc to another cell

Took me a while to find a cell that worked. And the forward/backward up/down problem still exists. Can't test anything without being able to move properly.

btw. is it normal, that it prints this:

Code: Select all

!!internal!!internal!!internal!!internal!!internal!!internal!!internal!!internal!
!internal!!internal!!internal!!internal!!internal!!internal!!internal!!internal!
!recover!!!!internal!!internal!!internal!!internal!!recover!!!!internal!!internal!
!internal!!internal!!internal!!internal!!recover!!!!internal!!internal!!recover!!!
!internal!!internal!!recover!!!!internal!!internal!!recover!!!!internal!!internal!
!internal!!internal!!internal!!internal!!internal!!internal!!internal!!internal!

?

And the forward/backward up/down problem still exists. Can't test anything without being able to move properly.

Crap. My guess is that i (again^^) messed up with git. I will exactly compare my version and the one that is on the repo.

btw. is it normal, that it prints this:

It is. I used it to debug something. I will remove it.

Edit: which cell do you use? We should maybe set it as default cell.

Well, for a start you could try to merge in my branch again. Just to make sure, that nothing got lost. Also do a submodule update after the merge to make absolutely sure, that nothing got lost there.

I tried multiple cells. One of the cells that work for me is: Vivec, Telvanni Plaza

Okay, i think i found the up and down bug. I had modified a file and forgot to put it on git. It's done now.

But it's very strange, because when i updated my git repo etc, it started crashing. Curently, i have a bug with the NifOgreLoader when trying to go to the vivec cell... So. I can't really test anything.

The good news: I tested it and the fix works.
The bad news (kinda): I don't get a crash, which probably means you have more git problems.

Activation does not work, as far as I can tell.

It is. I used it to debug something. I will remove it.

Unless you still need it for something, do that as soon as possible please, because it makes testing pretty annoying.

After looking at the github graph, I figured that you don't have your recent OpenEngine improvements in your collisions branch. Please merge in my collision branch again and do a sub-module update!

Do you compile/work in your git folder, or do you work in a copy of the git folder?

I am using out-of-source build. Why?

I was not clear enough sorry. My question was, do you have two different source folder, one for "work", and the other for git? Or do you modify the source directly inside the folder used for git?
I don't know if i'm clear^^

My question was, do you have two different source folder, one for "work", and the other for git? Or do you modify the source directly inside the folder used for git?

I work directly with the working tree in my clone. If I need another copy for reference (another branch) I make a clone.

I can't see any reason to copy the working tree out of the repository, that would just make things more cumbersome.

The later obviously. I have never seen or heard of a setup like the first one you mentioned. That would make the version control system kinda pointless.

I guess i have weired ideas might explain why i have so many troubles with git^^.

I did what you said, but it still crash...

Strange. Maybe try to clone again into a new directory?

Any progress?

Also, I have another question. In OpenEngine/bullet.phyiscs.hpp we have a setDebugRenderingMode function. Does this function allow the debug rendering to be toggled freely at runtime? Because there is a script instruction for it. I could hook it up to the function.

Yes that's it. If set to 0, there is no debug rendering, if set to 1, it is the current debug rendering(it display collisions shapes). Currently, it is set to 1 each time the function doPhysic in mwscene is called. Note that it require Ogre to be set up before.

Any progress?

I'm currently cleaning my git stuffs. I'm almost done with it.

Ok i think i've finished with Git. I did a little testing, and i removed the dynamic_cast you added, just to see what was wrong. And nothing happened, no crash. That's strange because I had the crash at some point. It seems it was resolved when I merged your master branch in the collision branch.

But i can still find no cell to properly test Bullet. The one you mentioned aren't working (they don't crash, but either the player fall, or he start sticked in a wall). I tried a lot of cell, without success.
Is there a command to teleport to a specific location inside a cell?

Still, it seems that some shapes are not loaded for objects like books and such. I'm looking into it.

Is there a command to teleport to a specific location inside a cell?

Nope.

It is strange that it is now working for me and not for you.

Regarding the crash: The activation bug only happens when you face a particular object or type of object. I haven't been able to identify it yet.

Still, it seems that some shapes are not loaded for objects like books and such. I'm looking into it.

This might be related to it though.

btw. there is no need to remove the dynamic cast. You get an error message in cout.

To make activation testing easier, we need the no collision mode (player can pass through stuff and no gravity). I suggest you implement this feature next.

I implemented the script instructions for toggling collision debug rendering (in my script branch).

MW happened to have two different instructions for this purpose (plus one shorter alias for each one). I wired up all four against the same function.

It works only partially though. I can switch the debug rendering on and I can switch it off again. But when I try to switch it on a 2nd time, it does not show up.
Please note that fixing this problem has a low priority. We can do the release without these instructions working properly.

You can now set gravity / collision for every actor (meaning also that each actor have it's own settings), with the setGravity and setCollision functions in PhysicActor.

But i don't know how to bind them to a command or to a key.

Also, with git, how do i "link" submodules with my own submodules? currently, it tries to push in your submodule Zini (so obviously it fails).

But i don't know how to bind them to a command or to a key.

There is already a function for it in MWScene (toggleCollisionMode). You just need to fill in the code in the functions body. The function is called, when you enter ToggleCollision into the console.

Also, with git, how do i "link" submodules with my own submodules? currently, it tries to push in your submodule Zini (so obviously it fails).

Just push to your repository. Make sure you commit/push the submodule, before you commit/push the main project.

It's on GIT now, and i removed the dependency between OpenEngine OpenMW.

Quite a few problems, unfortunately:

1. It does not build. You forgot to add two files to the cmake script.

2. Switching collision mode back on after it has been switched off doesn't work. Well, sometimes it does seem to work. I am not sure what is going on here. Entering ToggleCollision twice in the default start cell lets you continue falling (which started after entering ToggleCollision once).

3. When collision mode is switched off (I presume that is the default state when starting a new game), I can only move on the horizontal plane (no up or down).

Found the activation problem. You were not converting from Ogre to MW coordinates when doing the raycasting. The fix is in my collision branch. NPC activation still doesn't work. No idea why.
Also, when activating a door I always end up in mid-air. Not sure what is happening here. Testing is still pretty hard, because the no collision mode isn't working properly.

well, I think i found the cause of the NoCollisionMode problem too. In fact, it's really logical: the player keep it's velocity when you toggle the collision mode, so even if there is no more gravity, the player will continue to fall down. I will try to fix that tonight.

it's really logical: the player keep it's velocity when you toggle the collision mode, so even if there is no more gravity, the player will continue to fall down

Lol! That would certainly explain all the problems I had with the no collision mode.

It's solved but i'm having trouble to merge your branch into mine.

It's solved but i'm having trouble to merge your branch into mine.

Sorry, can't give any help, unless you give a better error description.


Tested your changes. The OpenMW repository didn't reference the correct submodule version. Otherwise it was okay.

ToggleCollision works now. The horizontal plane problem still persists though. Still impossible to do proper testing.

Sorry, can't give any help, unless you give a better error description.

I will try again latter.

The horizontal plane problem still persists though. Still impossible to do proper testing.

Well, this isn't a bug it's a feature Because when collisions are enable, you don't want your character to be able to fly just by looking up right? (and you don't want any difference of speed when looking up/down). That's why the only thing that must be take into account when in collision mode is the yaw rotation.
It will require a different implementation in FreeFly mode. For this, there should be a way to know in mwscene if it's in freefly mode or in collision mode.

Well, this feature makes the no collision mode unusable. I am aware, that we need separate implementations for collision and no collision mode.

For this, there should be a way to know in mwscene if it's in freefly mode or in collision mode.

I am not sure, if I understand what you mean. You already know the collision mode state in MWScene, because the toggle function is routed through this class.

I added a free fly mode.

Gah! That was nasty! Got a submodule merge conflict and probably more submodule problems (last commit appeared twice). Had no other option than to reset. Sorry, but merging in your collisions branch is beyond my git skill.

I added the changes from your last commit manually (ignoring the two commits before) and I can confirm that the no collision mode is working properly now.

I suggest you delete your collisions branch (both locally and on github) and start cleanly with my collision branch.

As I see it we have four problems left now:

1. Some objects don't show up in the physics. As far as I can tell, this affects mostly smaller items and NPCs.

2. Activating a load door (changing cells) makes you float in mid air. This could be either the physics system not handling the rapid change of the entire world correctly or I messed up the cell change mechanism when adjusting the World class for the physics changes.

3. Sometimes movement is blocked. This is most obvious when trying to climb the stairs in the Balmora mage guild. But there are other cases too.

4. Toggling physics debug rendering on, off and then on again doesn't work.

Of these #1 and #2 must be fixed, before we can have a release. Ideally we should also improve #3, but we probably don't want to delay the release too much because of this problem.

#4 can safely wait for the next version.

Did some preliminary analysis on #2. This is what is happening, when you activate a door:

- You get teleported, apparently to the right spot.
- A couple of frames later (or a very long frame later), during the doPhysics phase, MWScene teleports the player to a place near 0, 0, 0.

So far I have no idea why it is doing that.

Gah! That was nasty! Got a submodule merge conflict and probably more submodule problems

I also had a problem with submodules^^

I suggest you delete your collisions branch (both locally and on github) and start cleanly with my collision branch.

1. Some objects don't show up in the physics. As far as I can tell, this affects mostly smaller items and NPCs.

I will investigate, but for NPC it's more likely another problem because the player is created properly.

2. Activating a load door (changing cells) makes you float in mid air. This could be either the physics system not handling the rapid change of the entire world correctly or I messed up the cell change mechanism when adjusting the World class for the physics changes.

I will have a look at it.

3. Sometimes movement is blocked. This is most obvious when trying to climb the stairs in the Balmora mage guild. But there are other cases too.

This isn't new. I've been searching for a while to correct values.
I will try to find betters one, but they will most likely need to be changed to fit better with the exact morrowind behavior.
Also, the jump in missing.

Did some preliminary analysis on #2. This is what is happening, when you activate a door:

- You get teleported, apparently to the right spot.
- A couple of frames later (or a very long frame later), during the doPhysics phase, MWScene teleports the player to a place near 0, 0, 0.

So far I have no idea why it is doing that.

does it happens in no collision mode?

does it happens in no collision mode?

Yes.


Jumping is a separate entry on the task list. Don't worry about it for now.

Could you indicate me a cell with a door close to the spawn point?

Vivec, Telvanni Plaza

What is the exact command i must enter? Because it's saying Cell not found. I guess i missed a " or something, but i can't figure it out

./openmw --start "cellname"

I have "Vivec, Telvanni Plaza" from the cell name list in our wiki. I don't have the English version of Morrowind, so the name won't be the same for you and me.

You can get the name by entering

./esmtool data/Morrowind.esm | grep "CELL" | grep "Vivec"

(assuming Linux command line tools).

Okkayy, so name changes when you change the langage of the game. That explains a lots of things!

Yeah, one of the worst design flaws in MW. We may have to address this problem eventually (post 1.0).

I found the problem, but I'm not sure how to solve it. When you change the cell, the position of the SceneNode of the player is changed, but not the position of the PhysicActor. And as the position of the SceneNode is set from the position of the PhysicActor, so the position of the player doesn't change.

So to solve this, we must update the player position in the PhysicEngine in World::playerCellChange.

But after looking at the code, the player class has some useless function like setPos, because they only change the position of the SceneNode.

It looks like your analysis is correct. But you are blaming the wrong function. I am looking into it now.

Nope. That was not the problem.

I found a bug and added a fix and a partial workaround (the bug actually helped to avoid a crash at startup; we need to review the startup-sequence at some point).

But even with the fix the problem persists. I checked it. At the first moveObject call after the cell change the updatePhysics argument is true.

Git is starting to annoy me. I can't merge my branch with your because I modified mangle.

As it's a very minor modification(but required to compile on windows),can you commit it on mangle? (i don't really wants to fork Mangle...)

here is the modification:
in audiere_source.cpp

line 17 should be replaced by this:

Code: Select all

void AudiereSource::getInfo(Mangle::Sound::int32_t *rate, Mangle::Sound::int32_t *channels, Mangle::Sound::int32_t *bits)

Done. Please make sure to merge in my collision branch (and do a submodule update), so we don't run into submodule problems again.

Fun fact: After the cell change for three frames everything works correctly. doPhysics jumps near 0, 0, 0 only in the 4th frame.

But that's still strange, there shouldn't be any delay. Maybe it's a camera update stuff.

I'm trying to get how things are initialised, but it's rather complicated. Maybe this should be wikified.

Forgot about the initialization for now! That can wait for the next release. We need to fix this bug, since it is a release-blocker.

I don't see how this problem can be related to the camera.

I was only speaking of the 4 fram delay you noticed

But how can we solve the problem without looking at the initialization?

Because it is not related to initialisation. As far as I can tell the problem is, that after about 3 runs of phyiscs calculations the physics subsystem suddenly changes the coordinates of the player to some place near 0, 0, 0.

This could be:

- a bug in the physics code
- or faulty input to the physics code, probably from the world class, that somehow corrupts the physics data and leads to this kind of erratic behaviour.

By initialization, i also meant changing cell.

- or faulty input to the physics code, probably from the world class, that somehow corrupts the physics data and leads to this kind of erratic behaviour.

As far as I can tell, the position of the PhysicActor representing the player is never changed. So basicaly, the player stay in the same position while taking a door (but the position appears different due to a different cell). This isn't an erratic behavior.

As far as I can tell, the position of the PhysicActor representing the player is never changed. So basicaly, the player stay in the same position while taking a door (but the position appears different due to a different cell)

This is not, what I see. Before entering the door moveObject was called with Vector3(33.8427, 1246.47, -484.398) and physicsUpdate==false

THen, after the new cells were loaded, moveObject was called with Vector3(43454.4, -82440.3, 2127.49) and physicsUpdate==true.

Then we get 3 calls with similar values and physicsUpdate==false (these should be the result of doPhysics calculations).

Then I suddenly get a cell change to 0, 0 and a call to moveObject with (33.8427, 1246.47, -484.398) and physicsUpdate==false (again this should be the result of doPhysics calculations).

You have my most recent commits on the collision branch, right? Because the bug I mentioned indeed resulted in the behaviour you described in your last posting.

I have something strange. Indeed, the movefunction is called, but with the wrong name.
The name of the player is Unnamed_2, but moveObject seems to be called with nameUnnamed_2 while changing cell.

Interesting. I have an idea, where this might be coming from. Will investigate.

I suppose you mean something like Unnamed_1226 and the nameUnnamed_2 was only a typo.

Well, these are creatures. I have no idea, why they move, but they do. Shouldn't affect the player though.

I found the bug. I will commit it as soon as i've finished to clean up the code.

done.

Cell changing seems to work partially now. When I go outside, after a few steps I can't move any more, but I see the physics debug mesh moving according to my movement input.

btw. I think I have an idea why NPCs aren't added to physics.

Partial fix for the NPC problem committed. Two problems:

- The physics debug mesh is slightly offset from the actual NPC rendering. Might be a bug in the NPC rendering instead of the physics problem.

- Trying to focus or activate a NPC results in the casting bug, that we talked about a while ago. Looks like NPC are actually the type of object, where this cast fails.


btw. could you lower the range of activation a bit?

More info regarding the runaway debug rendering: This seems to be triggered by the player crossing an exterior cell boundary.

I fixed the raycasting bug,and shorten the range of it. It needs the latest OpenEngine.

But stairs cause a lot of jitter. I fear that at some point i will have to rewrite the character controller.

Nice. Seeing the NPC dialogue window now for the first time. Also nice.

I think we can handle the stairs and related problems in a later version. We just have to post a release note stating, that physics aren't perfect yet.

Okay. As I see it we still have two release-blocker left:

1. The runaway debug rendering at crossing cell boarders.

2. Small objects not showing up in the physics.

So much talk yesterday that I completely forgot to answer this one:

I'm trying to get how things are initialised, but it's rather complicated. Maybe this should be wikified.

Initialising was referencing to cell changes here.

Well, actually it isn't that complicated. On a cell change the following happens:

1. The cells that have become inactive are emptied (all references in these cells are removed from the scene).

2. Cell that have become active are filled (after being loaded from the esm file).

3. The player's position is adjusted.

There is happening some other stuff alongside, like sky adjustments (currently ignored by Caelum), script handling and registering/de registering of actors with the mechanics manager. But none of this should affect the physics subsystem.

2. Small objects not showing up in the physics.

fixed.

Confirmed. We still have problems with smaller objects like coins (seeing the debug rendering, but can't focus them). This can be fixed later.

Okay, only one bug left. Unfortunately this seems to be a hard one.

I made a little progress.
At line 130 of mwscene.cpp, the function

MWWorld::Ptr ptr = world.getPtrViaHandle (it->first);

fails, and that seems to be the cause of the bug. But i have no idea why.

I'll look into it.

That is an NPC. At the time when you get this error, it has already been removed from the scene. Apparently MWScene::removeObject doesn't handle removing actors properly.

Well, now the removeObject function support deleting actors. But deleting them lead to a crash to a crash. I'm looking into it.

Actors are now correctly being deleted i think. (if it crash, make sure you have bullet 2.77).

But it only introduce a new bug: sometimes, when you change to an exterior cell (or when you cross cell border), the program just freeze (but doesn't crash), and in debug mode it just quit, with absolutely no info (it's the first time I see this with the debugger). I'am sure the problem isn't with the PhysicActor code.

This is very strange indeed. But I managed to get a stack trace from a lock-up:

0x0000000000941d66 in btHashedOverlappingPairCache::removeOverlappingPair(btBroadphaseProxy*, btBroadphaseProxy*, btDispatcher*) ()
(gdb) bt
#0 0x0000000000941d66 in btHashedOverlappingPairCache::removeOverlappingPair(btBroadphaseProxy*, btBroadphaseProxy*, btDispatcher*) ()
#1 0x0000000000941ff4 in btHashedOverlappingPairCache::processAllOverlappingPairs(btOverlapCallback*, btDispatcher*) ()
#2 0x0000000000941c2a in btHashedOverlappingPairCache::removeOverlappingPairsContainingProxy(btBroadphaseProxy*, btDispatcher*) ()
#3 0x00000000007c0996 in OEngine::Physic::PhysicEngine::removeRigidBody(std::string) ()
#4 0x00000000007e0ee5 in MWRender::MWScene::removeObject(std::string const&) ()
#5 0x000000000088634d in MWWorld::World::unloadCell(std::_Rb_tree_iterator<std::pair<ESMS::CellStore<MWWorld::RefData>* const, MWRender::CellRender*> >) ()
#6 0x0000000000886897 in MWWorld::World::changeCell(int, int, ESM::Position const&, bool) ()
#7 0x000000000088a503 in MWWorld::World::moveObject(MWWorld::Ptr, float, float, float) ()
#8 0x00000000007e0ad8 in MWRender::MWScene::doPhysics(float, MWWorld::World&, std::vector<std::pair<std::string, Ogre::Vector3>, std::allocator<std::pair<std::string, Ogre::Vector3> > > const&) ()
#9 0x000000000088a72b in MWWorld::World::doPhysics(std::vector<std::pair<std::string, Ogre::Vector3>, std::allocator<std::pair<std::string, Ogre::Vector3> > > const&, float) ()
#10 0x00000000007d68d6 in OMW::Engine::frameStarted(Ogre::FrameEvent const&) ()
#11 0x00007ffff797c574 in Ogre::Root::_fireFrameStarted (
---Type <return> to continue, or q <return> to quit---
this=<value optimised out>, evt=<value optimised out>)
at /home/marc/Tools/ogre-1-7-1/OgreMain/src/OgreRoot.cpp:804
#12 0x00007ffff797d2c9 in Ogre::Root::_fireFrameStarted (this=0x7ffff7ec18d8)
at /home/marc/Tools/ogre-1-7-1/OgreMain/src/OgreRoot.cpp:876
#13 0x00007ffff797d329 in Ogre::Root::renderOneFrame (this=0x2)
at /home/marc/Tools/ogre-1-7-1/OgreMain/src/OgreRoot.cpp:963
#14 0x00007ffff797d39d in Ogre::Root::startRendering (this=0x7ffff7ec18d8)
at /home/marc/Tools/ogre-1-7-1/OgreMain/src/OgreRoot.cpp:956
#15 0x00000000007a9c3b in OEngine::Render::OgreRenderer::start() ()
#16 0x00000000007d8f3c in OMW::Engine::go() ()
#17 0x00000000007cfdf5 in main ()

Thanks, this help a lot.

Fixed it think

Lesson of the day: always keep your libraries up-to-date!

But performances are really bad for exteriors cells.

Yeah, that did it! Great! OpenMW 0.10.0 tagged. I will start the release process now.

Don't worry about performance. OpenMW is supposed the be slow at this stage, because we haven't done any optimisations yet. This is on the roadmap for 0.11.0.

gus, do you want to continue with physics for 0.11.0 (the stairs problems and such)? Or rather take a break from it and do something else for a while?

I would prefer to take a break and do something else. Also, I will have many exams so I can't predict how much time I will be able to give until July.

Okay. I added the physics cleanup task under "Other Tasks/Other Stuff", flagged as "Unassigned".

You might work on the Terrain rendering.

I might, but it's a rather huge task. I will begin with optimization, which shouldn't be too hard i think.

Definitely not trivial. You have to consider how to group references. Put everything together and rebuild the entire batch at each cell change? Or one batch per cell? Also, you need to handle the case when the world is changed. Maybe putting references that are more likely to change into a separate batch? Or maybe not. Lots of questions to consider. But we better handle that in a separate thread.

I just noticed how problematic NPC activation is. Here is an issue for it: http://bugs.openmw.org/issues/131

@gus (and probably jhooks): Would you mind having a look at it? I guess it wouldn't be too hard or time-consuming to fix.

When you trigger the debug rendering, you can see why it doesn't work right.

First, the capsule shape is probably to big.
Second, either the capsule shape is low, either the NPC visual mesh is too high (no idea which one is correct. Maybe the TES could answere that). Or maybe both.

But right now i don't have the time/energy to debug this.