Show/Hide heavy trees

[Rick]

I have a top down view with a lot of trees, bushes, and grass models on a 128x128 terrain. If I just show them all I get like 24 fps. With them all hidden I get like 180 fps. I have also made a logic grid 1x1 and all trees, bushes, and grass models are tied to the center location of each tile in the grid. Because of this I'm able to find a 20x20 grid around the player and show the models in those tiles if there are any. This gives me about 60 fps. The problem with that is as I move it keeps showing more models but not hiding the ones out of camera view so the fps starts dropping.

 

Wondering what kind of options there are for me to keep this area around the player to show these models and hiding all others outside of this range. Any tricks that might make this faster because even the looping over tiles around the player drops fps a decent amount.

[Scott Richmond]

Hey Rick. I recently went through the exact same situation. Your FPS is being eaten up by Occlusion Culling and there are two ways to fix it:

1. Know when tiles are entering and leaving your field of view and hide/unhide all models on those tiles.

2. You can effectively disable OC by putting ALL your models into 1 OC group.

[Rick]

What would be the best way to do number 1 without looping through the entire grid?

 

Also how do you put all the models into 1 OC group?

[Scott Richmond]

Don't loop. You'll need to keep track of whats entering and leaving your area. The most simple way to do this is:

- Place all viewable tiles into list 'prevTiles'.

- If player position changed,

-- Place the new set of tiles into list 'currentTiles'

-- Compare the 2 lists: prevTiles - currentTiles = newTiles; currentTiles - prevTiles = oldTiles;

-- Hide oldTiles

-- Unhide newTiles

 

That ways is really hacky, but its 'easiest'. There will be a nice way to do it mathematically with AABB 2D box comparisons or something like that.

 

As for OC groups, do some searching on the forum. I swear I even started a thread on it awhile back. I think these days all you need to do is use general model groups.

[Rick]

Thanks Scott. I'll actually give the AABB way a try if Lua has the one function that gives a callback with everything inside the AABB.

[YouGroove]

You can perform some sort of tree bounding box culling algorythm ?

When the the tree is not near the player , and bouding box is not visible o ncamera frustrum, just don tdisplay the tree ?

 

Do you use some software LOD ?

if dist > 100

show model 1

else

show model 2

end if

 

 

 

The problem with that is as I move it keeps showing more models but not hiding the ones out of camera view so the fps starts dropping.

 

A picture could be better ? Do you mean trees behind the player or outside of the camera field are displayed in the 3D buffer only ?

[Rick]

You'd have to loop through all the trees and do a distance check. That's to much looping because there really are a ton of trees in the entire scene but because of the top/down view only a handful are visible at any given time. I think the best way to do it is to use ForEachEntityInAABB() and just keep 2 lists and compare each frame and hide the trees not in the current frames list that is in AABB. Way less looping involved that way. That means, however, I'll have to go back to C++ as Lua doesn't seem to implement that function *sigh*.

 

 

outside of the camera field

 

That's what I mean. Think of an RTS view. The majority of the map isn't even visible becaues of the top down angle. I was hoping Leadwerks would just handle this on it's own but it looks like it's not

[YouGroove]

A method would be to calculate the obuding box of the tree, if it is not on the camera field you would not display the tree !

I think your idea of processing only the grids around the player will help a lot.

 

That's power display routine , so yes i think C++ would be better for maximum speed gain.

[Scott Richmond]

Leadwerks already implements a really nice culling algorithm with octrees. Unfortunately it just doesn't seem to scale well with huge numbers of objects. The simplest fix is to just disable it and write your own one using AABB.

[Clackdor]

How big is your map, Rick?

[Rick]

128x128 1 meter per tile

[Scott Richmond]

If he implements the show/hide functionality using AABB maths then size doesn't matter. It should scale to infinity.

[Rick]

Something else seems to be going on per my other thread as it's drawing every object even though I can only see about 20 it looks like, but if nobody can figure out why that is what is the basic idea with what you are talking about Scott?

[YouGroove]

You'd have to loop through all the trees and do a distance check. That's to much looping because there really are a ton of trees in the entire scene but because of the top/down view only a handful are visible at any given time.

 

That's something to avoid indeed ! Another solution could be to check for surrounding tiles, each tile would have it's own memory table containing the

position of trees on top of it.

So you would just :

- recalculate what are the surrounding tiles when you would leav the current tile where you are on

- Hide the trees from the tiles that passed from visible to hidden when you moved

- for each surrounding tile, read the memory table with trees positions and display (or manage) only that trees

 

So this way you would just work per surrounding tiles instead of all level and manage only trees on tiles arround the player

[Rick]

recalculate what are the surrounding tiles when you would leav the current tile where you are on

 

Even looping through just the surrounding tiles is a decent amount of looping and slows things down (I tried that already). With tiles being 1x1 it's a good amount of iterations. I think what I'll do is loop over that surrounding grid over multiple cycles so it splits things up some.

[Clackdor]

I have 256x256, 1 meter squares, with about that density of trees in my current map (see video). I don't seem to have the problems you are having.

 

Based on that and what Josh said in the other thread:

 

Something is wrong if 4000 entities are being drawn. The Zone only had about 1000 at any given time. Perhaps you have large numbers of models that have complex hierarchies. I can't diagnose this further without seeing the scene files.

 

I would submit that there is something wrong with the map or the tree/grass models and instead of spending time on a work-around, attempt to solve THAT problem.

 

First thing I would do is replace all the vegetation models with the ones that came with the LE download.

[Rick]

Hey Clackdor, good idea. I'll do that tonight and see how it looks. Yeah I agree something is wrong it's just a giant pain to spend so much time on something like this. Frustrating.

[YouGroove]

Even looping through just the surrounding tiles is a decent amount of looping and slows things down (I tried that already). With tiles being 1x1 it's a good amount of iterations. I think what I'll do is loop over that surrounding grid over multiple cycles so it splits things up some.

 

Instead of looping you could use some virtual grid put on a 2D table.

Let's suppose each sqaure have 100 units of width.

If you would be on position 90, 0 , you should be be on first squarre on the 2D table that could be adressed like table(0,0)

When you move if you would be on 150,0 you should be on sesond squarre of 2D map : table (1,0)

 

Just by calculating simply : (PositionX / 100) take the rounded value and you have the squarre on where you are.

 

So you don't have to loop throught all grid , just determine on what squarre you are and take account of surrounding ones.

 

And you would have on that table for each adressed field some object containing some pointers to the trees that would be

on that squarre.

And you oculd write some object containing tah list of trees and having a method to show/hide them.

[Rick]

Just by calculating simply : (PositionX / 100) take the rounded value and you have the squarre on where you are

So you don't have to loop throught all grid , just determine on what squarre you are and take account of surrounding ones.

 

Yeah that's what I did, but it's still ended up being about 40x40 (because once I found the tile the player was on, given what the camera can see I would go 20 tile in both direction from the player) grid which seemed to take a decent amount of time when doing every frame.

 

So right now it seems all the grass amount is really what's hurting. To help I changed the view distance on all the loaded models since it's a top/down view I simply have a short distance where the engine will show/hide on it's own via the EntityViewRange() function. This actually helped a ton. I also turned off shadows for grass. That gave me about 50 fps which was better but still not the best. For now I've just removed grass which now gives me 100+ fps which is great. Grass was going to be a resource for my game so now just rethinking how I can get that resource.

[YouGroove]

Ok, so it's no more some tiles algorithm problem ...

 

 

For shadows, i think you could ignore them for grass, or bake them just by changing grass color, like shadowed on the base of the grass and lightened to the top : It should be an option , even AAA games not put shadows for grass or it is some option.

 

 

 

A good trick used in some games is to make some premade bunch of grass, i mean lot of grass patches together.

But this will work only on regular surface depending or you could have grass polys ont the ground and others on the air !

You could have lot of grass this way and win lot of FPS using only some few objects , each containing lot of grass polys.

 

I seen that trick on some 3D engine editors when you painted trees on the terrain, you painted a bunch of several trees

that were one 3D model in fact , that's help a lot the engine (and this is also for regular floor, not too much distorted).

 

Why not changing grass ressource to cristals , rocks or anything else ?

 

Could you post some pictures , it would be interesting seeing before and after optimisation ?

[Rick]

Why not changing grass ressource to cristals , rocks or anything else ?

 

The idea with the grass was that you could make rope with it and rope would be used in making other things as well.

 

After harvesting a grass patch it would go away and other grass would grow somewhere else over time to keep a certain coverage of grass at all times so doing some tricks like other games where grass is purely for visuals won't necessarily work in this situation. This concept is the base concept for the game. Trees get cut down for wood and you have to plant new trees or else you can end up with no more trees. Same for bushes, corn and other plant food.

 

The idea is to then turn this into a persistent multiplayer (network code is being thought of the entire time, this singpleplayer is just to get the basics down and see how it plays) game to watch how the world grows and evolves. I'm making a client updater so I can start basic but people can play sooner and keep expending functionality over time, but I want players to be able to start playing the game right away. Sort of taking on the Minecraft way of developing. See if you can get people to pay for a betaish game with free updates for the game forever.

[YouGroove]

You'll be the next big indie success story

Well i'll just wait to see it in action, just hope it will be something fun to play.

Minecraft success, is based on the exploration and creative side of the game.