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

A place to show off your latest screenshots and for people to comment on them. Only start a new thread here if you have some nice images to show off!

Re: MOC - Minimal Ogre Collision - Demo1.0 Beta [Demo+Src+Video]

Postby ludollu » Wed Mar 18, 2009 11:36 am

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.
ludollu
Kobold
 
Posts: 38
Kudos: 0
Joined: 03 Apr 2007

Re: MOC - Minimal Ogre Collision - Demo1.0 Beta [Demo+Src+Video]

Postby westpointer » Sun Mar 29, 2009 3:46 pm

ludollu wrote: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.php?f=2&t=48180&p=330395
http://www.ogre3d.org/forums/viewtopic.php?f=2&t=48209&p=330558
User avatar
westpointer
Halfling
 
Posts: 62
Kudos: 0
Joined: 23 May 2008

Re: MOC - Minimal Ogre Collision - Demo1.0 Beta [Demo+Src+Video]

Postby Nauk » Mon Mar 30, 2009 7:58 pm

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 :)
User avatar
Nauk
Gnoll
 
Posts: 647
Kudos: 25
Joined: 11 May 2006
Location: Bavaria

Re: MOC - Minimal Ogre Collision - Demo1.0 Beta [Demo+Src+Video]

Postby adanar » Thu Apr 09, 2009 4:19 pm

I seem to be having the same aforementioned problem. Raycasting behaves very strangely for me also and I am also using Shoggoth.
adanar
Gnoblar
 
Posts: 23
Kudos: 0
Joined: 19 Feb 2006
Location: Greece, Crete

Re: MOC - Minimal Ogre Collision - Demo1.0 Beta [Demo+Src+Video]

Postby Nauk » Thu Apr 09, 2009 11:13 pm

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?
User avatar
Nauk
Gnoll
 
Posts: 647
Kudos: 25
Joined: 11 May 2006
Location: Bavaria

Re: MOC - Minimal Ogre Collision - Demo1.0 Beta [Demo+Src+Video]

Postby westpointer » Fri Apr 10, 2009 4:53 pm

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, :oops:
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.
User avatar
westpointer
Halfling
 
Posts: 62
Kudos: 0
Joined: 23 May 2008

Re: MOC - Minimal Ogre Collision - Demo1.0 Beta [Demo+Src+Video]

Postby Nauk » Fri Apr 10, 2009 10:47 pm

I'll have a look into it :) just may take a bit, since I am very much drowning in work right now.
User avatar
Nauk
Gnoll
 
Posts: 647
Kudos: 25
Joined: 11 May 2006
Location: Bavaria

Re: MOC - Minimal Ogre Collision - Demo1.0 Beta [Demo+Src+Video]

Postby adanar » Sat Apr 11, 2009 7:55 am

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..
adanar
Gnoblar
 
Posts: 23
Kudos: 0
Joined: 19 Feb 2006
Location: Greece, Crete

Re: MOC - Minimal Ogre Collision - Demo1.0 Beta [Demo+Src+Video]

Postby raygeee » Mon Apr 13, 2009 2:04 pm

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.
raygeee
Gnoblar
 
Posts: 6
Kudos: 0
Joined: 08 Jan 2008

Re: MOC - Minimal Ogre Collision - Demo1.0 Beta [Demo+Src+Video]

Postby adanar » Tue Apr 14, 2009 1:57 pm

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?
adanar
Gnoblar
 
Posts: 23
Kudos: 0
Joined: 19 Feb 2006
Location: Greece, Crete

Re: MOC - Minimal Ogre Collision - Demo1.0 Beta [Demo+Src+Video]

Postby raygeee » Tue Apr 14, 2009 6:43 pm

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/viewtopic.php?f=8&t=8615
raygeee
Gnoblar
 
Posts: 6
Kudos: 0
Joined: 08 Jan 2008

Re: MOC - Minimal Ogre Collision - Demo1.0 Beta [Demo+Src+Video]

Postby raygeee » Wed Apr 15, 2009 5:26 pm

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.
raygeee
Gnoblar
 
Posts: 6
Kudos: 0
Joined: 08 Jan 2008

Re: MOC - Minimal Ogre Collision - Demo1.0 Beta [Demo+Src+Video]

Postby Nauk » Wed Apr 15, 2009 8:19 pm

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 :)
User avatar
Nauk
Gnoll
 
Posts: 647
Kudos: 25
Joined: 11 May 2006
Location: Bavaria

Re: MOC - Minimal Ogre Collision - Demo1.0 Beta [Demo+Src+Video]

Postby raygeee » Wed Apr 15, 2009 10:28 pm

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:
smiley80 wrote: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.

Bekas wrote: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?
raygeee
Gnoblar
 
Posts: 6
Kudos: 0
Joined: 08 Jan 2008

Re: MOC - Minimal Ogre Collision - Demo1.0 Beta [Demo+Src+Video]

Postby Nauk » Thu Apr 16, 2009 12:17 am

raygeee wrote: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:
smiley80 wrote: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.

Bekas wrote: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 :)
User avatar
Nauk
Gnoll
 
Posts: 647
Kudos: 25
Joined: 11 May 2006
Location: Bavaria

Re: MOC - Minimal Ogre Collision - Demo1.0 Beta [Demo+Src+Video]

Postby deadvirus » Wed Apr 22, 2009 8:31 pm

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
The absence of light,
DeadVirus.
User avatar
deadvirus
Gnoblar
 
Posts: 13
Kudos: 0
Joined: 13 Mar 2009

Re: MOC - Minimal Ogre Collision - Demo1.0 Beta [Demo+Src+Video]

Postby Nauk » Thu Apr 23, 2009 3:19 pm

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.
User avatar
Nauk
Gnoll
 
Posts: 647
Kudos: 25
Joined: 11 May 2006
Location: Bavaria

Re: MOC - Minimal Ogre Collision - Demo1.0 Beta [Demo+Src+Video]

Postby deadvirus » Thu Apr 23, 2009 10:11 pm

Nauk wrote: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.
User avatar
deadvirus
Gnoblar
 
Posts: 13
Kudos: 0
Joined: 13 Mar 2009

Re: MOC - Minimal Ogre Collision - Demo1.0 Beta [Demo+Src+Video]

Postby pythonCode » Sun Apr 26, 2009 4:24 pm

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.
pythonCode
Gnoblar
 
Posts: 6
Kudos: 0
Joined: 15 Feb 2009

Re: MOC - Minimal Ogre Collision - Demo1.0 Beta [Demo+Src+Video]

Postby Nauk » Mon Apr 27, 2009 8:50 pm

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
User avatar
Nauk
Gnoll
 
Posts: 647
Kudos: 25
Joined: 11 May 2006
Location: Bavaria

Re: MOC - Minimal Ogre Collision - Demo1.0 Beta [Demo+Src+Video]

Postby deadvirus » Wed Apr 29, 2009 11:27 pm

There's something I don't understand, why did you cast Entity* to ulong in raycast?
The absence of light,
DeadVirus.
User avatar
deadvirus
Gnoblar
 
Posts: 13
Kudos: 0
Joined: 13 Mar 2009

Re: MOC - Minimal Ogre Collision - Demo1.0 Beta [Demo+Src+Video]

Postby Nauk » Thu Apr 30, 2009 3:00 pm

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 :)
User avatar
Nauk
Gnoll
 
Posts: 647
Kudos: 25
Joined: 11 May 2006
Location: Bavaria

Re: MOC - Minimal Ogre Collision - Demo1.0 Beta [Demo+Src+Video]

Postby xabila » Fri May 01, 2009 3:53 pm

Hi,
Have you update the source since january or it's the same version on your site?
Thanks
User avatar
xabila
Goblin
 
Posts: 225
Kudos: 0
Joined: 05 Jun 2006
Location: rennes [FR]

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

Postby Nauk » Sun May 03, 2009 2:15 pm

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
User avatar
Nauk
Gnoll
 
Posts: 647
Kudos: 25
Joined: 11 May 2006
Location: Bavaria

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

Postby deadvirus » Sun May 03, 2009 11:10 pm

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.
The absence of light,
DeadVirus.
User avatar
deadvirus
Gnoblar
 
Posts: 13
Kudos: 0
Joined: 13 Mar 2009

PreviousNext

Return to Showcase

Who is online

Users browsing this forum: No registered users and 2 guests