Geometry Problem when importing scene with DotSceneOctree

[ncazanav]

I'm trying hard to import a scene file to ogre following the (very useful) tutorial found in the ogreaddons\dotsceneoctree, readable at this adress

http://www.icetecstudios.com/public/OgreTest/Tutorial/

I run into a very strange problem (at least for me, i m quite newbie in Ogre) : when i am trying to import my scene (a building) the geometry of some parts of the building is completly messed up. When I import only partially my building every thing is fine.

It seems to me that there is a threshold not to overstep in the number of faces in the scene. under 70000 faces (approx.), everything is ok, but more renders a completly wrong geometry.

Please HELP, what am i doing wrong?

I tried changing the parameters of the sceneconverter when compiling the octree but it doesn't help (but in fact I'm not sure to understand the meaning of each parameters since i don't know precisely what is an octree in 3D rendering)

[tuan kuranes]

dotscene index buffers seems 16 bits (65535.)
You'll have to split object in smaller buffer, or patch dotscene exporter either to break its buffer in several ones, or use 32 bits indes (which is less Hardware compatible)

[ncazanav]

Not sure to understand exactly: in my scene every objects have less than 65535 faces, but the whole scene is about 90000.

So what do I have to split ? Is it preferable too have many objects small objets (i.e 1000 faces max per object) than to have a big one?

[tuan kuranes]

I'm no expert of dotscene exporter.
Sorry, wasn't very clear. Second try :

Problem is :

Dotscene seems export everything into a Single Buffer, or into Several Buffer but partitionned only by space partionning algoritms (octree). Problem arise when a single buffer needs more than 65535 indexes.

Three solution there :

If you reduce whole scene tris counts so that it need smaller index buffer, it would work. But you loose details.

If you patch dotscene loaded so that it loads index into 32Bits indexbuffer. But it will need recent (<2yrs) hardware, will impact performance and will not loose details.

If you patch dotscene exporter so that it handles that particular case and spit buffer > 65535 into several ones. It will work on all hardware and will not loose details. (That's the best solution.)

[ncazanav]

I am surprised that there is no loader for scene with more than 65535 tris. Is there another way to load such scenes?

If you patch dotscene exporter so that it handles that particular case and spit buffer > 65535 into several ones. It will work on all hardware and will not loose details. (That's the best solution.)

I'll have a look at the code of the dotscene exporter, but i am not sure to be able to patch it as you suggest...Do you know where can I find docs about octree, buffers, i dont know much about 3d programming...

P.S : il fait beau a Grenoble, de la neige?

[tuan kuranes]

perhaps the problem is that the 100.000 tris is not taking advantage of space partition, therefore resulting in a single big buffer in a single leaf of the Octree.

Isn't there any option to the exporter/loader, nor the loader to change Octree Depth, or the root Octree Size ?


There's lot of litterature on the web on spatial partionning, octree, quadtree, kd-tree, bsp.
Here's some
basic : http://www.gamasutra.com/features/19970801/octree.htm
more advanced : http://www.flipcode.com/articles/articl ... rees.shtml


But above proposed solution is more Ogre Mesh handling oriented, as patch will results in code that take a big Mesh Buffer (> 65535) and splits it in several ones (< 65535).
Just have to find where to do that.

Anyway Octree read is a must read to know how everything is handled there and optimize scene organization.

ps: pas de neige en bas, ni de soleil, à Grenoble, obligé de gravir les sommets pour percer la couche de nuages et tater la neige

[jacmoe]

That is a limitation of the dotsceneoctree, not Ogre.