next »

[Mikademus]

So I have some issues with OGRE 3D. I need to obtain the intersect position of a ray and some given geometry. OGRE only supports ray-to-aabb and ray-to-bsphere intersection on meshes, and ray-to-polygon intersection on "static geometry", i.e. there is no ray-to-polygon command on normal meshed build into it. Apparently that particular routine has been stopped at the gate by some forum moderators that exercise Politics to oppose it, no one knows why... Luckily, there is some code on the wiki that does what is needed, and everyone uses that instead. Static Geometry is a special kind of pre-analysed and non-changing geometry created by feeding meshed to a static geometry cooker facility in OGRE.

So, my problems are (1) that I can't create static geometry since the geometry data I create crashes the cooker. Nobody has any clue why, and all graphics displays nicely. And (2), the ray-to-polygon checker only hits some of the polygons (see attached images). I can't see any pattern to this.

Does anyone here have any experience with OGRE or related issues and have any advice what it could be or what I can test? I am a bit stumped here, and am running out of ideas.  


Full render:


Wireframe:

[Zaphos]

Well, if the ray-to-polygon code is just something you got off a wiki, can you just debug that?  Break it down to the simplest thing -- like, if there are any acceleration structures, disable them, and just loop over triangles and do ray-triangle intersection for each tri -- and make sure you can get the simple thing working, then build back the complexity until you figure out what's broken / how to fix it.

[David Pittman]

If I'm looking at the same code you are, it looks like the ray/triangle intersection test is dependent on the direction of the ray and winding order of the triangles. Make the last parameter of Ogre::Math::intersects(...) true instead of false and see if it magically works?

[Mikademus]

Zaphos, I am very much trying to avoid just that Seriously speaking though, the wiki source in question (link below) is used in most OGRE projects and is commonly pointed to by the OGRE graybeards, so it should be ok, but with my luck... What I have done in the pictures is basically what you suggest: remove all complexity and just automatically shoot rays. But I fear I might have to go low-level searching for NaN's and other funky things.

If I'm looking at the same code you are, it looks like the ray/triangle intersection test is dependent on the direction of the ray and winding order of the triangles. Make the last parameter of Ogre::Math::intersects(...) true instead of false and see if it magically works?

Hi David! Yeah, I think we're looking at the same code. Thanks for the suggestion about parameter for checking away-facing polygons. Sorry to report that it made no difference

[muku]

I found the thread where that code was originally proposed, and interestingly it's different (specifically, the GetMeshInformation function). Give that a try maybe. Incidentally, there are already two different versions of that function on the Wiki, have you played with both of them?

EDIT: There's also this, perhaps better tested.

[Mikademus]

Hi Muku!

Yeah, that's the first thread for the wiki code, and a relatively gentle introduction to Xavier, an OGRE moderator that is generally hostile and agressive, and one of the two that has kept any check of this kind to go into OGRE. His solution to anytime a newb asks "I am building my first OGRE Hello, World!, and I need to check for intersections against the mesh" (which is a common question) is "include a physics engine".

The two versions on the wiki are essentially the same, except for that the second one also updates the extracted mesh information with animation data, which is needed if testing against... well... animated meshes. And your last link is MOC (Minimal Ogre Collision, a header with some OGRE utils) uses the wiki code. Thank you for going to the trouble of looking for those resources for me!

I'm suspecting this may be a material-related issue, but how in any way this could be I haven't the foggiest...  

[muku]

The two versions on the wiki are essentially the same, except for that the second one also updates the extracted mesh information with animation data, which is needed if testing against... well... animated meshes. And your last link is MOC (Minimal Ogre Collision, a header with some OGRE utils) uses the wiki code. Thank you for going to the trouble of looking for those resources for me!

Ok, I could have guessed that you already looked into these things

I just thought that MOC, having been extracted into a sort of semi-official library kind of thing, would have had more testing than the volatile wiki code (there's a comment on the discussion page that a recent edit may have introduced a bug into it). But maybe not. Are they completely identical? It's only a source and a header file, so should be easy enough to try out.

[Mikademus]

Basically, the intersection test against polygons are done by two functions: a polygon iterator and intersect tester, and a mesh information extractor. I've gone over the MOC source line by line. What they did was abstract the interface into some helper methods, but the underlying work horses are the same. They also added the ability to mask away entities by name and group.

So this is looking like either a material or geometry issue, because looking at some other maps, it is obvious that there are areas on which intersections fail, areas seemingly defined by textures. And the map geometry I use chunk indices by texture, so there is some kind of correspondence here...

Another map:

[muku]

Ok, I'm not much help here. Just one last idea: is it possible that your issues (1) and (2) are related? That the geometry you produce has some anomaly which crashes the static geometry cooker and which also leads to the problems you're seeing with raycasting? Maybe just use a debug build of Ogre, point your debugger at it and see where it crashes. Might give you some hints what's wrong.

[Mikademus]

It is really good to hear that you think exactly the way I do: it makes me feel I'm at least doing something right! So I have already done just that, and I know exactly where the cooker crashes, and yes, I do too think that these issues might be related. I have posted about it in the OGRE forum--quite a while ago in fact--and as usual when it comes to non-trivial issues I have received no help. This is in fact why I am posting here rather than at the specialised fora: people here are more open, genuinely helpful and interested, and simply put pleasant and rewarding.

So by showing me that I am sane and taking the right steps you have certainly been of great help!

[muku]

Haha Like minds and all that. I give up then. Unless someone else steps up, I guess you'll really have to buckle down and get into heavy-duty debugging mode. Good luck!

[Alex May]

I can't really help beyond saying your environments look sweet!

[Mikademus]

Thanks Alex! The geometry was made in 1998 and still looks good! Adding some anisotrophy, shadows and dynamic lighting lifts it to a graphical pleasure with a distinct retro feel!

On topic: I have notices that ray queries on the blank areas actually do detect a hit, but always at a deviant position [-1.07374e+008, -1.07374e+008, -1.07374e+008]. I do not know whether this number signifies a special value like infinity or NaN, if it is a VStudio debug initialisation value, or an OGRE value. Might this be significant?

[Zaphos]

It kind of sounds like your data structures are getting clobbered sometime between being initially uploaded and being downloaded back for the ray tests ... have you tried printing out the positions of the vertices for the geometry you read back with getMeshInformation() (especially whatever geometry is generating those deviant positions)?  Wouldn't be too surprised if the positions are messed up ...

[Mikademus]

Oh chucks, ignore that part about deviant coordinates, that was just junk I hadn't cleaned out. When it fails it simply fails as it should and hits nothing.

Anyway, I've gone over my data on the polygon level and compared data before loading, while loading, after loading and while raycasting, and as far as I can see the geometry is correct. I have even refactored the hell out of my geometry loaders to no difference.

*jumps, shouts, tears hair, has tea and cookies*

I'm fresh out of ideas. Hugs would be appreciated now.

[BorisTheBrave]

You say it's a material problem? How does that affect the geometry of the world? By chunking, you mean you have split the geometry into several static models? Perhaps some brainstorming in this area would reveal something relevant. I only focus on it as it seems the most unusual aspect vs the others who have successfully used the wiki code.

[Mikademus]

By chunking, you mean you have split the geometry into several static models? Perhaps some brainstorming in this area would reveal something relevant. I only focus on it as it seems the most unusual aspect vs the others who have successfully used the wiki code.

Actually, I've integrated the geometry. The original data was chunked and divided models into a vertex list, and sets of faces sorted by materials indexing the vertices. When I load the graphics I bake it into using only shared vertex and index buffers. However, since OGRE allows only one material for any one Mesh they are divided into SubMesh:es if using multiple materials. Hmm, wonder if it may be the case that the intersection algo can only handle geometry in Entity and Mesh classes, and will ignore any SubEntity and SubMesh data? Good call, sir, well worth checking out!

[Mikademus]

Boris, thanks! That was indeed the reason! OGRE internally divides up the Entity and Mesh into SubEntity and SubMesh objects. The source code only checks against the first of these. Apparently when you call on the main Entity object is silently forwards to the first SubEntity. So your notion really guided me toward the source of the problem (if not the solution)! I now owe you an ice cream!

I have asked on the OGRE forum for help with correcting the wiki source to also include subentities, but I have little hope of receiving any assistance from there

[BorisTheBrave]

Ah, I'm glad it is solved, but it sounds more like you did the work yourself. Seems pretty poor of the OGRE forums not to have picked you up on that quicker.

[Mikademus]

Indeed, that is why I am so split about it. On the one hand it is the most powerful FOSS renderer out there; on the other hand what worth is that if you will only be listened to when you're already an expert? I'd like to be able to recommend it, but this is a really severe problem they have.