Performance cost of drawing 3DLines

Swarmer · Post by **Swarmer** » Sat Aug 30, 2008 4:00 pm

Is it bad practice for me to have the video driver draw 4000 3D Lines every iteration of rendering in a big for-loop? Is that actually as computationally expensive as it sounds?

If so, is there a better way? These lines never change position. They are always in the same spot (it's just a big grid). It seems like I could save a lot of cycles by not having to specify the same static position every iteration.

Dark_Kilauea · Post by **Dark_Kilauea** » Sat Aug 30, 2008 8:17 pm

You could use a scenenode to automate it and allow for culling if the node is outside of the frustrum.

See my grid scene node for a good example, it renders potentially thousands of lines rather quickly.

hybrid · Post by **hybrid** » Sat Aug 30, 2008 9:26 pm

Using a vertex list and drawing with EPT_LINES would make things lots faster. VBOs from Irrlicht 1.5 won't help, though, because the manually drawn verte arrays are not yet supported.
There had been several performance improvements for the grid node, try those as well.

Swarmer · Post by **Swarmer** » Sat Aug 30, 2008 11:10 pm

The grid node works great!

It'd be even better if it used drawVertexPrimitiveList, as hybrid suggested, but it runs good enough already.

The lines farther away clump up a lot and it's just a big gray blob, so a nice option to have would be to have the lines farther spread out as they get farther from the camera.

But it's sufficient already. Thanks.