Level Of Detail

[cyberkilla]

I am VERY glad I did the skeletal animation. Ive tested it roughly, but I suggest you let me test it a little more with a better model, before you consider it, Raft;).

sure, it will take some time to use it in karga since it requires quite a modification on some parts

Yes, indeed:) If you need control over timeframes, or something of this nature, it should be minimal work for me to add for you.
I know you have some novel utilities to pair animation sequences:).

[EgonOlsen]

Egon, how effective is the clipping plane ? i mean, in a 50.000 polygon world, if clipping plane lets 5000 polygons to be rendered, will it perform as good as rendering a 5000 poly scene ? how much is the overhead ?

It depends: Culling on the clipping planes (not just the far one) happens per object (based on its bounding box), per octree-node and finally per polygon. The most efficient of these are the octree-nodes, because you can cull away very large parts at once. A 50.000 polys scene with 5000 visible polygons can't perform as good as a scene with only 5000, but the overhead (with octrees) should be neglectable. When splitting the scene into single objects, the overhead is larger because there is no hierarchy information like there is in the octree. Culling individual polygons is the killer(tm) or course.

[raft]

Yes, indeed:) If you need control over timeframes, or something of this nature, it should be minimal work for me to add for you.

i would certainly need that, as i switched to delta time approach in karga. it's like Egon's tick based approach but instead of ticks i use passed seconds

I know you have some novel utilities to pair animation sequences:).

that's another story i hope ogre's exporters wont make any trouble to me on those..

Code Select Expand

r a f t

[raft]

It depends: Culling on the clipping planes (not just the far one) happens per object (based on its bounding box), per octree-node and finally per polygon. The most efficient of these are the octree-nodes, because you can cull away very large parts at once. A 50.000 polys scene with 5000 visible polygons can't perform as good as a scene with only 5000, but the overhead (with octrees) should be neglectable. When splitting the scene into single objects, the overhead is larger because there is no hierarchy information like there is in the octree. Culling individual polygons is the killer(tm) or course.

so this may well worth a try merge the whole scene into a single object, use octrees on it, set clipping plane to a reasonable value, place LoD planes just at clipping plane's border.

the missing part is, i dont want to/cant merge the whole scene into a single object because of our infamous climbing problem. i do use collison meshes for buildings, trees etc. that's i need them as seperate objects. maybe implementing an inter-object octree system and setting far ones invisible may help, indeed setting them invisible depending on a simple distance check may also help..

[EgonOlsen]

so this may well worth a try merge the whole scene into a single object, use octrees on it, set clipping plane to a reasonable value, place LoD planes just at clipping plane's border.

the missing part is, i dont want to/cant merge the whole scene into a single object because of our infamous climbing problem. i do use collison meshes for buildings, trees etc. that's i need them as seperate objects. maybe implementing an inter-object octree system and setting far ones invisible may help, indeed setting them invisible depending on a simple distance check may also help..

Then just use the octree on the objects that can be merged. An octree implementation that covers multiple objects costs more than it gives IMHO. Culling away single objects isn't that expensive.