Performance tuning: A large object

[Thaumaturge]

I’m currently attempting some performance-tuning in one of my levels, and could use some help, please:

My current focus is on one particular node. According to DirectTools (which is a wonderful tool, by the way!), removing this node results in a significant jump in performance. The node in question represents a band of trees, modelled at a polygon-count that looks reasonable to me, and that encircles the outdoors “courtyard” section of the level. (The trees behind, representing the rest of the surrounding woods, become progressively simpler.) The model also includes vertex-colours. There are about thirty-one trees included in the model, and the entire thing is made up of ~270 000 vertices, I believe.

Again according to DirectTools, this one node accounts for a significant percentage of the memory used by this region of the level. While the actual amount of memory used doesn’t seem enormous, I may be mistaken in that, and it may either way point to this being an expensive model.

However, I’m not sure of what to do about this. I don’t want to reduce the quality of the trees. If I split them up and use LODNodes, I fear that the proliferation of nodes may itself hinder performance, as might the fade between LOD-levels. (Having the trees pop in would be rather unsightly in this case, I think, as they’re the “front line” of the woods.)

One thought that occurred to me was to use Panda’s built-in instancing feature, instancing a single tree-model thirty-odd times–but I don’t know whether that would help here. It helps reduce the CPU cost of animating multiple Actors, as I recall, but would it help reduce the cost of these trees? (Note that they are in any case identical, just scaled, rotated, and with their own vertex colours. Those colours could perhaps be left aside.)

Hardware instancing is possible–but how widespread would availability of this feature be in potential users? I don’t want to limit my game’s potential audience for something that right now appears in only one level.

So–any thoughts?

[wezu]

If these woods surround the player/camera on all sides then dividing the model into 4 parts (down the middle, like slicing cake) will let culling discard 25-75% of the model depending on where the camera is pointed.

I think instancing is a openGL 3.2/GLSL 150 feature, but it can work in GLSL 130 with extensions. Anyway that’s technology from 2009.

[rdb]

You should try to find out whether the issue has to do with the amount of geometry or with the amount of pixels being drawn.

You can easily do this by resizing the window to be half the size. If rendering the object reduces to only a quarter of the time, then you know it’s got to do with the amount of pixels that are being rendered of the object, not with the amount of geometry. This could be due to excessive overdraw, ie. if you have lots of transparent cards making up the individual leaves that are being drawn over each other. If that is the case, instancing won’t help a bit.

[Thaumaturge]

@wezu

If these woods surround the player/camera on all sides then dividing the model into 4 parts (down the middle, like slicing cake) will let culling discard 25-75% of the model depending on where the camera is pointed.

Hmm… That’s an interesting idea. I would probably divide it further: when standing at one end of the enclosure, most of the side-ranks may be visible, but the end behind the player wouldn’t be. I may try this, thank you!

[edit] All right, I’ve tried this–specifically, I broke the object into ten pieces (two on the short ends, and three on the long), aiming to increase the amount of potential culling. And it does seem to have helped! It’s not a huge jump in performance, but it is an improvement. [/edit]

@wezu

I think instancing is a openGL 3.2/GLSL 150 feature, but it can work in GLSL 130 with extensions. Anyway that’s technology from 2009.

It may be from 2009, but is support for it wide-spread now? (And widespread in machines that aren’t specifically gaming computers, for that matter.)

@rdb

You should try to find out whether the issue has to do with the amount of geometry or with the amount of pixels being drawn.

You can easily do this by resizing the window to be half the size. If rendering the object reduces to only a quarter of the time, then you know it’s got to do with the amount of pixels that are being rendered of the object, not with the amount of geometry

Hmm… According to the frame-rate meter, doing that takes me from ~15ms to ~13ms–so it would seem that it’s not a pixel-overdraw issue.

(Although in all fairness, I note that, due to the size of the “courtyard”, the trees probably don’t take up a lot of vertical space, so reducing the window may not reduce them as much as in the case of a scene amongst trees. Still, I suspect that this isn’t an overdraw issue.)

(The leaves are a separate object, by the way, using a different shader; deleting the trees doesn’t delete the leaves.)