Level Of Detail

[cyberkilla]

Sorry, another question;).

Has anyone managed to implement LOD in jPCT?
I heard something about Raft achieving this.

Does anyone have any information you can volunteer to me?

[eye1]

What is LOD? Raft has send me sample of combining fenggui with jpct. Looks very interesting

[cyberkilla]

LOD stands for Level Of Detail, apparently.

It would appear to remove, or, at least ignore some of the vertices in a mesh,
as they move away from the camera.

The idea is that it is foolish to render a 15,000 polygon model, when it is so far away from the camera it is only a few pixels high on the screen.

Im sure there are other methods that compensate enough to remove the need for LOD.

Thoughts and opinions are very welcome:)

[EgonOlsen]

I wouldn't bother with it until it becomes a problem. Objects and octree cells behind the far clipping plane or out of the screen won't be processed anyway.

[cyberkilla]

Fair enough:)
Premature optimization is, as they say, the root of evil:)

[raft]

yes, karga has a simple LoD system. it doesnt reduces polygons on the fly bot uses prebuilt low poly versions of some objects. you can find some more info on karga thread

i did that hoping it would help to manage large scenes. well, in theory and on experimental scenes (like this) it does, but practically it doesnt help much. it also has some minor overhead as i do set visible/unvisible on different LoD levels instead of adding/removing to/from world.

i also use them for avatars without animating low poly versions. this sometimes seems unpleasing

so, i agree with egon, i should most possibly save my efforts for something else

Code Select Expand

r a f t

[cyberkilla]

Thanks Raft;).

The only way it would be truely useful, is if we had some sort of edge folding algorithm. Something like that might  be advantageous - provided the algorithm was actually faster than just rendering the handful of redundant vertices:)

[raft]

yes, and of course provided with jCPT allows removing some vertices/triangles

this is an interesting topic indeed. i very very wish to manage large scenes in karga (without fog and clipping plane) but still have no idea how to do this. gl renderer can render larger scenes but the performance difference between it and the software renderer gets smaller as the scene gets larger. i guess because of the overhead

maybe a progressive LoD system as you described is the only way

Code Select Expand

r a f t

[cyberkilla]

I have an idea!;)

Perhaps you could use a vertex controller to:

- Fold vertices onto eachother.
- Reverse the normals so they are backfacing, and therefore, not drawn?

The folding might not be as hard as is sounds.

Every nth vertex could be affected. This might give the rough effect.
It sounds very bad, but there was a C++ GL example  that did this,
and it does look good!

What do you think?
It is, at the very least, an avenue worth exploring.

Just to clarify, I mean, moving some vertices so that they occupy the same space as other vertices of another face, then setting the affected face normal to be culled.

[EgonOlsen]

This will still push the polygons half the way down the pipeline before they are getting discarded. I don't think that it'll help much...maybe a bit, but not that much. The need for adding and removing polygons on the fly is exactly the reason why such CLOD-approaches aren't used anymore by today's games. Hardware just doesn't like it that way. jPCT is somewhere in between, so it may benefit from it to a degree, but: Do you really have the need to do this ATM?

[cyberkilla]

No, of definitely not;)

I was merely intrigued, because an artist from ID Software spoke about their implementation in Quake III. However, the website is from 1998, and I do not know about the Quake versions, so perhaps it is outdated.

[raft]

interesting idea cyber
egon, brainstorming doesnt hurt, does it

then how do current games handle so big scenes ?

one idea i once thought was, rendering some far part of the scene to a texture then simply replacing that far part with a single plane which has that texture assigned. this still needs the nearest part of that far part to be significantly far away from camera to be realistic which in turn means we still have to manage some large scene, kind of egg-chicken dilemma

[cyberkilla]

Hmm, interesting idea Raft:).

I agree with you.

If you have an FPS, or an RPG(and others, naturally), where there are a lot of players on the screen, ~5,000 polygons each is a little harsh.
Not that I would use that many - but Unreal Tournament, and Warcraft use this as the upper limit.

In these games, players are very rarely close to the camera, but it does happen often enough to nessesitate the need for some reasonable detail.

I am sure there are other options though, and, you're correct, I don't need to look into this now - I just have some free time, and a bit of curiosity:).

Oh! This is the wrong place to put this, but: I will have some screenshots soon Egon:). I am working on a female model for my test map(volcano pit).
Many apologies for the delay. I have been working non-stop on this project. Things just take a little longer than I anticipated.

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;).

[raft]

indeed this begun to seem more reasonable to me

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 ?

[raft]

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