LOD discussion

ttlanhil · July 16, 2006

should I forget about implementing a sky?

someone posted screenies of a sky a while back, though I don't recall much from more recently. probably worth checking if they were near finished

and if you're looking for more to do on LOD, there's Cal3D stuff in the library about that, though I don't know the details (the actors are where a large number of the polygons go, as FPS at storage shows )...

I've heard Cal3D also allows for multiple meshes to be linked to an entity and swapped, which may mean the ability to use high- , medium-, and low-polygon count and maybe texture sizes for the actors... if FPS is really low or the actor is really far away, switching to low res for a bunch of them will make a difference (heck, if roja got really excited, you could have a really high def one where facial hair and such uses enough polygons to look almost real... that sorta thing would only be when you're at max zoom in though, when you're not that far in it looks close enough)

Roja · July 16, 2006

I never remember ANY pictures of a sky in EL. The only person who started to look into it was Bahrain, who just posted that he can't work on it now.

Actually ttlanhil, the cal3d isn't where we'd need to have LOD.

When FPS is really low due to large amounts of players being in an area, there isn't much we can do about it because they are all close by-within view range- and need to be shown in full detail, this happens with the simply orthographic camera. Remember, the players will pop in/out of view range once they reach a distance-our problem is is that 3d objs are rendered PAST that view range(when using perspective or this new camera), and THAT's where the slow down is and LOD would benefit us greatly. It's not about what is in the current view range, but past it.

Only select 3d objects would need to have different LOD's. Mainly the trees and vegetation that have alpha blending calculations. I can easily make 1 or 2 extra models for each tree, with a lower poly count. Start with 1, then go to 2 if needed, perhaps even use the 2d plane that always faces the camera technique-more thought is needed to what we should do.

With the fog turned on, you probably wouldn't notice a difference at all.

An alternative is to somehow work a LOD option into the code and e3d format, such as cal3d uses. However, this will most likely take long to program, and also I don't know how selective it would be. Houses, which have few polygons and need thus show their "detail" are needed to stay as is, whereas trees & flowers can very much be reduced.

Then of course, it'd help to turn off objs. all together after a certain distance. But the fog would need to always be there in the very background, blended with the sky somehow. I could do some mock-ups if it'd be easier for you programmers to visualize.

Learner · July 16, 2006

Also, having a tunable LOD to just ignore small objects past a certain distance will help also. There is no reason you need to try to render the flower way in the back by the mountain. The best formula should look at both size & distance to use as a LOD object culling.

ttlanhil · July 16, 2006

I never remember ANY pictures of a sky in EL. The only person who started to look into it was Bahrain, who just posted that he can't work on it now.

ahh yes. there were a few screenies posted of it, I'm pretty sure. oh well, if the code is available it may save a fair bit of time

Actually ttlanhil, the cal3d isn't where we'd need to have LOD.
When FPS is really low due to large amounts of players being in an area, there isn't much we can do about it because they are all close by-within view range- and need to be shown in full detail, this happens with the simply orthographic camera. Remember, the players will pop in/out of view range once they reach a distance-our problem is is that 3d objs are rendered PAST that view range(when using perspective or this new camera), and THAT's where the slow down is and LOD would benefit us greatly. It's not about what is in the current view range, but past it.

I'm not too sure about this... I'm thinking with the normal overhead camera, rather than pseudo 1st person, but I think it would make a difference... if you're a full normal zoom out (ie no modded clients) near a storage you get a lot of slow down, but you don't see any details of the actors anyway. that's the sort of thing I'm looking at. it wouldn't necessarily be a large drop in polys (although the maps are getting better at high-zoom rendering, so if the FPS drop was lessened then a bit more zoom may be practicable), but even if you had half as many, I would imagine storages would be a lot nicer to the FPS. the level of detail in the actors looks to be designed for a zoomed-in looking, since there's enough detail to make it look good, but that's mostly wasted at a big zoom out

perhaps even use the 2d plane that always faces the camera technique-more thought is needed to what we should do.
With the fog turned on, you probably wouldn't notice a difference at all.

it doesn't work too well from an overhead, but yeah, if you're having close to 1st person view, billboarded trees and such could save a lot of work

Then of course, it'd help to turn off objs. all together after a certain distance. But the fog would need to always be there in the very background, blended with the sky somehow. I could do some mock-ups if it'd be easier for you programmers to visualize.

heh, that's something I suggested at the actor appear distance... a ring (or perhaps sphere) of fog at the distance where actors are added/removed by the server, so people seem to walk out of the fog.

it can be done with OpenGL fog pretty easily (and should be simple enough to blend with sky colour... at least the general one... stuff like buildings in the ring area will have some colour flow through, but not a lot... there's a problem here in having the colour right when you're looking below the horizon, from stuff like buildings and mountains. we can only have a single colour for the fog, so manually making patches different colours based on what we know is further that was isn't possible)

unfortunately, OpenGL only allows us to use one fog at a time, so to do this we'd have to give up weather-type fog (well, I think there was one (experimental?) new OpenGL thingy for multiple fogs, but that's probably even less likely to be usable on many computers)

emajekral · July 16, 2006

Also, having a tunable LOD to just ignore small objects past a certain distance will help also. There is no reason you need to try to render the flower way in the back by the mountain. The best formula should look at both size & distance to use as a LOD object culling.

That is precisely what I'm working on. I plan to separate small 2d and 3d objects when rendering lists are being made and using a special frustum to cull them early. There will be a float range spinbox in elconfig to allow it to be configured. If that's not enough I'll start looking at projecting trees into a texture and rendering them as billboards once a certain distance has passed.

Roja is right about where the problem lies. Morcraven Marsh and IP are the worst, the first because of all the grass, the second because of all the trees.

I'll let you all know how it works. (Or even better, someone who understands how the frusta are set up can add one and do the lists.)

I can already say that there will be a speedup... I get a 2-3x speedup by setting the back clipping plane to 20.0f on the worst parts of some maps and that already looks almost good enough. The speedup isn't enough for slower systems, but it is something.

Beware, map load times may go up. Maybe I'll prerender the billboards at some point.

Roja · July 16, 2006

Ok, just let me know if you need lower polygon objects or something taht you need me to do(art-wise), thanks for tackling this project, it'll be an awesome addition to the game!

Learner · July 16, 2006

Ok, just let me know if you need lower polygon objects or something taht you need me to do(art-wise), thanks for tackling this project, it'll be an awesome addition to the game!

'Low Poly' items should also avoid using transperancy as well.

Roja · July 16, 2006

yeah I figured that

Only problem is with the trees with leaves....suppose they could be just a solid shape, but then the 2d "billboards" would work just as good.

Learner · July 16, 2006

yeah I figured that

Only problem is with the trees with leaves....suppose they could be just a solid shape, but then the 2d "billboards" would work just as good.

At a distance the leaves being solid and less variaty in leafe coverage isn't a problem, which is also why a 2D object could possible replace it at extreme ranges if visibility is desired.

Entropy · July 16, 2006

What really slows down the game a lot is the vegetation, because of the alpha testing.

We really need to use impostors (2d biloards after a certain range). From what I've heard, Crytek and other similar engines make extensive use of impotors, and they switch to the 3d object once it's at a certian distance.

Emajekral, I want to talk with you in the game about it. What times are you usually on?

Roja · July 26, 2006

I think to make it easier for users concerning the LOD what we should do is make a few predefined LOD settings that they can choose from in the config panel(such as low, medium, high). We can also leave the cull distance option there as it is now so that more experienced users can fine tune it.

Learner · July 26, 2006

I put in a VERY SIMPLE LOD that just culls out objects based on distance squared and their size (-DSIMPLE_LOD). This is extremly simplistic but shows a good FPS increase even with a perspective of 0.80 and being in DP. The slower the video card, the more this will make a difference.

I'm going to add the same logic to reflections and shadows now, but the current windows client with it compiled in can be found at http://www.other-life.com/el/elc-130-LOD.zip

I know that something MUCH better then this is needed, but even a simple step like this can help in perspective and the other experimental camera views. It could also use a parameter for tuning it's culling.

emajekral · July 26, 2006

I found that the size didn't help things much and have just done a cull on distance squared in my version (with spin box to adjust it ingame). I'll have a look at yours and see how they play together.

Mine is automatic for reflections, cause the cull is done on 3d objects only. 90% of rendering effort is expended there. Roja can confirm this using my client: turn off reflections and shadows and you'll find that the boxes labelled tiles, 3d objects, 2d objects, etc will turn on and off those layers.

Using simplified models in a certain range may further improve performance. Billboards are my plan for now, but I'm not saying that using lower poly count 3d objects and no alpha testing in the mid-distance wouldn't help a lot too.

I'm looking at using the bbox code for distance sorting and occulsion testing. If I'm right the bbox hierarchy uses some kind of space partitioning that can be used to get near O(n + ln(n)) sorting time on distance for objects, similar to bsp trees. If objects are rendered front to back we get an automatic savings on texture lookups, alpha tests and other stuff. If the hierarchy can't do all this then it's time to look at bsp or k-d trees as a preprocess step.

Edited July 26, 2006 by emajekral

Learner · July 27, 2006

Yes, I've seen that I didn't have to worry about reflections, and mine could still use some tuning and something like a spinner or two as well. The reason I wanted to take size into a account is so that flowers, etc could wait longer, but large objects like houses could be rendered farther away and have less of a chance of popping into existance.

Yes, using billboards and some simplified models (specially if alpha can be removed) can help even more. Since we don't have billboards yet is why I'm biased to taking size into account. In DP and other maps you can get a horizon of boulders/mountains in the background very often which looks better until we do this better.

emajekral · August 3, 2006

My skybox work has brought up an issue that should probably go here, and should also be included in any discussion of improving the map editor.

Click here for previous discussion.

I propose a simple cell system that will section off obviously mutually occluded areas of maps. Each area can be tagged with a sky. I have three predefined sky types: Underworld, Weather-based Cloudy Skies, and Plain textured (a simple sky or rocky ceiling texture could be attached to it). I plan to make a generic skybox for playing around with that will expose several different types of layers. I plan to use a modified version of the sound area definitions. An extension to the editor that can draw rectangles or polygons around parts of the map and set information about them would be very nice.

If the work is to proceed we will need a sky and cell attribute specification, preferably one that leaves room for portals in the future.

If someone else wants to take on the work feel free to claim it.

The whole job involves:

Designing a cell and sky specification language (Sound is a good starting point).
- This may involve getting me to guarantee a c interface for setting up the generic skybox(will probably require a few texture arrays, animation variables, and a bitmask for turning layers on and off) and simple sky(one texture) . Neither is implemented yet.
- I expect cells to be 2D polygons that split up the map. Not 3D volumes.
[*]Writing/copying loaders for the language.

[*]Changing the map loader optionally to sort map objects into seperate rendering lists based on their cell.

[*]Adding a sky to each cell list when cell lists are created.

[*]Loading textures specified in for the generic skybox and simple sky into a format compatible with my interface.
- Textures for the other skies will be provided. Currently only one is used: cloud1.bmp
[*]Writing or adapting code to find what cell the player is in.
- I can provide a simple inside/outside test for convex polygons, and I'm pretty sure I've got one for convex/concave polygons too.
[*]Writing code to specify and set up the sky to render based on the cell the player is in.
- I'm switching the sky with a function pointer right now:
```
void (*render_sky)()
Available targets right now are:
//stubs
void generic_sky();
void simple_sky(); //<-- This will change tonight

//Overworld outdoor sky with moving clouds, 
//weather based cloud density, stars, day, night, 
//sunset and sunrise. Configures itself based on 
//what the client knows about weather and time.
void variable_cloudy_sky();

//Fiery horizon with swirling red, orange and black clouds.
void underworld_sky();
```
  Just so you know.
[*] Modifying the editor to provide a view for specifying cells and sound boxes and their attributes then saving them to disk.

The work would take me a long time alone. If I've missed something obvious or non-obvious please comment.

I don't know where to put this. It is not quite LOD, not all sky, and partially map editor. Should this go in a new thread?

emajekral · August 14, 2006

Working on LOD slowly along with sky.

On some maps, like White Stone, cells just won't provide a performance boost. On that map one can probably section off the magic school and a certain secret area, but those don't lie in the directions that exhibit the lowest framerates.

So I poked at the code again. I checked a few assumptions. I made some observations. I have drawn some conclusions. I have some questions.

Alpha testing is NOT a problem on high(er) end video cards in this engine.
Even if alpha testing is a problem on low(er) end video cards either there's an efficiency issue in the pipeline OR the polygon counts are too high. (We get over 6million polys per second on a 2.8Ghz Pentium 4. That's comparable to what Game Cube games get, iirc)
Textures slow things down a little, but not much (on my system. Other's mileage will vary)
Reducing polygon count is the surest way to improve performance without seriously overhauling code.
Lower polycount 3D models for LOD would be great.
Why do the ground tiles cause almost as much of a speed hit as 3d objects? I expected 2d objects to have more impact. (actual figures for 2d objects not recorded below)

Investigative stream of conciousness follows. It contains hard figures relating to one problematic camera angle in White Stone.

____

I've been wondering if part of the performance hit some maps take is due to texture misses. I looked in the bbox code and saw that new items are 'qsort'ed by render type (state batching, good plan) and then texture (textured batching, good, good).

The only problem is that the sort is done on the first texture id only resulting in render orderings like this(dumped from 3d_object.c just before drawing):