G'day,I read some good info at http://www.synapsegaming.com/forums/p/647/2717.aspx#2717But we still have some questions.We have a park scene with buildings, trees, stuff etc.... This one FBX has a pile of textures it links to. Should these textures be embedded or somehow merged into on big jpg?What kind of performace inmprovement would we receive if we actually merged all these objects into one mesh in the file? Bonus: Is .FBX prefered over .X? And if so/not why? We are about to add some characters to our game.
hi,
let me see if i can answer some of your questions!
Q: We have a park scene with buildings, trees, stuff etc.... This one FBX has a pile of textures it links to. Should these textures be embedded or somehow merged into on big jpg?
A: textures for meshes can hold alot of unused (un-textured) space. these small amounts of pre-allocated/unused memory can add up quickly, eating into the 150mb binary limit. packing texture/UV parts tightly together will gain you valuable asset space. multiple models/meshes can access the same image for texturing.
but, the main questions you need to ask yourselves are:
FBX or X? ......... FBX has more updates and gets more improvements than X files. and, when exported as ASCII for debugging, can be easier to read !!!
Hey,
Beware of "Wall of Text" 12/12, Flying with Trample.
The improvement to performance by grouping objects is solely dependent on how your scene itself is assembled and laid out. Are the texture used as a per-object basis (example: trees use one texture, benches use one texture, etc) or are they being used a material textures (tree wood and benches use the same wood texture, tree and bush leaves use the same leaf texture, etc)? I can take a quick look at the scene and assets to better determine which would be the best route for optimization if you would like. I'm planning on writing a giant optimization doc in the coming weeks, so here's a few things I will tackle in the doc that may help you here:
I'll start by stating that scene optimization is best to be considered on a per-scene basis as what works for one does not work for others. Here's a quick run down on how we can go about it.
There are two things to consider in your particular scene, the amount of materials and the amount of individual objects. First, we'll tackle the models. Given that it is a park scene, I'll assume there are quite a lot of objects. Merging/attaching them together will minimize the amount of objects, but keep in mind that if two attached objects share separate materials they will effectively still be two objects. How your meshes are textured (whether they are unique UV channel textures or many tileable textures assigned to portions of the mesh) will alter your optimization routes quite a lot.
If they are objects with only one texture assigned (scenario A), then it would be best to attach like objects that use the same material. This isn't to say group all of the same objects, but to do so logically based on "visible groups", or a group of the object that would be visible together. Two trees on opposite ends of the scene would not have a benefit to be grouped in most cases, as both will be rendered when one is in view. On the other side of the coin, if there are a number of tileable textures assigned to singular meshes across the scene (scenario B), grouping objects that share similar materials will have a large benefit to performance as it will split the meshes per materials.
Scenario A: We'll consider two objects, both sharing same single material. When ungrouped, there will be two objects. If grouped, given that they share the same material they will now be one object and will also both be rendered whenever one of them is in view, even when the other is not. In a situation where there are 50 objects sharing the same material and they've been grouped they will now be one single object. Depending on the object count vs. other bottlenecks, it may be beneficial to group all objects sharing the same material even though they aren't all visible together, though as stated earlier, this is best done on a per-scene basis.
Scenario B: Imagine those same two different boxes only now they share six materials, one per side. If these are left ungrouped, we're left with 12 separate objects in the scene(6 materials x 2 objects). If we attach/merge these two boxes, we've now brought that count down to 6 (separated by the materials). Now imagine this with 10 boxes (60 objects vs 6) and you can see how grouping the like objects can have a great gain. This applies to any objects that share materials.
Understanding this, we can move to textures. Having a texture atlas for different textures is difficult to do, creates more geometry to fit the UV space, but is highly beneficial in most scenes (again, with all things.. there may be exceptions). It greatly limits material batch counts as well as object counts. Most AAA titles that have outdoor only buildings use this technique to allow more varied building around the world scene. I would highly suggest grouping the objects before going this route, as it would involve overhauling most of your assets, that and the increased geometry to supplement the texture sheet UV's could increase the vertex count (which is another bottleneck). Just remember that for each additional texture used in the scene you also increase the number of objects in your scene. If you're able to create a texture atlas on a per-object basis or similar object basis (all plant objects use the same texture sheet) it would be simpler and more time efficient than creating a scene texture sheet.
I'm not sure of the different of .x to .fbx I must admit, but I'm sure the other developers here can help you with that.
Hope this helps,
Alex
Follow me on Twitter!
Another thing can greatly complicate the scenario:
When rendering the scene once, you want to minimize draw calls, but if you have to render the scene several times, to create shadow maps for example, you may process geometry you do not need because it is part of a large batch and this can be costly very quickly too.
In short, there is really not one way to make it, but a good understanding of the rendering pipeline will help you find what is optimal in each case.