Raycasting to the polygon level -- questions

[Blasphemer]

Hmm I'm getting the same problem with your code as with the ConvertToMesh():

Code: Select all

    byte* pVertex = (byte*)vBuff.Lock(HardwareBuffer.LockOptions.HBL_READ_ONLY);

is throwing an AccessViolationException.

Any idea why that could be happening?

[Beauty]

My raycasting code is ready.

First I started to created a single function (as with the wiki code).
Later I decided to create a raycasting class instead of a single function, because it's better for the overview, allows better configuration and reduces redundancy.

Before release I wanted to perform some more tests. (e.g. animated models)
In my last test I recognized problems with the Sinbad model. For some areas of the model the ray query doesn't return hits. It's no problem of the polygon method. The problem is that the ray doesn't detect the bounding box. (I reported about this.)

Additionally I still don't know how to handle IndexData.IndexStart correctly. For this I created a seperate topic, but there was no reply.

I've been trying to get it to work with the ManualObject

In the wiki I published a demo code which shows how to query vertices and indices of a ManualObject. So you can see how to do.
http://www.ogre3d.org/tikiwiki/Read+raw ... ct+-+MOGRE

My polygon raycasting class I will publish soon.
Also I want to write some documentation.
If you are a C++ user, you can be the slave who creates the port from C#.

[Beauty]

I have been trying to do:

Code: Select all

        var manualObject = entry.movable as ManualObject;
        manualObject.ConvertToMesh("Poo", "General");

Conversion of ManualObjects to a Mesh is only possible when the ManOb has indices.
Maybe this is the problem.

[Beauty]

Hmm I'm getting the same problem with your code as with the ConvertToMesh():
[...]
is throwing an AccessViolationException.

Sorry, I have no idea.
Did you init the vertexBuffer variable/pointer?

Code: Select all

        VertexElement posEl = moData.vertexData.vertexDeclaration.FindElementBySemantic(VertexElementSemantic.VES_POSITION);
        HardwareVertexBufferSharedPtr vBuff = moData.vertexData.vertexBufferBinding.GetBuffer(posEl.Source);
 
        byte* pVertex = (byte*)vBuff.Lock(HardwareBuffer.LockOptions.HBL_READ_ONLY);

By the way:
AccessViolationException is a "common" and no specific error.
(I suppose mostly or always the reason is a pointer problem.)
So the reasons of your both crashes can be very different.

[Blasphemer]

The access violation only occurs with ManualObjects (not entities) and if I debug in DirectX. All is ok if I use OpenGL. I wonder how the ManualObject hardware buffers are defined in Ogre.

Id be happy to test your stuff but I'm using C# as well, sorry. Anyway thanks for the help; let us know once you are ready to release the code. I only have mine working with TriangleLists so far but it actually seems to do the job.

[Beauty]

I also use DirectX. For OpenGL I didn't test.
More details: Windows 7 (64bit), Mogre 1.6.5 (x86)

Id be happy to test your stuff but I'm using C# as well, sorry.

It's the most easy way to test my code.
On yesterday I decided to publish my code in a Mercurial repository (instead of SVN). I read some lines of the manual, but I need to understand it more deeply.

Also I recognized that I need some modifications, because there are a few application related depencies inside. Additionally I would like to embedd it to a tiny test application.

The current state of my code is attached to this post. (quick&dirty)

//--------------------------------------------------
// Preview code for raycasting on polygon level
// (c) 2011 by Beauty beautyod (at) gmx.de
//
// For usage it needs tiny modifications. There related code I added to file RaycastingToPolygonLevel_helper.cs (quick and dirty copy&paste)
// If you miss something or have questions, just ask.
// An improved version I will publish later.
// Look to this forum topic for news: http://www.ogre3d.org/forums/viewtopic.php?f=1&t=67355
//
// Please report your experience in the forum. (If it works well or causes problems.)
//--------------------------------------------------

Source code - download here

[saket]

Hi Beauty

Got your code snippet, and i don't think it's dirty but your "RaycastingToPolygonLevel_helper.cs" file seems like a quick one .

If you are a C++ user, you can be the slave who creates the port from C#.

As a C++ user, going throgh your code and i think this file must have some namespace declaration with it, as file "RaycastingToPolygonLevel_.cs".

It's a long time, I left C# ... whatever ... concepts are almost same, just need to refresh it.

As another side your article will help me a lot ... http://www.ogre3d.org/tikiwiki/Read+raw ... ct+-+MOGRE thanks.

[Beauty]

i don't think it's dirty

I uploaded it quick and dirty and it doesn't run out of the box.
Yes, the helper file is really dirry.

must have some namespace declaration

In most easy case just put the methods of xxx_helper.cs to the main class.
Then the most works should be done.

As another side your article will help me a lot ... http://www.ogre3d.org/tikiwiki/Read+raw ... ct+-+MOGRE thanks.

Nice to know that it's useful for somebody.
For what do you use it?
I think in common cases the programmer still knows the vertices/indices, because ManualObjects are created by the applications code.

It's a long time, I left C#

The Mogre API is mostly the same.
Some Mogre members are "class properties". For Ogre C++ you need to replace them by getXxx() / ()setXxx() calls. (As far as I know, C++ doesn't know properties. At least the Ogre API doesn't have such properties.)

[saket]

Although I hadn't gone through your code properly, till now.

Nice to know that it's useful for somebody.
For what do you use it?
I think in common cases the programmer still knows the vertices/indices, because ManualObjects are created by the applications code.

I had seen some comment entitled "Data Grabbing", Indeed that's all i wanted to see again. Since the article is removed, i am unable to say anything but most of the time, code-snippet articles has always something to notice (*completely my prospective view).

(As far as I know, C++ doesn't know properties. At least the Ogre API doesn't have such properties.)

I think you are talking about Accessors and Mutators (get/set in C#). As per i know, Accessors are just the method/member function that are used to access the values within object but doesn't modify it, whereas Mutators are just used to modify these instances/objects . These are not bonded with the prefix-string as get/set in C++.

Please follow the link (and enjoy some articles...)
Accessor: http://www.brpreiss.com/books/opus4/html/page603.html
Mutators: http://www.brpreiss.com/books/opus4/htm ... 0000000000

In C++, whenever we talk in concern of Design pattern these are quite fundamental things within a class. In ogre, yes we use Accessors and Mutators and your getXxx() / ()setXxx() can be said as the same.

[saket]

Yes, definitely Class Property has some difference in syntactically basis.

I was going through your code concern to RaycastingToPolygonLevel_.cs, and you had done it really well. I would really appreciate the beauty of your overloaded function FindClosestPolygon(,,,), both for Manual object and Entity. There switch cases for Render operations are really smart. Your loop with if-else ladder had distinguished the architectural rendering phenomenon of all triangle operations (as OT_TRIANGLE_LIST/OT_TRIANGLE_STRIP/OT_TRIANGLE_FAN) and there co-ordinate indexes for the next triangle respective as 3/2/1 (after 1st triangle) is interesting.

RayToTriangleCheck(,,,,) to identify the intersected polygon/triangle with the distance from ray-origin is really superb. Your structure TriangleCheckResult, with the overload constructor is really giving a bit view about expected result.

I had also gone through AddDebugPoint3D(,), AddDebugLine3D(,) and TerrainRayCorrection(,) methods. Among all, I really have some problem to understand TerrainRayCorrection(,) and i think i need some guidance.

[Beauty]

Thanks for analyzing my code and all your compliments.
It's a motivation to continue my community work.

The needed low level basics I learned from code snippets, Ogre documentation and by useful answers of friendly forum members. Without the groundwork of other people I would had no chance to write my raycasting class.

Currently the (seldom) used Ogre feature related IndexData.IndexStart is not regarded.
Now I know the background by the explanation of Ogre founder Sinbad. (Details you can read here)
In the next weeks I want to extend my code to manage this feature, too.
Also I think it's useful to add an option to enable/disable the processing of this feature. (Because it's for rendering purposes and possibly a user wants to regard all vertices, independent of rendering optimizations.)

I really have some problem to understand TerrainRayCorrection(,) and i think i need some guidance.

A description I published in an other topic, including pictures.
Unfortunately nobody cares. (At least there was not one single comment. Later I though it was waste of time to create the pictures and to write the description.)
Well, this correction is only needed for usage with the TerrainSceneManager (or others, which are based on this).
For the new Ogre terrain component this correction is not needed. (Just comment it out.)

Details about TerrainRayCorrection(,):
http://www.ogre3d.org/forums/viewtopic. ... 00#p444900
Details about the background/impreciseness are in the discussion above.

The access violation only occurs with ManualObjects (not entities) and if I debug in DirectX. All is ok if I use OpenGL. I wonder how the ManualObject hardware buffers are defined in Ogre.

I'm sorry for your problems.
Perhaps I will create a tiny test application, which just needs to be compiled/started. Then it's more easy to find the problems.
Is it possible to extract the code which generates your ManualObjects (including all specific vertex values)?
Then I could create the same object in my application to perform tests.
Did you try it on an other computer? Then we could be shure, that it's not related to your hardware/driver/software settings.



Sorry for my late answer.
I was working for my diploma thesis and now I spend time with my girlfriend.
But I will continue/publish my work.
Thanks for your interest in following this topic.

[saket]

Thanks for analyzing my code and all your compliments.

Always welcome . Sometimes it's not possible to implement what exactly you think, yes only because of time and I really dn't know when I will lead it ... , so till then I think it's always nice to appreciate good view and work.

the explanation of Ogre founder Sinbad.

Yes, I read it. You had also referenced it in your previous comments.

Details about TerrainRayCorrection(,):
viewtopic.php?p=444900#p444900

It really looks sweet with images, you had worked a lot for this. A tutorial with visual guidelines will always quite easy to understand concepts for beginner as me. I need one more week-end (comming) to go through it.

I was working for my diploma thesis and now I spend time with my girlfriend.

All the best for your thesis.
Belated Merry Christmas. Enjoy your holiday week, till then I need to work on MRT hopefully will complete it within this week, then i will come back to your posts again.

[Beauty]

In an other topic somebody asked for the differences of my code.
The answer I publish here, because it's a more common place to that topic.

[...] is the only difference that it's written in c#, or are there other differences?
[...] is the plan to rewrite the c++ code for raycasting?

The code is completely re-written and very different on many places.

First I just wanted to get it work with ManualObjects.
When I analyzed the existing code in the wiki I recognized problems.
So I decided to re-write it from the scratch.

Here are the main problems of the original code and the differences of my code.

1)
There is no differentiation for rendering types. The code just expect, that the meshes only contains triangle lists. Other triangle types or lines or points would cause wrong results or even crashes (out of range exception at access to an array when the amount of indices is not dividable by 3).
This doesn't happen with my code. It processes all rendering type as it should be.

2)
The code needs more CPU load than needed.
Reason: The "ray to polygon checker" uses the help of function GetMeshInformation(). This "helper function" was created for wrappers for physics and collision detection libraries. (at least it was used for OPCODE). It creates a full copy of all vertex positions and indices at each query. But there is no need to create a full copy. In my code the "ray to polygon check" is done while reading out the vertex/index data.

3)
The ray detection has an abort condition based on the "common" ray query distance. This is bad in some cases, because the "common" ray distance returns the distance to the bounding box (AABB). If the ray source is inside of the bounding box, it can happen that a mesh will not be checked, although it's polygones are closer than others.
If you don't understand what I mean I can search for a picture on my computer, which I created for a presentation about 2 years ago. It explains the problem as picture.
My code has an improved checker to decide if the polygons of an mesh/manualObject will be analyzed. If it's far enough for shure there is no need to check all of it's triangles.

4)
The original code only detects rays, which intersects to a polygon from the "positive side" (outer side). This could save a little bit of CPU load (maybe very very little??), but sometimes it's useful to detect triangles from both sides. Now ther is an option and the user can decide what he prefere.

5)
The original code could return the the normal of the detected triangle. If the user doesn't need it, he could comment out some lines of code and GetMeshInformation() returned null values for it.
Now there is a more clear way to enable/disable this functionality.

6)
My code detects for Meshes/Entities, ManualObjects and Terrain. The closest distance will be returned.
Also for terrain I wrote a code to calculate the normal of the terrain hit. (by use of additional helper rays)
The ray query for the old Terrain Scene Manager returned a very imprecise distance value (up to 1 Ogre unit too much). For this issue I created a method, which queries a much more precise distance value. Details for the terrain distance correction I published here. (including images)
Note: For the new terrain component the correction function is not needed. The new terrain component returns precise distance values.

7)
If needed, the user can define a maximum distance. 3D objects which are more far away will not be checked on polygon level. (Saves CPU load)

8)
Support of mesh animations is included.
For software based and for hardware based animations.
Thanks to the helping words of jacmoe

9)
The wiki code was just a function and a helper function.
My code is a class, which offers more flexibility for options and should be more clear.

10)
The original code was with very less documentation.
In my code I tried to added many comments. So I hope it's a help for people who want to understand or modify it.



More I don't remember right now. If I do so, I will update the list.

updates
... notices for an increased list will be added here ...

[JDX_John]

Sounds very cool. I'll make a note to update my code using your version next time I touch that area of functionality.

Thanks!

[Mawen]

Wow looks like you did a lot of work on this! I'll definitely upgrade my raycasting code.

[Beauty]

Don't forget to give feedback

[Beauty]

Today there was a talk about my polygon rayquery code in the Ogre chat.
Here I publish some suggestions. So that they don't get lost.

Bugfix for a special animation type:

Beauty, you have a buggy in your raycast to polygon level code
lets say you have a pose or a morph animation with no skeleton, it doesn't work
i just replaced all the getskeletonverts to getsoftwareverts blah blah, but what you could do is put in a || statement when you check to see if it has any animation

it's not that big of a deal, very few people probably have pose animations without bones that need to raycast to polygon level
well it's just another bool and two conditionals
hold on i'll write it real quick and pastebin it

Beauty, and yes, in your code it seems it wouldn't work on a pose animation without a skeleton as well

Here his animation bugfix code:

Code: Select all

// orginal:
bool useSoftwareBlendingVertices = entity->hasSkeleton();

if (useSoftwareBlendingVertices)
{
   entity->_updateAnimation();
}


// Modified:
bool useSoftwareBlendingVerticesSkeletons = entity->hasSkeleton();
bool useSoftwareBlendingVerticesMorph = entity->hasVertexAnimation()

if (useSoftwareBlendingVertices || useSoftwareBlendingVerticesMorph)
{
   entity->_updateAnimation();
}

Code: Select all

// orginal:

//When there is animation:

if(useSoftwareBlendingVertices)
   vertex_data = submesh->useSharedVertices ? entity->_getSkelAnimVertexData() : entity->getSubEntity(i)->_getSkelAnimVertexData();
else
   vertex_data = submesh->useSharedVertices ? mesh->sharedVertexData : submesh->vertexData;


// Modified:

if(useSoftwareBlendingVerticesSkeletons)
{
    vertex_data = submesh->useSharedVertices ? entity->_getSkelAnimVertexData() : entity->getSubEntity(i)->_getSkelAnimVertexData();
}

else if(useSoftwareBlendingVerticesMorph)
{
    vertex_data = submesh->useSharedVertices ? entity->_getSoftwareVertexAnimVertexData() : entity->getSubEntity(i)->_getSoftwareVertexAnimVertexData();
}
else
{
    vertex_data = submesh->useSharedVertices ? mesh->sharedVertexData : submesh->vertexData;
}

A great offer:

Beauty, when you finish your raycaster let me know, i'll port it to cpp

Here are speed-up suggestions for the case that rays are queried with high frequency.
(For general use my code should be still fine.)

raycasting via gpu buffers on CPU seems a bit hackery to me
and, it scales very bad too; what happens with static geometry?
each ray must go through all tris?

What would be an alternative to cycling though all polygons for each ray? How to you want to check for intersection when ray origin/direction or scene objects are moving?

sorting the tris
(this is for multiple rays only)
and if they are moving, then you need to reindex each frame-queries

A further suggestion:

Use SelectionBuffer, Beauty. Also in the WIki.
SelectionBuffer works as part of your application sources.
It works just fine with the SDK release.
It has an interceptor that's inserted into Ogre's rendering pipeline at the appropriate place. Ogre is designed to accomodate such interceptors without recompiling.

The SelectionBuffer wiki page is here:
http://www.ogre3d.org/tikiwiki/Selection+Buffer

[Beauty]

Hmm I'm getting the same problem with your code as with the ConvertToMesh():

Code: Select all

    byte* pVertex = (byte*)vBuff.Lock(HardwareBuffer.LockOptions.HBL_READ_ONLY);

is throwing an AccessViolationException.

Any idea why that could be happening?

A half year after development of my code I started to use it in my Mogre application. In general it works fine.
Unfortunately sometimes I also get a crash at this position. It's very strange.

After some debugging it seems so that the crash happens, because a single section of the ManualObject get somehow "invalide".
In my application I catched the Exception and stopped polygon raycasting. Then my application is still running (instead of full crash). But one of my ManualObject sections isn't visible anymore in the Ogre render window.

My suggestion:
Sometimes somehow (by usage of my raycasting code) a single ManualObject section gets invalide.
So Ogre doesn't render it anymore.
And when my raycasting code tries to read the section content, there is a crash, because the memory (RAM on GPU) of the section seems to be disposed.
So the pointer (of the ManualObject section) points to a memory address, which doesn't exists anymore.

It's very strange, because the query works hundrets and thousands of times. And somewhen later there is a crash.
Even when nothing in the scene or ray properties are changed. All object positions/orientations are equal. Also the ray origin/direction is equal.
It works and works and works. Always the same situation. But somewhen there is a BAM.
I never had problems with "loosing ManualObject sections", It only happens while using my ray query code.
My ray query code is read-only (related to the GPU RAM). So why it should make invalide the allocated memory of a ManOb section?
I don't understand this.

Perhaps the same problem happens with Entity sections?
I didn't try it yet, but it could be possible.

Related to this problem I already created the forum topic Crash at HardwareBuffer Lock ...killed ManualObject section?.
If somebody has an idea, it would be nice if he tell it (in the referenced topic).

P.S.
I still use Ogre 1.6.
If this issue is based on an already fixed Ogre bug, please let me know.

ConvertToMesh()

If you want to create an entity from a ManualObject, you have to use indices for your ManualObject.
Without indices you can't use ConvertToMesh().
Just for the case that you need this note.

[duststorm]

This is kind of a hacky solution, but since you're saying it doesn't occur often at all, maybe you can work around your problem like this:
When you catch the exception, unload/destroy the manualObject for the failing pipe segment, then recreate a new one and restart ray casting.

[Beauty]

I thought of something similar:
Each of my pipe consists of only one ManualObject.
If an exception happens I could return the related section number. Based on this knowledge I could set an "ignore flag" to my ray query class to prevent further sucesses to the corrupted section. Additionally I could add a new section to the same ManualObject, which becomes the same content as the corrupted section. (All vertex data is stored in my pipeline class. So I know how to rebuild the section.)
This could work fine and quickly ... but only with my pipes.

My class should be usable for everybody. If somebody else has crashes (e.g. with a loaded mesh), he can't just recover the section, because it's difficult to find out the vertex data, which was stored in the corrupted section. Using meshes, the problem additionally could happen with the memory of the "shared vertex section".

So it would be better to find and fix the real problems source.

In the remaining time for my diploma thesis I don't have much time for coding. (Additionaly I don't have any idea where/how to search for the problems source.)
Currently I just restart my application and hope that the next run of my simulation isn't interupted by the problem.

[Klaim]

Some comments looking at the code of OgreRay at the end of this page http://www.ogre3d.org/tikiwiki/Raycasti ... ygon+level

1. It looks like there is a missing destruction call of the RaySceneQuery (using SceneManager::destroyQuery()) , that should happen in the destructor. Am I right?
2. There is a 3rd "GetMeshInformation( const Ogre::MeshPtr mesh ..." that is never used. Should have it been used inside other functions?
3. I see some scary new and delete. Can't this be done without allocating on the fly?

[Klaim]

The code doesn't compile with VC11 because of this line:

unsigned int* pLong = static_cast<unsigned int*>(indexBuffer->lock(Ogre::HardwareBuffer::HBL_READ_ONLY));
unsigned short* pShort = static_cast<unsigned short*>(pLong); // ERROR

This is not allowed, it should be a reinterpret_cast.

Do you recomand I to use MOC instead of these snippets? It looks like MOC uses the same code inside.

[Beauty]

Thanks for your feedback.
I don't remember so much details at the moment, because it's about 1 year ago.
Aside the very strange type of crashes my code worked fine.
I compiled it with VS 2010.
Visual Studio 2013 I never used. Currently I program for microcontrollers with an other IDE.
Just try my code and perform some tests. The usage should be easy.
Be shure that you use MY code and not the very old code of the wiki.
I hope I can look to your notes in an other week.

[Beauty]

An addition:
My code is completely re-written and not C++.
I's C#. The old C++ code of the wiki has bad performance and bugs.
So you should consider to port my improved code to C++.

Or just try MOC.
I couldn't use it, because it's not available for C#. (I used Mogre.)

[Klaim]

VC11 is VS2012 not 2013.

So I managed to make it work, with some modifications specific to my use case.
Now, you say that the wiki have old code, so I'll take a look at the C# version but I think I might also just refactor agressively the wiki/MOC version?
The main thing would be to keep a indice and vertice buffer (vector) associated with the RaySceneQuery so that there is no new/delete happening each frame (if I want to know each frame what's under the mouse for example). Basically the code does too much lowlevel manipulations to my taste but I guess it was "just working" at the time.

As MOC does use the same code but rely on the mesh overload only of the GetGeometry functions, I'll try to change the code to just that.

If I rewrite a c++ version fromt he C# version, or not, I think I'd better put my own version in another wiki page linked to this one.