MOC - Minimal Ogre Collision 1.0 - [Update 03.May.2009]
-
- Kobold
- Posts: 38
- Joined: Tue Apr 03, 2007 10:38 am
Re: MOC - Minimal Ogre Collision - Demo1.0 Beta [Demo+Src+Video]
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.
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
- Halfling
- Posts: 62
- Joined: Fri May 23, 2008 9:29 am
Re: MOC - Minimal Ogre Collision - Demo1.0 Beta [Demo+Src+Video]
After changing to Ogre 1.6.1, I get similar problems as ludollu. They are: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.
The vertex position seem wrong.Code: Select all
GetMeshInformation(entity->getMesh(), vertex_count, vertices, index_count, indices, entity->getParentNode()->_getDerivedPosition(), entity->getParentNode()->_getDerivedOrientation(), entity->getParentNode()->getScale());
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.
I have the same results :'(Code: Select all
newGetMeshInformation(entity->getMesh(), vertex_count, vertices, index_count, indices, entity->_getParentNodeFullTransform());
I probably make a mistake !
So if you have a idea ...
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
- Gnoll
- Posts: 647
- Joined: Thu May 11, 2006 9:12 pm
- Location: Bavaria
- x 25
- Contact:
Re: MOC - Minimal Ogre Collision - Demo1.0 Beta [Demo+Src+Video]
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 

ARTIFEX TERRA 3D - Artist-friendly, free and easy WYSIWYG realtime outdoor scene Editor & Painter
New loader now with Ogre::Terrain support: Addons for Artifex on SourceForge
MOC - Minimal Ogre Collision & Mousepicking
Simple TerrainMaterialGenerator for the use of standard Ogre material with Ogre::Terrain
New loader now with Ogre::Terrain support: Addons for Artifex on SourceForge
MOC - Minimal Ogre Collision & Mousepicking
Simple TerrainMaterialGenerator for the use of standard Ogre material with Ogre::Terrain
-
- Gnoblar
- Posts: 23
- Joined: Sun Feb 19, 2006 9:06 pm
- Location: Greece, Crete
Re: MOC - Minimal Ogre Collision - Demo1.0 Beta [Demo+Src+Video]
I seem to be having the same aforementioned problem. Raycasting behaves very strangely for me also and I am also using Shoggoth.
- Nauk
- Gnoll
- Posts: 647
- Joined: Thu May 11, 2006 9:12 pm
- Location: Bavaria
- x 25
- Contact:
Re: MOC - Minimal Ogre Collision - Demo1.0 Beta [Demo+Src+Video]
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?
ARTIFEX TERRA 3D - Artist-friendly, free and easy WYSIWYG realtime outdoor scene Editor & Painter
New loader now with Ogre::Terrain support: Addons for Artifex on SourceForge
MOC - Minimal Ogre Collision & Mousepicking
Simple TerrainMaterialGenerator for the use of standard Ogre material with Ogre::Terrain
New loader now with Ogre::Terrain support: Addons for Artifex on SourceForge
MOC - Minimal Ogre Collision & Mousepicking
Simple TerrainMaterialGenerator for the use of standard Ogre material with Ogre::Terrain
- westpointer
- Halfling
- Posts: 62
- Joined: Fri May 23, 2008 9:29 am
Re: MOC - Minimal Ogre Collision - Demo1.0 Beta [Demo+Src+Video]
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.
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
- Gnoll
- Posts: 647
- Joined: Thu May 11, 2006 9:12 pm
- Location: Bavaria
- x 25
- Contact:
Re: MOC - Minimal Ogre Collision - Demo1.0 Beta [Demo+Src+Video]
I'll have a look into it
just may take a bit, since I am very much drowning in work right now.

ARTIFEX TERRA 3D - Artist-friendly, free and easy WYSIWYG realtime outdoor scene Editor & Painter
New loader now with Ogre::Terrain support: Addons for Artifex on SourceForge
MOC - Minimal Ogre Collision & Mousepicking
Simple TerrainMaterialGenerator for the use of standard Ogre material with Ogre::Terrain
New loader now with Ogre::Terrain support: Addons for Artifex on SourceForge
MOC - Minimal Ogre Collision & Mousepicking
Simple TerrainMaterialGenerator for the use of standard Ogre material with Ogre::Terrain
-
- Gnoblar
- Posts: 23
- Joined: Sun Feb 19, 2006 9:06 pm
- Location: Greece, Crete
Re: MOC - Minimal Ogre Collision - Demo1.0 Beta [Demo+Src+Video]
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..
-
- Gnoblar
- Posts: 6
- Joined: Tue Jan 08, 2008 10:54 pm
Re: MOC - Minimal Ogre Collision - Demo1.0 Beta [Demo+Src+Video]
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:
It's not that important since Hydrax isn't supposed to work on a big terrain for inland sea rendering, just curious.
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);
-
- Gnoblar
- Posts: 23
- Joined: Sun Feb 19, 2006 9:06 pm
- Location: Greece, Crete
Re: MOC - Minimal Ogre Collision - Demo1.0 Beta [Demo+Src+Video]
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?
One final question. Do u know what Ogre methods I should use to implement an entity to entity collision check?
-
- Gnoblar
- Posts: 6
- Joined: Tue Jan 08, 2008 10:54 pm
Re: MOC - Minimal Ogre Collision - Demo1.0 Beta [Demo+Src+Video]
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
Just as information: MMOC Thread http://www.ogre3d.org/addonforums/viewt ... f=8&t=8615
-
- Gnoblar
- Posts: 6
- Joined: Tue Jan 08, 2008 10:54 pm
Re: MOC - Minimal Ogre Collision - Demo1.0 Beta [Demo+Src+Video]
I had to change one datatype in GetMeshInformation() from unsigned long* to int* on the following line 408 to make MMOC run with Hydrax 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.
Code: Select all
unsigned long* pLong = static_cast<unsigned long*>(ibuf->lock(Ogre::HardwareBuffer::HBL_READ_ONLY));

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
- Gnoll
- Posts: 647
- Joined: Thu May 11, 2006 9:12 pm
- Location: Bavaria
- x 25
- Contact:
Re: MOC - Minimal Ogre Collision - Demo1.0 Beta [Demo+Src+Video]
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.
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
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)
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

ARTIFEX TERRA 3D - Artist-friendly, free and easy WYSIWYG realtime outdoor scene Editor & Painter
New loader now with Ogre::Terrain support: Addons for Artifex on SourceForge
MOC - Minimal Ogre Collision & Mousepicking
Simple TerrainMaterialGenerator for the use of standard Ogre material with Ogre::Terrain
New loader now with Ogre::Terrain support: Addons for Artifex on SourceForge
MOC - Minimal Ogre Collision & Mousepicking
Simple TerrainMaterialGenerator for the use of standard Ogre material with Ogre::Terrain
-
- Gnoblar
- Posts: 6
- Joined: Tue Jan 08, 2008 10:54 pm
Re: MOC - Minimal Ogre Collision - Demo1.0 Beta [Demo+Src+Video]
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:
There are two things which came up in the MMOC thread that I didn't want to withhold:
Maybe that's a explanation for my entities not starting walking.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.
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?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).
- Nauk
- Gnoll
- Posts: 647
- Joined: Thu May 11, 2006 9:12 pm
- Location: Bavaria
- x 25
- Contact:
Re: MOC - Minimal Ogre Collision - Demo1.0 Beta [Demo+Src+Video]
Very possible.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:Maybe that's a explanation for my entities not starting walking.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.
Good find and seems like no way around adding/changing thatI 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?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).

ARTIFEX TERRA 3D - Artist-friendly, free and easy WYSIWYG realtime outdoor scene Editor & Painter
New loader now with Ogre::Terrain support: Addons for Artifex on SourceForge
MOC - Minimal Ogre Collision & Mousepicking
Simple TerrainMaterialGenerator for the use of standard Ogre material with Ogre::Terrain
New loader now with Ogre::Terrain support: Addons for Artifex on SourceForge
MOC - Minimal Ogre Collision & Mousepicking
Simple TerrainMaterialGenerator for the use of standard Ogre material with Ogre::Terrain
- deadvirus
- Gnoblar
- Posts: 13
- Joined: Fri Mar 13, 2009 5:57 pm
Re: MOC - Minimal Ogre Collision - Demo1.0 Beta [Demo+Src+Video]
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
shouldn't it be:
Second: A little bit bellow (line 283, but I think I've changed some lines, so it could be other line)
casting from uint to int... are you sure and int can handle all indexes?
Thanks
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();
Code: Select all
pentity->getParentNode()->_getDerivedScale();
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);
...
Thanks
The absence of light,
DeadVirus.
DeadVirus.
- Nauk
- Gnoll
- Posts: 647
- Joined: Thu May 11, 2006 9:12 pm
- Location: Bavaria
- x 25
- Contact:
Re: MOC - Minimal Ogre Collision - Demo1.0 Beta [Demo+Src+Video]
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.

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.
ARTIFEX TERRA 3D - Artist-friendly, free and easy WYSIWYG realtime outdoor scene Editor & Painter
New loader now with Ogre::Terrain support: Addons for Artifex on SourceForge
MOC - Minimal Ogre Collision & Mousepicking
Simple TerrainMaterialGenerator for the use of standard Ogre material with Ogre::Terrain
New loader now with Ogre::Terrain support: Addons for Artifex on SourceForge
MOC - Minimal Ogre Collision & Mousepicking
Simple TerrainMaterialGenerator for the use of standard Ogre material with Ogre::Terrain
- deadvirus
- Gnoblar
- Posts: 13
- Joined: Fri Mar 13, 2009 5:57 pm
Re: MOC - Minimal Ogre Collision - Demo1.0 Beta [Demo+Src+Video]
Thanks for your reply.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.
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.
-
- Gnoblar
- Posts: 6
- Joined: Sun Feb 15, 2009 7:48 pm
Re: MOC - Minimal Ogre Collision - Demo1.0 Beta [Demo+Src+Video]
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
- Gnoll
- Posts: 647
- Joined: Thu May 11, 2006 9:12 pm
- Location: Bavaria
- x 25
- Contact:
Re: MOC - Minimal Ogre Collision - Demo1.0 Beta [Demo+Src+Video]
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

HTH
/Nauk
ARTIFEX TERRA 3D - Artist-friendly, free and easy WYSIWYG realtime outdoor scene Editor & Painter
New loader now with Ogre::Terrain support: Addons for Artifex on SourceForge
MOC - Minimal Ogre Collision & Mousepicking
Simple TerrainMaterialGenerator for the use of standard Ogre material with Ogre::Terrain
New loader now with Ogre::Terrain support: Addons for Artifex on SourceForge
MOC - Minimal Ogre Collision & Mousepicking
Simple TerrainMaterialGenerator for the use of standard Ogre material with Ogre::Terrain
- deadvirus
- Gnoblar
- Posts: 13
- Joined: Fri Mar 13, 2009 5:57 pm
Re: MOC - Minimal Ogre Collision - Demo1.0 Beta [Demo+Src+Video]
There's something I don't understand, why did you cast Entity* to ulong in raycast?
The absence of light,
DeadVirus.
DeadVirus.
- Nauk
- Gnoll
- Posts: 647
- Joined: Thu May 11, 2006 9:12 pm
- Location: Bavaria
- x 25
- Contact:
Re: MOC - Minimal Ogre Collision - Demo1.0 Beta [Demo+Src+Video]
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 

ARTIFEX TERRA 3D - Artist-friendly, free and easy WYSIWYG realtime outdoor scene Editor & Painter
New loader now with Ogre::Terrain support: Addons for Artifex on SourceForge
MOC - Minimal Ogre Collision & Mousepicking
Simple TerrainMaterialGenerator for the use of standard Ogre material with Ogre::Terrain
New loader now with Ogre::Terrain support: Addons for Artifex on SourceForge
MOC - Minimal Ogre Collision & Mousepicking
Simple TerrainMaterialGenerator for the use of standard Ogre material with Ogre::Terrain
- xabila
- Goblin
- Posts: 225
- Joined: Mon Jun 05, 2006 9:40 am
- Location: rennes [FR]
Re: MOC - Minimal Ogre Collision - Demo1.0 Beta [Demo+Src+Video]
Hi,
Have you update the source since january or it's the same version on your site?
Thanks
Have you update the source since january or it's the same version on your site?
Thanks
- Nauk
- Gnoll
- Posts: 647
- Joined: Thu May 11, 2006 9:12 pm
- Location: Bavaria
- x 25
- Contact:
Re: MOC - Minimal Ogre Collision 1.0 - [Update 03.May.2009]
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
- 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
ARTIFEX TERRA 3D - Artist-friendly, free and easy WYSIWYG realtime outdoor scene Editor & Painter
New loader now with Ogre::Terrain support: Addons for Artifex on SourceForge
MOC - Minimal Ogre Collision & Mousepicking
Simple TerrainMaterialGenerator for the use of standard Ogre material with Ogre::Terrain
New loader now with Ogre::Terrain support: Addons for Artifex on SourceForge
MOC - Minimal Ogre Collision & Mousepicking
Simple TerrainMaterialGenerator for the use of standard Ogre material with Ogre::Terrain
- deadvirus
- Gnoblar
- Posts: 13
- Joined: Fri Mar 13, 2009 5:57 pm
Re: MOC - Minimal Ogre Collision 1.0 - [Update 03.May.2009]
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.
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.
DeadVirus.