Page 1 of 8

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

Posted: Tue Oct 21, 2008 6:24 pm
by Nauk
MOC - Minimal Ogre Collision 1.0 (Update 03.05.09)

Link to the Video:

Hey everyone, since collision-detection seems to be an ongoing topic and people keep asking about simple collision and more accurate mousepicking we decided to pack our collision routines into a lightweight and easy to use mini-toolkit, named MOC - Minimal Ogre Collision.

MOC is based on the Ogre forum & wiki entries: ... ygon_level

MOC does not aim to and is by no means able to be a replacement for the use of a full blown physics or collision library. It is rather a solution for situations where integrating a physics library would be a total overkill: like mousepicking in editor applications, quest & turn based rpgs, architectural presentations, quick prototypes, demos etc. Simply in all cases where you only need a basic collision-detection or picking and nothing else.

So far we could not detect a notable performance tax when using it. Looking at the demo - you can turn it off entirely pressing C and the FPS meter doesn't show a messurable difference. We had similar good results testing it in bigger scenarios with many more objects in the scene.

- Simple accurate mousepicking on vertex level, means if you click on a mesh the mesh is only detected if you hit the actual mesh and not the bounding box.
- Simple collision detection, for example to prevent the camera from moving through walls, or enable walking and driving on objects like bridges, roadmeshes, etc.
- Supports ETM, TSM & Meshbased terrains
- Easy to setup and use. MOC only consist of 2 files CollisionTools.h + .cpp
- Open Source under the MIT license allows to use it like you wish, commercial or non-commerical

- MOC demo 1.0 beta - win32 demo,binaries, source and media ~ 46MB
- MOC demo 1.0 beta - VC++ 2005 express project files, sources
- Latest - MOC toolkit source
- Latest - MMOC toolkit source for MOgre

Future Plans:
- Support for BSP
- Static Geometry

- MOC - Google Code

- MOC on

Since this is not only my doing:
Thanks & credits to Wannabee who helped a lot with the implementation and Eliah for making the video.

Hopefully some of you find it useful :)


Posted: Tue Oct 21, 2008 8:33 pm
by altren
Great! I think such tool will be really useful.
Are you going to update it or it's one time release?

Posted: Tue Oct 21, 2008 8:41 pm
by betajaen

It's about time Ogre has something like this.

Posted: Tue Oct 21, 2008 9:59 pm
by bharling
Very useful indeed, I second comments before - ogre needs a very simple collision lib when true physics is not required.

At the risk of over complicating things, can I recommend adding some simple octree culling into the routine, might speed things up considerably

Posted: Tue Oct 21, 2008 11:08 pm
by Duncan Mac Leod
Thank you so much...

I will try it out as soon as time permits :wink:

Posted: Wed Oct 22, 2008 1:52 am
by novaumas
Great project, I love the non intrusive nature of it: Just add the two files to a project and start using it.

Posted: Wed Oct 22, 2008 6:44 am
by crioto
Looks nice!!!

Posted: Wed Oct 22, 2008 12:27 pm
by Nargil
A shame I've already started writing my editor with a physics library. But at least I can simulate the physics to see if an object isn't thrown into the space because it's placed inside the floor ;)

Posted: Wed Oct 22, 2008 12:40 pm
by manowar
If I understand well, this is similar as OgreOpcode...but does not use opcode then ?

Posted: Wed Oct 22, 2008 3:23 pm
by Jabberwocky
This is a great gift for people who want to get something simple working, and maybe don't have the time, programming experience, or need for something more complicated.

Nice work. :)

Posted: Wed Oct 22, 2008 3:36 pm
by alexdbkim
Wow~ it must be a hard work. Excellent =)

Posted: Wed Oct 22, 2008 6:25 pm
by oddrose
Great, great!

Posted: Wed Oct 22, 2008 7:47 pm
by Nauk
@Altren: We will update and continue working on it to improve performance and features, also the reason we put it up on sourceforge so hopefully others will contribute ideas and code.

@Bharling: I will definately have a look into that, at this point I have to admit I only know the very basics about culling mechanics and possible implementations, but I already started reading up on it, since it sounds like a good thing to do. If you have more detailed suggestions, pointers or ideas about it feel free to post them here or on the MOC forum: ... ?board=7.0 - will be definately greatly appreciated.

@Nargil: But then you got it already up and running which is what counts :) and there is always the possibility to try it in the next project.

@Manowar: Both have the same basic purpose, but Opcode has definately way more features and is likely more performant, where MOC is easier to integrate and lightweight.

Many thanks for the overly nice feedback everyone on behalf of our humble team :)

Posted: Wed Oct 22, 2008 8:18 pm
by vilgeits
Great and simply :D

Posted: Fri Oct 24, 2008 1:01 pm
by sinbad
Nice work - for those that don't want to go all the way to Opcode or to a physics engine I can see this being very useful.

MOC feature request

Posted: Fri Oct 24, 2008 2:27 pm
by rukos1

i tried out MOC and it works fine.
The CollisionTools::raycastFromCamera method expects an const OIS::MouseEvent param.
What do you think about a downgrade to an OIS::MouseState struct? You just use the mouse position in this function. This could reduce the dependencies.

best regards rukos1

Posted: Fri Oct 24, 2008 3:55 pm
by Praetor
I actually completely removed the OIS dependency and had that function take in Ogre::Real x and y parameters for viewport-relative mouse positions.

Posted: Fri Oct 24, 2008 5:26 pm
by Nauk
@vilgeits: thank you very much :)

@sinbad: thanks a lot, your feedback means a lot for us :)

@rukos1 & praetor: many thanks for testing and input :) , you both are totally right, changing it to x,y parameters to remove the OIS dependency.

another MOC feature request

Posted: Thu Oct 30, 2008 1:54 pm
by rukos1

I tried to pick an BillboardSet, but they were not recognized, because Billboards are not intented. To allow this I added the entry:
mRaySceneQuery->setQueryTypeMask(SceneManager::FX_TYPE_MASK | SceneManager::ENTITY_TYPE_MASK);
into the constructor.
But in method CollisionTools::raycast is an explicit check if the object is an entity. Could the next version consider Billboardsets please. A flexible solution would be to allow the user to set the QueryTypeMask...

Another point is the returned target as ulong value.
Why don´t you just return a movable pointer without this horrible cast?

Thanks for your work!

Posted: Thu Oct 30, 2008 6:44 pm
by Nauk
Good point, thanks for the input rukos1, I will add/modify both and you are welcome :)

Posted: Thu Oct 30, 2008 9:39 pm
by jacmoe
Great work!
I approve of the MOC! :)

About time that Ogre got a collision lib using nothing but Ogre. :wink:

Posted: Sat Nov 01, 2008 4:40 pm
by Nauk
We are happy you like the MOC! - thank you for the kind words jacmoe :)

Posted: Tue Nov 04, 2008 2:03 pm
by nikki
Thanks a lot for this! I'm working on a little demo/tutorial for NGF, and I wanted to include some simple collision detection, without placing dependencies on a full-blown physics engine or collision library. Looks like this is what I need! :)


Posted: Wed Nov 05, 2008 12:09 pm
by tourist
Thanks for this great and solid contribution. Its an awesome feature, solid, simple, and eficient

Posted: Wed Nov 05, 2008 7:07 pm
by Nauk
Thanks Nikki and tourist for the great feedback, very rewarding for us :)