If I have a parent object and combine multiple other objects with it by the flattenstrong method…would the effects of flattenstrong remain if I detach the parent object and re-attach it to the graph later? or would I have to re-call flattenstrong with all the objects involved, again?
flattenStrong() is a permanent change to your model, so it will remain flattened after detaching it and reattaching it.
Of course you could try this and see. 
David
So it’s really true huh?..
P3D won’t flattenStrong objects which have different textures and materials?
Whenever there are state changes involved, it is not possible to flatten models together. Panda will still need to tell the GPU to swap the texture or material before rendering the other geometry, so it is simply not possible to batch all the geometry together in one draw call.
So for materials and textures, the objective would be giving each sublevel of the whole it’s own material and atlas, then create a gloss map (texture stage) which supports any surface that should have a slight shine as well as surfaces that should appear dull.
How about this one… I attach objects B, C, D, and E to object A and call flattenStrong. Later, I call a detachNode on object C. What happens to the state of flattenStrong now? In my tests, I was able to remove a sub-node from the flatten. I’m guessing one of two things took place… A- there was no flattenStrong effect to begin with or B- flattenStrong was lost and all objects were rendered as individual objects.
You can use tools like egg-palettize or perhaps the MultitexReducer to help you with combining nodes that have different textures.
As for your example: if the flatten was successful, C should no longer exist in its original form, so you can’t do any operations on it any more. So, C.detachNode() would simply fail to produce the desired result and you should not rely on being able to manipulate C at all after the flatten operation.
Just trying to figure out what approach will work or not work for flattenStrong…
So, if objects that are to be grouped together have a material each, then flattenStrong will not work, right? Then, if I have a parent object which has a material and attach all other objects to that parent object and call flattenStrong, will P3D apply the material on the parent to all objects? (and all objects are textured by an atlas for this scenario)
or
Will P3D just say, “Since all these objects have materials, I am not going to flatten them, when I could have just assigned the parent’s material to all then execute flatten, since all objects are textured from on source…but no”
What I want to do is give all objects a Material while creating baked textures; rather or not to remove materials before exporting to egg or bam for the purpose of flattenStrong… That’s the question.
If two child nodes have different materials, flattenStrong will leave them alone; it will not merge the nodes, and leave the materials as-is.
For example, if you have four child nodes, the first and second sharing a material, and the third and fourth sharing another, flattenStrong() will result in two child nodes; the first and second merged together, and the third and fourth merged together as well.
However, if all four child nodes have the same material, flattenStrong() will flatten them all together and you will end up with only one node (the node you called flattenStrong on).
So in general, the only thing you need to worry about is that you don’t create too many differing materials; flattenStrong will make sure that the ‘look’ of the objects to be flattened won’t change no matter what. So, you don’t usually need to make additional considerations.
Then my theory is correct…export objects with no materials, flatten and then set a Panda created material to the new single flatten node.
That leaves one issue; different surface shine.
I wondering if I can somehow use an ambient atlas with P3D’s gloss map TS to somehow give objects their correct shine even though they are merge as one with the level itself…?
I’m confused though… The manual says a gloss map needs to be an alpha texture… ? Define alpha texture. I know normal maps have alpha data imbeded; unless gloss maps need to be a texture format which holds alpha, like png…that’s just my guess. Ambient maps are black and white by default (at least in Blender 2.4).
I was playing the game Dishonored and realized…most of the game levels use baked shadows. Only Actors have real-time shadows and some smaller level scenery do. The game sucks because the programming is broken; glitches all over the place. When will developers learn…the AI or programming of a game IS the game. The graphics compliment the programming if it’s perfect. Visuals are nothing without flawless programming and AI. Not impressed at all with Dishonored and find it quite boring.
The gloss information needs to be in the alpha channel of the image.
I think I have a good curve ball here…
What if I had serveral objects, one atlas, one material and called a flattenStrong, grouping the objects into one…but one of the objects have engine based alpha set (0.5 transparency).
What will happen now?
Will the transparent object drop the alpha setting or will flattenStrong fail?
or
Will all objects combine except the one with alpha?
No different from before. If one of your objects has a different render state set, such as a transparency attribute, it will not be flattened together with the other objects. You’ll end up with one node without the transparency and one node with the transparency.
When you say different render state, does that apply to future changes as well? For instance, if you have three objects flattened into one successfully and later decide to change the texture atlas for the flattened object, would that effect the state of flattenStrong? Same question for texture stages…
After flattening, you can of course still change the render state of the flattened objects, but you won’t be able to change them on individual objects that have been flattened together of course (only on the merged version of all those objects), since the flatten operation is permanent.
So rotating and scaling a flattened object isn’t going to cause cull issues?
There is no difference between a node that exists as a result of a flatten operation and any other node. So no, if there is a node to transform, transforming it will not cause “cull issues” whatever that may mean.
Since you keep asking similar questions, I should explain that you should see “node.flattenStrong()” as a method that simply reorganises the node structure below “node”. It may remove nodes, it may not. But it won’t change the materials or any other render state, nor will it prevent you from doing anything with “node” itself afterward. The only thing you need to keep in mind is that you cannot rely on being able to access children of “node” any more, since some may have been removed or merged.
I ask because I have experienced serious frame rate drop when manipulating an object that has had the flatten operation performed on it (in the past while testing). This lead me to believe, transforming the vertices in anyway of a flatten object was a no no. I then stopped calling flatten on any object I already knew I would rotate, move or scale.
According to your answer, it is not dangerous to rotate, move or scale (cause transforms) while in a flatten state. Maybe something else was going on with my past tests; I can only guess I was not getting a clean flatten of objects before. Understanding the limitations more clearly now, I hope I can avoid the same fps drop issues (I think I will this time 
).
One thing I really hate is having to go back and re-construct a large portion of code while developing an enormous project.
As rdb explains, the purpose of flattenStrong is to combine many small objects (wherever possible) into a few big objects.
There are two main side-effects of doing this that you should understand:
(1) It may improve performance if your performance was previously limited by sending too many individual objects to the graphics card.
(2) It may reduce performance if your performance was previously benefiting by eliminating many individual objects that were outside of the view frustum.
So if you call flattenStrong() and you suddenly have reduced performance, it may be that you were in condition (2). The bottom line is that you cannot naively call flattenStrong() on your scene and always expect your performance to improve. Sometimes it will not improve at all, and sometimes it will get worse.
Ideally, you will understand the structure of your scene and where the performance bottlenecks are; and then you will have an informed idea about how to improve performance with appropriate calls to flattenStrong() within the scene.
One way to build this understanding is to experiment with different combinations of flattenStrong() and observe the results in PStats. This is of course time-consuming and involved. But there is no magic way to achieve ideal performance without a lot of time-consuming effort. Sometimes you even have to go back and re-construct a large portion of code. 
David