Vegetation loader

[RdR]

Hello all,

A while ago I created a vegetation loader for TANK@WAR, which loads and creates vegetation on the fly (defined in a vegetation map).
I divided the world in patches so I can determine which LOD to draw or not drawing it at all (depending on camera distance).
I'm using the BatchingMesh to combine all the vegetation together (1 batching mesh per LOD for a patch node) to minimize the draw calls.

World
- X PatchSceneNodes (depending on the defined world and patch size)

PatchSceneNode
- N BatchingMeshes (1 BatchingMesh represents 1 LOD)

Say we have 3 LODs per patch and a patch has plant1 to plant9 it would be something this:
LOD0 = all plants
LOD1 = plant1 to plant6
LOD2 = plant1 to plant3

This all works pretty nice, but this solution uses alot of memory.
So my question is has anybody some suggestions how to improve this (reduce memory usage)?

I could minimize the memory by not using the same plant for each LOD (if they occure in every LOD), but that means I have to draw multiple batching meshes.
But that will decrease the performance

PS:
If you want to see it in action, play TANK@WAR

[ErUs]

I'm not sure what you mean by vegetarian. Is the main character in your game a vegetarian? are you trying to load the player model?

[serengeor]

I'm not sure what you mean by vegetarian. Is the main character in your game a vegetarian? are you trying to load the player model?

What the F

[ACE247]

Seconding serengeor. What the FFFF?
But I bet something went terribly wrong with google translate and other language interpretations...

On a different note, RdR maybe you could outline your algorithm a bit more. Maybe profile it a bit?
Is likely some lookop function, draw call or otherwise holding up the proccessing time?
There could be some small simple code bits holding up your vegetation lod system that you've missed/etc, as I all too well know with these kind of systems.

[ent1ty]

Don't get confused, that's just the old rascal erus trolling hard

(well done btw )

[RdR]

I'm not sure what you mean by vegetarian. Is the main character in your game a vegetarian? are you trying to load the player model?

Lol

On a different note, RdR maybe you could outline your algorithm a bit more. Maybe profile it a bit?
Is likely some lookop function, draw call or otherwise holding up the proccessing time?
There could be some small simple code bits holding up your vegetation lod system that you've missed/etc, as I all too well know with these kind of systems.

The algorithm is not the problem, it works good and only creates vegetation when the map loads.
Problem is the memory its uses. Not when creating it, but when the vegetation is loaded, it uses alot of memory to hold all the vegetation data.

[ErUs]

Firstly: Are the patches repeating?
If they are then just make the patch smaller.

If not then you could try streaming from disk, but async loading can be a pain with irrlicht.

[RdR]

Firstly: Are the patches repeating?
If they are then just make the patch smaller.

If not then you could try streaming from disk, but async loading can be a pain with irrlicht.

Patches are not repeating because they are unique, but plant meshes are repeated (but rotated / scaled a bit)
If i make the patch size smaller, this means I need more PatchSceneNodes to cover the world.
And results in the same memory, because the same plants are used.

[hendu]

You're right that instancing would solve this issue. With no cpu-side batching, the naive implementation would be one draw call per plant.

Just curious, what memory and how much?


T@w is very close to looking better than scorched3d, btw

[ACE247]

T@W is quite similar to Zero Ballistics actaully, but better.
Except, the Environment scaling in T@W is a 'bit' of... Trees are so unrealistically huge...

[RdR]

You're right that instancing would solve this issue. With no cpu-side batching, the naive implementation would be one draw call per plant.

Just curious, what memory and how much?


T@w is very close to looking better than scorched3d, btw

Yep, thats why I PMed So far only good solution I found to solve this problem.
Memory depends on how much vegetation there is in the world/map.
In the free hills map its ~500MB extra memory for the vegetation (no trees)

Not familiar with scorched3d but will check it out

T@W is quite similar to Zero Ballistics actaully, but better.
Except, the Environment scaling in T@W is a 'bit' of... Trees are so unrealistically huge...

Thanks!
Hmm wil look into that, some more improvements or suggestions (for T@W or this topic)?

[Virion]

I think instancing could probably save up a lot of memory while maintaining good performance. correct me if i'm wrong.

[ACE247]

Instancing is definetly the way to go.
I thought you already had that, RdR? Any good veg manager will need it...

[RdR]

Instancing is definetly the way to go.
I thought you already had that, RdR? Any good veg manager will need it...

No, dont have it yet
Does anyone got a good Instancing example with Irrlicht?
Or give me some pointers?

[hendu]

Well, start with my old hack, figure out how to nicely add instanced arrays to irr api, and implement DX parts too if you want those