Advice on optimisation sought

Troubleshooting General Help
1

Hi all,



I have some general queries about approaches to scene optimisation, if anyone would care to share their thoughts…


  1. Merging meshes.



    a. I understand that the number of Geometries is as much (or more) of a contributing factor to overall speed as the amount of polygons/vertices, and that it is recommended to merge meshes which share the same textures. Is that right?



    b. If a Geometry uses multiple textures, would it be more efficient to separate each the Geometry into multiple meshes for each different texture, and merge similarly-textured Geometries only, or is there no harm in using Geometries which have multiple textures?



    c. If meshes are merged, they become larger, and therefore will not be culled as often because more parts of the mesh will remain within the camera frustum. Should I be aiming for small “clumps” of merged meshes to preserve culling of unseen faces, or should I just merge as much as possible and give no thought to the size of the meshes in my scene. Or something in between? Is there a good rule-of-thumb to use?


  2. Submeshes & nodes on the Scene Graph.



    a. On export from Blender, each Geometry is buried 3 levels beneath a node. Does this have a significant impact on speed? The only solution I can see (other than re-writing the Ogre export script) would be to export, then import into the JME3 scene editor and manually move the meshes out of their parent nodes. I am reluctant to do this if there is little gain, as this is a huge overhead, and it would mean I lose the ability to make changes in Blender, and import directly into my JME3 project. So, is it worth the effort, or do nested Nodes have little impact on overall speed?


  • I know I could do test cases for all of these scenarios, but I thought I’d put the questions out to the brains trust before embarking on the lengthy process of cutting and pasting my scene a dozen times.



    Thanks in advance for any hints,

    Jon.
2

The way i try to picture it is, you have 1 truck transporting goods from A to B (data sent to the GPU). You can either load 1 object in your truck, or you can load more into your truck and reduce the number of trips. Its the number of trips that is the big factor, loading doesn’t take much. But if you load it too much, then the truck tips over, you get the idea :), as for rules of thumb i’m not sure, you just gotta find a good balance that suits your game. As for detailed explanation, I’m sure someone can help you there :slight_smile:



There’s GeometryBatchFactor.optimise(Spatial) for static objects and BatchNode for moving objects.

2 Likes
3

Hey thanks for the advice.



Nice analogy with the truck… That’s pretty much what I thought (it’s good to have some confirmation, though!) Guess it’s a matter of trial and error to some extent.



Regarding the GeometryBatchFactory.optimise()… I take it I don’t need that if I just “Join” relevant objects in Blender before I export them, right?



For the benefit of other readers, I also notice (from Orge python script) that objects belonging to a group whose name starts with “merge” will automatically be merged upon export… which sounds dandy (though I haven’t tried it yet myself)

4

Some random stuff:



A Geometry can only have one Material. So the “If a Geometry uses multiple textures” part is not relevant.



Batching happens by material.



Merging things in blender may or may not create single Geometry objects when imported into JME. There are many dependent factors. It probably pays to check.



BatchNode can be a way of getting some of the better parts of both approaches in some cases.

1 Like
5

When testing optimisations remember to test them on a range of hardware too…

1 Like
6
A Geometry can only have one Material. So the "If a Geometry uses multiple textures" part is not relevant.

Egad you're right... I just noticed in the Scene explorer, single objects in blender with multiple textures are broken into multiple Geometries, so I guess that's one less decision to make. :)

BatchNode can be a way of getting some of the better parts of both approaches in some cases.

Thanks.
7
@jonmonkey said:
Egad you're right... I just noticed in the Scene explorer, single objects in blender with multiple textures are broken into multiple Geometries, so I guess that's one less decision to make. :)

thats why theres the new TextureAtlas class, to combine textures so you can merge geometries.
2 Likes
8
thats why theres the new TextureAtlas class, to combine textures so you can merge geometries.

I understood that the TextureAtlas doesn't handle repeating textures too well, though. Is that not so?

With that assumption, for each object that uses a repeating texture, I've had to define a separate Material. (or rather, 1 Material/Texture for ALL my textures that repeat in 1 direction only (X or Y), 1 material for EACH Material/Texture that repeats in both X and Y directions, and 1 Material/Texture for ALL my textures that don't repeat at all.)

Most of the objects in my scene share 2 Materials (1-direction repeat, and no-repeat). Other materials are only used when I need to have X&Y texture repetition, animate, or change the material properties.

Does that sound right to you?

And while we're chatting (and for the benefit of other newbies reading this :) )...

1. For objects whose textures do not repeat, I have not been using textureAtlas anyway. I gather TextureAtlas is simply a large bitmap, with some auto-calculation to merge separate images into one, merge objects, and re-map the objects' UV's appropriately at runtime.

Instead, I have created a large texture manually in Photoshop (with all the bits of all my objects), then created ONE Material in Blender, applied it to all relevant objects, mapped their UV's to my mega-texture, and merged them into one object before export. (Although I'm yet to try "BatchNode" as suggested in this thread, so I dunno... )

Am I missing a trick, or is that a valid alternative do you think? (I just find it easier to work in Blender/Photoshop than use code to alter my scene)


2. And just to clarify my previous post, I think I meant Materials (not Textures)... Textures on Materials with different properties (alpha, specular, etc.) would not be able to use TextureAtlas, nor the method I just described in 1. above, would they? As I understand it, TextureAtlas requires all objects have to have to same Material definition.

SO MANY DECISIONS!! And I thought this 3D game gig would be a walk in the park hahaha.
1 Like
9

Yeah, you’d have to repeat the texture on the atlas, making the effort futile. You can separate the mesh so you can define new coords. A few more triangles won’t kill your GPU.

  1. Is exactly what I propose to do, have the atlas beforehand and then map the texture coords accordingly on your model, works especially well for quickly texturing towns etc., less so for characters.
  2. one material = one texture, well at least one texture of one type (e.g. diffuse, normal, specular etc.)
1 Like
10
@normen said:
Yeah, you'd have to repeat the texture on the atlas, making the effort futile. You can separate the mesh so you can define new coords. A few more triangles won't kill your GPU.
1) Is exactly what I propose to do, have the atlas beforehand and then map the texture coords accordingly on your model, works especially well for quickly texturing towns etc., less so for characters.
2) one material = one texture, well at least one texture of one type (e.g. diffuse, normal, specular etc.)


Excellent.

Sorry for the big brain dump above, but it's very useful/reassuring just to confirm I'm taking the right approach, when there are so many different ways to do all this stuff. :)
1 Like
11
@jonmonkey said:
Sorry for the big brain dump above, but it's very useful/reassuring just to confirm I'm taking the right approach, when there are so many different ways to do all this stuff. :)

If its this way round I don't mind, easier correcting the dump than dumping yourself twice every week ;)
12

Can the content of this thread be summarized into a couple new entries on our best practices?

1 Like
13

Sorry, erland_sh I ment to vote you up (stupid iPhone). Will make up for when I can!

1 Like
14

There, I fixed it. You can thank me later. :wink:

1 Like
15

and i fixed it more :slight_smile:


@kwando said:
stupid iPhone


you better hope a certain someone, doesn't read that :)
16

Me?

17
@erlend_sh said:
Can the content of this thread be summarized into a couple new entries on our best practices?

The information about modeling and model import is in the wiki: https://wiki.jmonkeyengine.org/legacy/doku.php/jme3:intermediate:multi-media_asset_pipeline