Bad performance on a scene, but not on another with more geoms

Hello, I have an issue with the frame rate on a single scene. I am unsure why and I hope you can help me.

I use flattenStrong() on the scene but I still experience poor performance. When I try to run render.analyze(), I get this output:

16 total nodes (including 0 instances); 0 LODNodes.
6 transforms; 6% of nodes have some render attribute.
22 Geoms, with 3 GeomVertexDatas and 2 GeomVertexFormats, appear on 3 GeomNodes.
14959 vertices, 14959 normals, 0 colors, 14935 texture coordinates.
GeomVertexData arrays occupy 473K memory.
GeomPrimitive arrays occupy 49K memory.
8654 triangles:
  3128 of these are on 1307 tristrips (2.39327 average tris per strip).
  5526 of these are independent triangles.
20 textures, estimated minimum 46080K texture memory required.

Which looks better than one of my other scenes, which runs perfectly fine. For some reason it is just this one scene. The analysis of the other scene is the following:

50 total nodes (including 0 instances); 0 LODNodes.
11 transforms; 4% of nodes have some render attribute.
40 Geoms, with 8 GeomVertexDatas and 3 GeomVertexFormats, appear on 8 GeomNodes.
19433 vertices, 19433 normals, 17155 colors, 19409 texture coordinates.
0 normals are too long, 13 are too short.  Average normal length is 0.999331
GeomVertexData arrays occupy 678K memory.
GeomPrimitive arrays occupy 79K memory.
13574 triangles:
  1904 of these are on 769 tristrips (2.47594 average tris per strip).
  11670 of these are independent triangles.
38 textures, estimated minimum 72960K texture memory required.

I am unsure what the issue with the scene is or how to find out. I just tried to heavily optimize it by removing polygons and shrinking textures, but it is still not 60 fps as my other scenes. I hope you can help me figure this out. Thank you!

Does the low-fps scene perhaps have a lot of transparency, or significant use of cull-binning, or greater use of post-process/full-screen effects?

Thanks for you reply.

I am unsure, what cull-binning is. As it is now, all objects are front-culled and there are no transparency or prost-processing whatsoever.

The only thing I can think of is a lot of models being front-culled when they should be both back and front culled, i.e. some shelves which are consisting of a single plane.

In short, it’s the process described on this page.

Do you mean back-face culling? And do I guess correctly that you’re referring simply to the engine’s built-in handling of this, and not to something that you’ve applied or implemented yourself?

If so, then that should be fine, I imagine.

Hmm… In that case, have you tried a less aggressive flattening method–say “flattenMedium”? Perhaps “flattenStrong” is doing a bit too much in this case, and by doing so undermining the engine’s attempts to improve performance by removing elements that are out of sight.

Another thought: does the low-fps scene perhaps use larger textures than the high-fps scene?

And finally for this post: are you using shaders, and perhaps different shaders in different scenes?

Oh, I have not touched cull-binning at all.

And yes, I meant back-culled, the standard handling. I have not altered anything there.

All textures are 512x512 in all the scenes now. They were 1024x1024 in the scene in question before, but I suspected it was causing the issues, so I changed them. However, it hardly improved anything.

I am not using any shaders yet. The scene is almost just a 3D model I imported to show in my game. No collisions yet either. Also, flattenMedium did not improve it, it seems.

I tried to export the scene without the shelves and got 60fps. I find that strange, because the shelves are only about 2000 polygons. The total poly count of the scene including shelves are 12k and I have other scenes with 13k polygons running just fine.

Hmm… Could you post a model containing just the shelves, please? (With no further modifications, ideally: just delete everything that’s not a shelf.) Perhaps a Blender file, or something that Blender might import? Perhaps there’s an issue in the model that’s causing problems.

Thank you very much! I have attached different model files (.mb, .obj, .fbx) and I hope some of them work for you. The textures were too large to upload here, so I have uploaded them to Google Drive, in case you need them: (200.2 KB)

Hmm… Importing the OBJ copy into Blender (Blender’s FBX importer gives an error–a version issue, I think–when attempting to load the FBX copy, and it doesn’t seem to have importers for the others) I don’t see any obvious issues…

Of course, it may not be the shelves, as such. Perhaps some other element is reducing performance to the point that it only just reaches 60fps, and adding even a little more geometry causes it to dip below that point.

Hum. One further thing: you could run your game with PStats active (see this page). That might provide further clues as to where the bottleneck lies. (I’d suggest running it alongside both your high-fps scene and your low-fps scene, so that you can compare the graphs given for the two.)

Thank you very much for your support. I will try to look into the PStats and see if I can identify the issue!

1 Like

Thank you for your support, Thaumaturge!

I successfully identified the issue using PStats. For some reason the collisions were the bottleneck, even though I yet have to make collisions in the scene. However, it was the cTrav, which was the issue, which I use for clicking on objects. It was traversing the render node, which I guess was too much to handle. Therefore, I simply made a node for interactive objects as a child to the render, which cTrav can traverse. It now runs a lot better!

1 Like

It’s my pleasure! I’m glad that you managed to find the origin of the problem, and have improved matters somewhat! :slight_smile:

Ohhh–are you perhaps having your clicking-ray(/segment/line) collide with visible geometry (perhaps using “GeomNode.getDefaultCollideMask()”)?

If so, note that visible geometry is in general not optimised for collisions, and thus may have a greater impact on performance than dedicated collision geometry, I believe. For the most part, I recommend having collision geometry–often simplified–that’s separate from your visible geometry.

Yes, it is using the visible geometry right now. I thought about changing it, but it is limited how many objects in my game will be interactive, so I think I’ll wait and see if it can’t handle it. Otherwise I must change it :slight_smile:

Fair enough!

I will say that I’d be inclined to expect a rather noticeable increase in performance by switching to dedicated collision geometry–even if you were to give such collision geometry to every object that you currently have interactions with.

1 Like