MOC - Minimal Ogre Collision 1.0 - [Update 03.May.2009]

[ludollu]

Finnaly I use classical picking (with AABB).
And, for my particular case (manualObject in a plane), I test if the coordinate of the ray with a plane "is in my manualObject".
To do that I use manualObject features save all the time (MVC).

It's work and for now is enough.

[westpointer]

Hi everyone !
I'm a MOC user.

I create a beautiful manualObject (a 3d triangle) with OT_TRIANGLE_LIST renderOperation
after that I convert it in mesh (convertToMesh).

Then I use MOC for picking.
But, the function GetMeshInformation return strange result.

Code: Select all

GetMeshInformation(entity->getMesh(), vertex_count, vertices, index_count, indices,
entity->getParentNode()->_getDerivedPosition(),
entity->getParentNode()->_getDerivedOrientation(),
entity->getParentNode()->getScale());

The vertex position seem wrong.
My triangle is in a plan (with y aligned) and I have some vertex with y=1 and other with y=-1

I change the function getMeshInformation to use directly the matrix 4x4 representing the full transformation.

Code: Select all

newGetMeshInformation(entity->getMesh(), vertex_count, vertices, index_count, indices,
entity->_getParentNodeFullTransform());

I have the same results :'(

I probably make a mistake !
So if you have a idea ...

After changing to Ogre 1.6.1, I get similar problems as ludollu. They are:
1. Picking seems totally wrong, eg, when you click on some place near the tree, but the bounding box of the tree shows.
2. When the camera is facing upwards(pitching about 90 degree) or downwards(pitching about -90 degree) while moving, the program is dead, seems infinit loop.

The only change I made while using 1.6.1 is GetMeshInformation. I searched the forum and find people have similar problems:
http://www.ogre3d.org/forums/viewtopic. ... 0&p=330395
http://www.ogre3d.org/forums/viewtopic. ... 9&p=330558

[Nauk]

I will look into it, I am just in the middle of migrating everything to Ogre 1.61, but so far I haven't found anything not working, but I'll check

[adanar]

I seem to be having the same aforementioned problem. Raycasting behaves very strangely for me also and I am also using Shoggoth.

[Nauk]

I just migrated my gameproject to Ogre 1.61 and I am using MOC there for picking and player collision, no problem this far. Does the MOC demo application work for you?

[westpointer]

Finally, I solved the picking problem I mentioned above.
It is not the problem of MOC, it is sth I neglect.
That is MOC use OIS mouse position to picking, and I use CEGUI, but my CEGUI mouse(shown) position
and OIS mouse(hidden) position does not coincide or overlapped. So, it is all my fault,
I tried two way to solve it, either works:
1. make my CEGUI mouse and OIS mouse overlapped;
2. Or use CEGUI mouse position to do picking.


But my second problem still exists, that is When the camera is facing upwards(pitching about 90 degree) or
downwards(pitching about -90 degree) while moving, the program is dead, likely it falls into infinit loop.

[Nauk]

I'll have a look into it just may take a bit, since I am very much drowning in work right now.

[adanar]

I am still having trouble. I dont use MOC for mousepicking but rather for raycasting which means that the CEGUI-OIS mouse problem dows not apply in my case since the raycasting starts form the position of an object in world space and not the mouse position.. I'll keep looking and if I solve it will get back to u..

[raygeee]

Thanks for sharing this code with us. Works great! (I'm using the C# port MMOC with Mogre)

One Question:
If I use CollidesWithEntity() while running Hydrax in ProjectedGrid mode I get a System.OverflowException in the function Raycast. I'm guessing it's because Hydrax has just too many vertices to calculate (Hydrax always draws the water underneath the terrain in ProjectedGrid mode). I just wanted to ask if you're experiencing the same issue with MOC too. If not, it might be some issue in the C# port.

I've used TSM with the demo terrain.cfg (adjusted MaxHeight to 200), a collision radius of 20 and no QueryFlags.
The exception should occur in this line:

Code: Select all

// check for a hit against this triangle
 std::pair<bool, Ogre::Real> hit = Ogre::Math::intersects(ray, vertices[indices[i]],
    vertices[indices[i+1]], vertices[indices[i+2]], true, false);

It's not that important since Hydrax isn't supposed to work on a big terrain for inland sea rendering, just curious.

[adanar]

ok now it works great, it was my mistake

One final question. Do u know what Ogre methods I should use to implement an entity to entity collision check?

[raygeee]

I'm putting that question regarding Hydrax and the OverflowException on hold - We don't have solution yet but the cause seems clear: the datatype of the index of vertices is the cause.
Just as information: MMOC Thread http://www.ogre3d.org/addonforums/viewt ... f=8&t=8615

[raygeee]

I had to change one datatype in GetMeshInformation() from unsigned long* to int* on the following line 408 to make MMOC run with Hydrax

Code: Select all

unsigned long*  pLong = static_cast<unsigned long*>(ibuf->lock(Ogre::HardwareBuffer::HBL_READ_ONLY));

Although I've got the feeling that I'm "cutting" some values...
The thing is that I need all values in indices[] to be not greater than Int32.MaxValue. This hack helped preventing it for now, but since the offset gets added and indices[] is still unsigned long I can't be sure of it. Is there a way to rewrite the code with all indices[] values to be int?

And another question:
How can I be sure that collision detection stills works fine? Collision detection with camera works fine as far as I can tell. But about collision detection between objects I'm not so sure. It didn't work all the time before, so I can't tell if something changed now.
Example: I've got a Robot entity walking over the terrain which uses CollidesWithEntity every step it takes. Now if there is a Tudorhouse entity standing in the way sometimes it doesn't walk at all, sometimes it just walks through. The same happens if I put a Ninja entity in the way of the Robot.

This leads me to a general question: Is MOC designed to handle collision detection between (moving) objects? I'm not very sure since they wouldn't need it at vertex level, only the camera does.

[Nauk]

About the int32 conversion, I honestly never checked what datatype the indices really need, but you could easily find out debugging them without Hydrax, as ulong and see what values you get.

As for the general design of MOC and moving entities, MOC is basically nothing else than a comfort wrapper around the wiki example raycasting down to polygon level. So what happens is, a ray is send from the position you define, in the collisidesWithEntity method it originates from your node coordinates + rayHeightLevel on the Y-Axis. If the ray hits an object, the vertex data is retrieved and the polygon where the ray hits is calculated and then the exact intersection with that polygon in question. Taking that, it should not matter if the object is moving, because as I understand it at the very moment of a raycast nothing moves untill the next frame is rendered. You also could watch the raycasting in your debugger and see what results you get.

Now one ray is very thin and might go right through something like a window or a pair of legs etc, if you want to be more on the secure side, you could cast more than one ray parallel. That is what MOC is doing in calculateY if you enable the gridcheck, 2 rays are being cast to decrease the probability to fall through gridbojects, handbridges, etc.

Code: Select all

collidesWithEntity(const Ogre::Vector3& fromPoint, const Ogre::Vector3& toPoint, const float collisionRadius, const float rayHeightLevel, const Ogre::uint32 queryMask)

One thing that could be the reason assuming you don't have a problem with casting down from ulong to int32, your rayHeightLevel could be set wrong?

Anyway if you don't need accurate collision between your moving objects, why dont you simply check the distance between them and iterate through all objects in question and check their proximity, not very fancy, but does the trick and should be more than fast enough

[raygeee]

Thanks for the long answer, I'll keep those multiple raycasts in mind when I'm testing it.

There are two things which came up in the MMOC thread that I didn't want to withhold:

The problem is, that if the 'fromPoint' is inside the entity it will collide with the mesh of the entity.
So you can either specify a point that is outside the mesh or add a filter for that entity in Raycast.

Maybe that's a explanation for my entities not starting walking.

IMO the choice of "unsigned long" from the original C++ author is an unfortunate one. Indices for the GPU are either 2 bytes (use32bitindexes == false) or 4 bytes (use32bitindexes == true). "unsigned long" in C++ is 4 bytes for 32bit platforms and all is good, but AFAIK "unsigned long" is 8 bytes for 64bit platforms, so the code would not work for 64bit.
Instead of "unsigned long" he should have picked an explicitly 4-byte type like Ogre::uint32 (and I think 'int' is 4 bytes on both 32 and 64 platforms but I'm not sure).

I know you aren't the original author of the raycast snippet but isn't that a modification to consider? Changing the variable's type definition to a type that's not ambiguos? Or is using a 32bit platform common assumption for code snippets?

[Nauk]

Thanks for the long answer, I'll keep those multiple raycasts in mind when I'm testing it.

There are two things which came up in the MMOC thread that I didn't want to withhold:

The problem is, that if the 'fromPoint' is inside the entity it will collide with the mesh of the entity.
So you can either specify a point that is outside the mesh or add a filter for that entity in Raycast.

Maybe that's a explanation for my entities not starting walking.

Very possible.

IMO the choice of "unsigned long" from the original C++ author is an unfortunate one. Indices for the GPU are either 2 bytes (use32bitindexes == false) or 4 bytes (use32bitindexes == true). "unsigned long" in C++ is 4 bytes for 32bit platforms and all is good, but AFAIK "unsigned long" is 8 bytes for 64bit platforms, so the code would not work for 64bit.
Instead of "unsigned long" he should have picked an explicitly 4-byte type like Ogre::uint32 (and I think 'int' is 4 bytes on both 32 and 64 platforms but I'm not sure).

I know you aren't the original author of the raycast snippet but isn't that a modification to consider? Changing the variable's type definition to a type that's not ambiguos? Or is using a 32bit platform common assumption for code snippets?

Good find and seems like no way around adding/changing that

[deadvirus]

Hello,
First, I want to say thanks for MOC! It is really useful!!!

So far, I have two questions:

First: In CollisionTools::raycast, when calling GetMeshInformation one argument that's passed is

Code: Select all

 pentity->getParentNode()->getScale();

shouldn't it be:

Code: Select all

pentity->getParentNode()->_getDerivedScale();

Second: A little bit bellow (line 283, but I think I've changed some lines, so it could be other line)

Code: Select all

for (int i = 0; i < static_cast<int>(index_count); i += 3)
            {
                // check for a hit against this triangle
                std::pair<bool, Ogre::Real> hit = Ogre::Math::intersects(ray, vertices[indices[i]],
                    vertices[indices[i+1]], vertices[indices[i+2]], true, false);
                     ...

casting from uint to int... are you sure and int can handle all indexes?

Thanks

[Nauk]

Hey deadvirus, I am happy you like MOC and thanks for the feedback.

Now to your questions:
getScale() works this far, but I will check again, just to be sure.

About the size_t to int cast, good point and I am actually not sure it is always enough, I will look into it,
the for loop could aswell run with size_t.

Good points, thank you for spotting and bringing it up.

[deadvirus]

Hey deadvirus, I am happy you like MOC and thanks for the feedback.

Now to your questions:
getScale() works this far, but I will check again, just to be sure.

About the size_t to int cast, good point and I am actually not sure it is always enough, I will look into it,
the for loop could aswell run with size_t.

Good points, thank you for spotting and bringing it up.

Thanks for your reply.

The problem I got with getScale() was that I had something like RootSceneNode : Node1 : Node2 : TheMesh (the mesh is child of Node2, Node 2 child of Node1...).
Node1 has a scale, Node2 inherits it's parent scale... but because there was getScale(), it was only getting Node2 scale, but the "real"(world) scale was Node1*Node2 scales. So, the ray detects the mesh, but when doing triangle hit check it was not getting the correct info from the mesh.
Using _getDerivedScale() does that... get's the world scale.

I hope I explained myself correctly, English its not my first language...

For the other problem, using size_t on the loop solves the problem, and works fine. I can't see a reason to not using that.

Thank you.

[pythonCode]

Hi all. First I need to thanks nauk, MOC is great for beginners. I want to ask if it is possible to use MOC for collision detection between objects ? I am now writing a simple RPG game, I don't want to use any physics library, so I tried MOC, but I don't know how to detect if my character collides with any entities. The demo just uses the simple camera, I cannot find any hints from it. Hope you can help. Thanks.

[Nauk]

Hello pythonCode, I am happy you like it It is possible and you can find the answer here in the thread, this and last page.

HTH
/Nauk

[deadvirus]

There's something I don't understand, why did you cast Entity* to ulong in raycast?

[Nauk]

No particular reason anymore, it is just a relic from the very first versions, I should change it to Ogre::MovableObject, thanks for pointing it out Deadvirus

[xabila]

Hi,
Have you update the source since january or it's the same version on your site?
Thanks

[Nauk]

I just updated the SVN and Google Code download to the latest changes, lifting MOC out of beta status now. Thanks everyone for the nice feedback and improvment suggestions. The changes mainly are type changes:

- moved the index array from unsigned long to Ogre::uint32.
- moved the "ugly" unsigned long pointer for the target return reference, to Ogre::Entity and Ogre::Moveable (both work).
- changed the OIS::Mouseevent parameter in the raycastFromCamera method to Ogre::Vector2, removing the OIS dependency.

Smiley80 also updated MMOC (C# port for Mogre) just recently.

http://code.google.com/p/minimal-ogre-c ... n-toolkit/
(Note: the demo is still the old one)

Hope it works as it should, I tested it with my own gameclient, no problems - enjoy
/Nauk

[deadvirus]

Thanks for the update!
I've added (changed) some functions so that I can get the index of a submesh (subentity) that was hit. It's something really simple, but for now it works fine!

If you think it would be useful, I could post it here.

DeadVirus.