vbo/vertex array performance : one high poly or lots of low poly models?

[teletubo]

In my current project, I have lots of trees being displayed in a scene . Some of them are merely decorative, that is, player will not interact with them and they will not affect pathfinding and stuff .
But since there are a LOT of decorative trees, in some weaker machines it causes a performance hit, since there are lots of objects being rendered.

I’m thinking about joining a cluster of decorative trees in one model, let’s say 5 trees in one obj model, and render it instead of rendering 5 trees .

Will I have a resonable performance gain ? Will it make difference at all in Vertex arrays ?

[lhkbob]

This will help a lot. If you consider the extreme case, you could render 10000 cubes or combine the 10000 cubes into one large “geometry”. The single draw call will perform waaay better for three reasons: less JNI overhead, the card only has to work on 1 operation so its queue isn’t being flooded, and the CPU has much more free time to do other things while the card is processing (instead of continuing to queue OpenGL commands).

I’ve found that vbo’s and vertex arrays can scale reasonably well up to 100,000 polygons in a shape and not do terribly. At that point, though, vbos really do better than vertex arrays and you’ll still only be able to render a couple of them at a decent framerate but it’d be even harder to make 100,000 or 10,000 draw calls in a frame.

You would need to limit it to trees nearby so you could still benefit from frustum culling. If you trees have different textures, you’ll have to figure out how to combine them into a single texture that you can activate when drawing the clustered geometry.

[Riven]

I fully agree with lhkbob.

@teletubo

I’m thinking about joining a cluster of decorative trees in one model, let’s say 5 trees in one obj model, and render it instead of rendering 5 trees.

Noooo!

Do this in your engine. You can combine the geometry at runtime, purely based on model properties (does it share a texture?) and information like instance locality (combine all geometry in each cell of a grid).

[teletubo]

@Riven

I fully agree with lhkbob.

@teletubo

I’m thinking about joining a cluster of decorative trees in one model, let’s say 5 trees in one obj model, and render it instead of rendering 5 trees.

Noooo!

Do this in your engine. You can combine the geometry at runtime, purely based on model properties (does it share a texture?) and information like instance locality (combine all geometry in each cell of a grid).

Yeah, I thought about that, it would be stupid to spend more memory and disk space in storing/loading another obj with data I already have ready to use .

Thank you both for the info .