[Tutorial] BI Sample Data Modding 102a - Model Optimization Section Count Reduction

[cifordayzserver 119]

When modifying the Bohemia Sample models, you may find the base model, or your modified model end up with very high section counts.

This affects performance adversely for every instance of the object. So for even a small object like a wall or a tree or a bush that is repeated many times througout a terrain; it is VERY important to optimize models.

For highly modified models you can end up with needlessly high section counts, which are tedious but simple enough to rectify.

I want to give a special thanks to RKSL-Rock for advising M1lkm8n on how to accomplish this, as well as Snakeman of PMC Tactical for also providing relevant info and advice! and OBVIOUSLY to M1lkm8n for passing it on to me!

http://www.rkslstudios.info/

&

http://tactical.nekromantix.com/

Models can and should be optimized in MANY ways when being created from scratch, however this tutorial only focuses on correcting problems that can happen when forward porting, or editing, an existing BI model.

I am making this tutorial mainly due to the lack of readily referenceable material regarding section counts in modelling for arma or in general. I am by no means an expert in the field, nor do I have a solid fundamental background in 3d modelling or texturing.

I. A quick primer

+++++++++++++++++

Models in O2 and all modelling software are made up of 3 components:

1. Points - Fairly clear, it's a dot somewhere in the 3d space of modelling software. In design based 3d software like AutoCad this can literally be a list of xyz coordinates entered in sequence.

2. Faces - Faces are a planes that connect any 3 to 4 points to create a solid surface, on which textures, materials, or shaders may be applied

3. Sections - a section is an collection of connected faces that all use a common texture, or material

In the normal resolution lods, the model is UV unwrapped and textures are mapped to that "section" of the UVmap. The section count is a direct result of the number of unique textures + the number of different RVMats for any texture.

Also worthy of note, is that the SAME texture can exist in multiple namespaces, so it's VERY important to ensure textures are being pathed to the same namespace when applying them initially, or during the modelling process.

II. Why are sections bad?

++++++++++++++++++++++++

1. Because smarter people than me say so.

2. Everyone I know that went to school for modelling be it for commercial or entertainment purpose, say the same thing... section count is THE PARAMOUNT consideration. If you can (and you should) make ALL models 1 section.

I have no idea if this is currently accurate, or applicable directly to Arma, but I have been told by MANY Arma specific modders, and one of the BI DevZ that it was the most important consideration for models in Arma as well... DRASTICALLY more important than poly or face count.

HOWEVER, it must be stated, that some of the SMD buildings were in circulation for a LONG time with INSANELY high section counts, and no noticeable effect on performance, upto and including having them in an MP game state where loot was spawned in every room.

Moron's Summary:

I did not go to school for modelling, and I have not really found many resources outlining the intimate details, or even identifying the proper verbiage

BUT... essentially, graphics cards are forced to start an entirely new draw cycle when they encounter a new section... so if you have high section counts the GPU is forced to spend more time assembling processable packages, and lining them up for processing, instead of screaming through huge chunks of assembled data.

So, the section counts drastically increasing was quite a mystery to M1lkm8n and I for a while, and many people gave us guidance, and pointers in the right direction.

III. What goes wrong?

+++++++++++++++++++

1. When moving a model's namespace OR when port forwarding model content (see glossary below) the pathing to the textures are re-pathed to the new namespace or texture type, this can often be done less than optimally.

2. When copy/pasting faces from a model back in and manipulating them can often cause Oxygen or Object Builder to not associate the new face/texture with the section it was copied from.

+++++

RULES

+++++

1. BACKUP YOUR FILES before you begin work. OFF the P drive.

2. Monitor the changes you are making in Bulldozer after EVERY change and BEFORE saving progress

3. Check, Double Check, Re-Check, Check again, and when you're done with that CHECK AGAIN!

4. Save your progress often and BACK IT UP OFF the P drive.

IV. How to fix it

+++++++++++++++++

The process is tedious but very simple, it's very likely that someone could script something to automate this in O2, but I do not know how to do that.

1. Open your model

2. Select the 1st Resolution LOD (normally 1.000, in the example shown it is 0.000)

3. In "Resource Library" Window (If this window is not shown you can activate it as shown: Window->Resource Library)

4. Open the dropdown for "Current LOD" and then open the "Textures" folder

As you see in the example picture, there are 8 textures used for the model. This means that there will be a final MINIMUM section count of 6, however, if any of those textures are using different RVMats, then the section count will be higher.

In SOME cases, you can normalize the rvmats to reduce section count with little to no visual effect in the final model... In other cases, you will ruin the appearance of your model, and it will be difficult to revert the changes if you have saved your progress.

Back to the example, and you can see an ASTOUNDING section count of 164

WHY!?!?!

No idea, but lets get to work on fixing it.

5. Right click in the empty space in the "Lods" Window (If this window is not shown you can activate it as shown: Window->Lods)

6. Selct "new" from the dropdown menu

7. You will see a new resolution lod created

8. Re-Select the 1st resolution lod (in the example 0.000), in the "Lods" Window by double clicking on it with the LMB

9. Select the 1st texture listed in the "Resource Library" window (in the example "drevo_prkna_stara_co.paa") by clicking on it once with the LMB

10. Now, click on the selected texture with the RMB to activate the properties menu and click "select in object"

11. Copy the selected faces (ctrl+c)

12. Select the LAST resolution lod that you created in step 6/7 by double clicking on it with the LMB

13. Paste the copied faces (ctrl+v) into the new resolution lod

14. Check the section count in the new resolution lod

- IF there is only 1 then skip BACK to step 9 and repeat for the next texture listed in the "Resource Library" window until all the listed textures have been pasted into the new lod

- If there is more than one section or MANY sections then:

15. Press "E" (or from the file menu select Faces->Face Properties)

16. You will see two Text Entry areas in the "Texture and materials" portion of the window. The "Texture" will show the name of the texture you selected with it's full namespace path. The "Material" will show "..."; this indicates that there are more than one RvMats referenced by the same texture. In some cases this is required or intentional. If it's a matter of saving 1-2 sections, then carry on for now, although I do check to see if the changes are noticeable and use the same RvMat if it will look fine.

17. Select one or more faces listed with the RvMat that you wish to use, Copy that full path in the text entry area marked "Material"

18. Select ALL the faces that you want to change the RvMat for and paste the full path of the rvmat into the text entry area marked "Material"

19. Watch the section count drop.

20. Once you have completed steps 9-19 for ALL the listed textures in the 1st resolution lod. Continue to step 21

21. Select the last resolution lod you created in step 6/7 by double clicking on it with the LMB

22. Select all (ctrl+a) and Copy (ctrl+c) to copy ALL the points/faces/sections

21. Select the 1st resolution lod by double clicking on it with the LMB.

22. Select All (ctrl+a) and delete by hitting the "delete" button on your keyboard, or by selecting "delete" from the Edit drop down file menu

23. Pasted all the points/faces/sections from the final resolution lod that are still stored in memory by hitting "ctrl+v"

Your model should now have the lowest possible section count without altering the UV unwrapping or textures.... in the 1st lod ONLY...

24. Repeats steps 8-23 for EVERY resolution lod the model has. In example model this is 0.000, 1.000, 3.000, 5.000, and 20.000

It is a tedious and time consuming process, but it is an absolute necessity to optimize your models as much as possible.

This is only ONE means of optimizing the models. I wanted to take the time to document this process specifically because I had not seen any information publicly detailing the process.

I am by NO MEANS an expert in modelling or model optimization, so if I have mis-stated or poorly summarized ANY aspect of this tutorial PLEASE feel free to provide additions or corrections.

Thanks for Reading!

*Reference / Glossary

Namespace - Refers to the location in which a model expects to exist. The default namespace in arma 2 is CA, all models exist in either the common or the addons folder, hence the namesapce CA. Modified Addons must exist in a unique namespace, otherwise they will overwrite the defailt models as the modified models are loaded after the core game files.

Ex: The 2 story Brick Apartment building is called "panelak.p3d" inside the PBO "buildings". It's namespace is "\ca\buildings\panelak.p3d"

Our modified version of the 2 story brick apartment is called "smd_panelak.p3d" and it's inside a folder called "buildings" inside the PBO "smd_sahrani_artif_obj". It's namespace is: "\smd_sahrani_artif_obj\buildings\smd_panelak.p3d"

Port Forwarding - Refers to the process of taking an asset from a previous release of a game, and making it fully compatible and featured as possible in the next iteration of the engine.

---------- Post added at 04:26 ---------- Previous post was at 04:24 ----------

Putting this up before doing the video again that way there is some peer review going on before I do the video.

Some example figures from buildings I've done already.... smd_budova3: old count: 100 sections! Fixed Count: 11. Oi!

[Armod 10]

Hey bud, Very good tut!

Something that I find very very handy in Object Builder is the option to Export any selections you have defined to Proxy models, This is basically attaching one model to another, without the 2 being actually counted as the same model. I find it very good practice to set my model up as a whole first, then, Once it is all ready, I would always proxy out wheels, and my Resolution LOD Interiors of the vehicle.

[cifordayzserver 119]

Interesting, I have been playing with proxying parts of buildings a LOT, and plan on making a system that allows for the dynamic creation of any height building from a library of available models... although I haven't really began the project in earnest yet.

I took the panelak buildings and made 3 chopped up models that I use to proxy together in 2 different version (4 story and 8 story).. although I want to re-do how they're cut up.

I only published the 2 and 8 story ones, but as you can see, you can slap as many of the "Middle Floor" sections in between the "Ground Floor" and "Top Floor" models:

The FPS is terrible mainly due to how it was recorded, although obviously you wouldn't want to have 264 floor apartment buildings all over the place lol ;)

In the case of the BI models, often the sections are textures that are just used for LOTS of buildings, so it's not very logical divisions like wheels/interior etc.... I think the way they did it was to optimize package size not performance in game. I have a feeling that the models/game would perform better if someone took the time to export the models and give them proper dedicated textures per/building. I hope to actually do that at some point, but have a fairly long list of things that are more important to finish first.

Also, I have been mainly working with the A1 buildings so far, but the A2 buildings (and some A1) are broken up into modular parts similar to the way you describe, although I don't really understand the purpose of it for non-reused parts...

IE I get a wheel, but why the interior? Is it so the interior model/texture don't need to get loaded for players who are only viewing the exterior?

The complicated functions like LOD switching, occlusion culling, and sections are total mysteries to me. I plan on trying to learn more, but am always pulled in too many directions!

[x3kj 1247]

I have a feeling that the models/game would perform better if someone took the time to export the models and give them proper dedicated textures per/building. I hope to actually do that at some point, but have a fairly long list of things that are more important to finish first.

The reason why having dedicated textures per building isn't such a good idea, is because the larger your building gets the less texturedetail you can have, as everything needs to fit inside the UV square. For large buildings this would either result in outrageously large textures, or bad resolution. Also, if one texturefile is loaded it isnt loaded again into the videocard memory i would think. So if you have textures per building you are loading more textures in to the memory then if you had textures that are shared on all buildings. Think of doors... instead of one texture that contains a door, you have one door in each buildings texture taking up space. Also, if you where to alter the texture for the door, you do it in one texture only. With your approach you would have to change the door in several textures.

HOWEVER, it must be stated, that some of the SMD buildings were in circulation for a LONG time with INSANELY high section counts, and no noticeable effect on performance, upto and including having them in an MP game state where loot was spawned in every room.

That's because the rest of the game IS optimized for section counts. If it wasnt... you would have a problem. You won't see the effect in single-case studies. If you don't care about optimize models in larger projects it will bit you back at the very end when you play the mod and notice that somehow performance is bad. Especially if it's a totalconversion and you replaced many models.

Same if you use alot of different mods and all of them are not optimized.

Edited September 20, 2014 by Fennek

[PuFu 4600]

I find that in order to fix something, you need to understand how it works and thus what could go wrong, as well as what individual things are, and how engine handles it.

So if you don't mind, i'll have a few things to add, some to explain and even more to correct:

I. BASICS:

A. 3d meshes are made out the following (and i am talking about from a general POV, not simply from O2/OB)

1. Vertices (wrongly named points in O2) - the main difference between vertices and points is that vertices define polygons. Points are singular elements with XYZ coordinates that have no relation whatsoever with polygons. In O2/OB case points used for memory lods.

2. Edges - the line that is defined by 2 vertices, that creates an edge for a polygon.

3. Polygons (or faces) - the plane defined by at least 3 vertices. The 3 vert/edge polygon is called a tris. the 4 vertices polygons are called quads. The ones that have more the 4 verts are called ngons (O2/OB cannot handle ngons).

4. Elements - multiple polygons with shared vertices (welded).

5. Smoothing groups / hard|soft edges - the way the faces are shaded. Most 3d software packages use smoothgroups, some use edge solution (hard or hard) In the case of O2/OB, it is half way, since it is surface based, but follows hard or soft solution. It has a direct relation to the number of vertices normals (also in direct relation to the number of individual UVW islands), that in itself has a direct relation to the max number of vertices allowed.

B. Specific to O2 / OB:

1. Sections - is a number that has no relation to the mesh individual properties. It tells the user the number of external files the p3d is connected to, and thus the engine needs to search, load and eventually cache in order to display the p3d in its entire form.

It has nothing to do with connected faces or individual faces

The number is for the entire .p3d and not for individual LOD. What can fit in here:

a) diffuse texture files (1 section / texture map)

b) material file (1 section / rvmat)

c) proxies (1 section / proxy file - if the proxied .p3d uses a different diffuse + material it will add at least another 2 - IRC it won't display those additions though)

To fix what Cifor wrote: diffuse textures/rvmats can be used simply on individual and/or unconnected polygons. In theory one could have one diffuse per each face in a mesh. Same goes for rvmat. One could also have 1 diffuse texture for the entire thing but 3 rvmtas.

The optimal solution would be to have as little as possible individual files for each P3Ds. Most of the times that is simply impossible. Again, i am confident to say that it is better to have everything on a 4K texture map than 4 x 1K texture maps.

II. SECTIONS:

I simply cannot agree with Cifor approach: there needs to be more reasons behind sections rather than the puerile agreement of sorts : "because smarter people than me say so" or "some lad than went to school of modeling (never heard of this school before, and i have been working in the industry for some time. Arts schools yes, digital art yes, film school - digital department yes, never modeling school - except if you are referring to modeling in the sense of living-moving clothes hanger) told me so"

Anyways:

Sections are not bad by themselves. In fact it is a hugely important factor for content creators to guide themselves towards optimization. Huge number of section count will simply lower the performance when said asset is in use.

Reasons for such behaviour:

1. As previously said, Draw Calls.

I won't get into a lot of detail here, most is freely available on the web for anyone with some basic knowledge and interest.

a) a draw call is a so called "hit" towards the GPU. To put in in perspective, a game mesh (p3d file in this case) having one texture, one material file means 3 draw calls (1 for each). On top of that you have terrain, shadows, lighting etc. The fewer the better (if it wasn't obvious enough)

b) it is primarily a matter of numbers here. For current generation GFX cards, the size of texture, meshes, etc is not all that important, but the number of individual sent packages is, simply because of CPU-GPU relation.

That is one of the reasons why for instance, if you have a multitude of individual 2x tris game objects, each with simple texture and material file, the performance would be worse than having all that in a single game object with a single material file. The CPU will have to send all those small packages of data towards the GPU for number crunching, while GPU will simply idle waiting on data.

Also, afaik, instancing is not really used in arma engine (maybe for terrain creation but i wouldn't know it, but would make sense since trying to populate objects manually in editor in the same way one would do in Visitor is just insane form performance pov), which is a bit weird since from DX9 handles instancing quite well.

2. Streaming:

a) all the data needs to be pulled from the HDD and send for processing. ArmA has an issue here, since very few of the data is buffered via RAM on one hand, and on the other hand the said data for ArmA is pretty fucking big, and that is without any sort of addons. (yes, size does matter here).

b) since the current data streaming tech for A3 is simply an enhanced OFP one, back in the day when the CPUs were all single core, the ram memory size was a lot lower 256-512mb back in 2001 (unable to correctly act as a buffer for the data), and the simple fact that the entire's game dataset was a lot smaller, it was all pretty much streamed continuous from the HDD.

The HDDs back then was very very similar in terms of performance with the current mechanical drives of today, at least from the performance POV. Remember that HDD is the single PC component (i am excluding SSDs on purpose) where the advancements were mainly in capacity size and stability, and NOT read/write performance, especially when comparing with all the other advancements ranging from CPU to GPu and anything inbetween.

I hope the above would shed some light on the way RV handles data, as well as the "mysteries" and dark side of sections.

[PenguinInATuxedo 18]

Ty for all the info everyone I am learning Terrain building but want to know more about modeling. I feel like the sandbag bunker I have been working on might not even work in ArmA, one day i will get a model I made onto my map :P

[cifordayzserver 119]

The reason why having dedicated textures per building isn't such a good idea, is because the larger your building gets the less texturedetail you can have, as everything needs to fit inside the UV square. For large buildings this would either result in outrageously large textures, or bad resolution. Also, if one texturefile is loaded it isnt loaded again into the videocard memory i would think. So if you have textures per building you are loading more textures in to the memory then if you had textures that are shared on all buildings. Think of doors... instead of one texture that contains a door, you have one door in each buildings texture taking up space. Also, if you where to alter the texture for the door, you do it in one texture only. With your approach you would have to change the door in several textures.

That's because the rest of the game IS optimized for section counts. If it wasnt... you would have a problem. You won't see the effect in single-case studies. If you don't care about optimize models in larger projects it will bit you back at the very end when you play the mod and notice that somehow performance is bad. Especially if it's a totalconversion and you replaced many models.

Same if you use alot of different mods and all of them are not optimized.

VERY good info! Thanks so much for the clarifications!

I find that in order to fix something, you need to understand how it works and thus what could go wrong, as well as what individual things are, and how engine handles it.

So if you don't mind, i'll have a few things to add, some to explain and even more to correct:

I. BASICS:

A. 3d meshes are made out the following (and i am talking about from a general POV, not simply from O2/OB)

1. Vertices (wrongly named points in O2) - the main difference between vertices and points is that vertices define polygons. Points are singular elements with XYZ coordinates that have no relation whatsoever with polygons. In O2/OB case points used for memory lods.

2. Edges - the line that is defined by 2 vertices, that creates an edge for a polygon.

3. Polygons (or faces) - the plane defined by at least 3 vertices. The 3 vert/edge polygon is called a tris. the 4 vertices polygons are called quads. The ones that have more the 4 verts are called ngons (O2/OB cannot handle ngons).

4. Elements - multiple polygons with shared vertices (welded).

5. Smoothing groups / hard|soft edges - the way the faces are shaded. Most 3d software packages use smoothgroups, some use edge solution (hard or hard) In the case of O2/OB, it is half way, since it is surface based, but follows hard or soft solution. It has a direct relation to the number of vertices normals (also in direct relation to the number of individual UVW islands), that in itself has a direct relation to the max number of vertices allowed.

B. Specific to O2 / OB:

1. Sections - is a number that has no relation to the mesh individual properties. It tells the user the number of external files the p3d is connected to, and thus the engine needs to search, load and eventually cache in order to display the p3d in its entire form.

It has nothing to do with connected faces or individual faces

The number is for the entire .p3d and not for individual LOD. What can fit in here:

a) diffuse texture files (1 section / texture map)

b) material file (1 section / rvmat)

c) proxies (1 section / proxy file - if the proxied .p3d uses a different diffuse + material it will add at least another 2 - IRC it won't display those additions though)

To fix what Cifor wrote: diffuse textures/rvmats can be used simply on individual and/or unconnected polygons. In theory one could have one diffuse per each face in a mesh. Same goes for rvmat. One could also have 1 diffuse texture for the entire thing but 3 rvmtas.

The optimal solution would be to have as little as possible individual files for each P3Ds. Most of the times that is simply impossible. Again, i am confident to say that it is better to have everything on a 4K texture map than 4 x 1K texture maps.

II. SECTIONS:

I simply cannot agree with Cifor approach: there needs to be more reasons behind sections rather than the puerile agreement of sorts : "because smarter people than me say so" or "some lad than went to school of modeling (never heard of this school before, and i have been working in the industry for some time. Arts schools yes, digital art yes, film school - digital department yes, never modeling school - except if you are referring to modeling in the sense of living-moving clothes hanger) told me so"

Anyways:

Sections are not bad by themselves. In fact it is a hugely important factor for content creators to guide themselves towards optimization. Huge number of section count will simply lower the performance when said asset is in use.

Reasons for such behaviour:

1. As previously said, Draw Calls.

I won't get into a lot of detail here, most is freely available on the web for anyone with some basic knowledge and interest.

a) a draw call is a so called "hit" towards the GPU. To put in in perspective, a game mesh (p3d file in this case) having one texture, one material file means 3 draw calls (1 for each). On top of that you have terrain, shadows, lighting etc. The fewer the better (if it wasn't obvious enough)

b) it is primarily a matter of numbers here. For current generation GFX cards, the size of texture, meshes, etc is not all that important, but the number of individual sent packages is, simply because of CPU-GPU relation.

That is one of the reasons why for instance, if you have a multitude of individual 2x tris game objects, each with simple texture and material file, the performance would be worse than having all that in a single game object with a single material file. The CPU will have to send all those small packages of data towards the GPU for number crunching, while GPU will simply idle waiting on data.

Also, afaik, instancing is not really used in arma engine (maybe for terrain creation but i wouldn't know it, but would make sense since trying to populate objects manually in editor in the same way one would do in Visitor is just insane form performance pov), which is a bit weird since from DX9 handles instancing quite well.

2. Streaming:

a) all the data needs to be pulled from the HDD and send for processing. ArmA has an issue here, since very few of the data is buffered via RAM on one hand, and on the other hand the said data for ArmA is pretty fucking big, and that is without any sort of addons. (yes, size does matter here).

b) since the current data streaming tech for A3 is simply an enhanced OFP one, back in the day when the CPUs were all single core, the ram memory size was a lot lower 256-512mb back in 2001 (unable to correctly act as a buffer for the data), and the simple fact that the entire's game dataset was a lot smaller, it was all pretty much streamed continuous from the HDD.

The HDDs back then was very very similar in terms of performance with the current mechanical drives of today, at least from the performance POV. Remember that HDD is the single PC component (i am excluding SSDs on purpose) where the advancements were mainly in capacity size and stability, and NOT read/write performance, especially when comparing with all the other advancements ranging from CPU to GPu and anything inbetween.

I hope the above would shed some light on the way RV handles data, as well as the "mysteries" and dark side of sections.

WOW! Pufu!

AWESOME, and SUPER informative points. I had some basic understanding of much of what you said, but certainly not enough to properly summarize it, so I avoided the technical details all together as much as possible. THANK YOU for the detailed reply! I will modify incorporate your comments into the narrated video version, and edit out the inaccuracies in my original post!

Thanks so much for the insight! I will certainly do more research based on your comments.

Part of my mis-understanding (I believe) is due to how the textures are applied to faces in O2. In several cases there were syntax variations such as "CA\data\default.rvmat" i/o "ca\data\default.rvmat" which at least in O2, results in an increased section count for that resolution lod in the bottom left. Once you normalize the names the section count drops drastically.

There is no doubt my approach is HORRIBLE... the original name for the modelling tutorials was going to be "A copy and paster's guide to modelling buildings in o2"

But, I did say "people I know who went to school FOR modelling" not went to modelling school ;-P

I actually did take a course in AutoCad in College in the 90's... but that was a Loooooong time ago... and was not geared towards anything other than industrial design schematics.

Edited September 20, 2014 by CiforDayZServer

[m1lkm8n 411]

One correction. The section count in the bottom left is indeed for the lod not the entire model. Unless I'm misunderstanding the portion you are talking about pufu

[PuFu 4600]

cheers for the heads up. Re-reading sound like it, which would obviously be false. Don't worry, it is a leftover from a few edits and rephrases, it was part of the previous sentence.

---------- Post added at 01:48 ---------- Previous post was at 01:37 ----------

WOW! Pufu!

AWESOME, and SUPER informative points. I had some basic understanding of much of what you said, but certainly not enough to properly summarize it, so I avoided the technical details all together as much as possible. THANK YOU for the detailed reply! I will modify incorporate your comments into the narrated video version, and edit out the inaccuracies in my original post!

Thanks so much for the insight! I will certainly do more research based on your comments.

No worries, hope it helps to understand what and why one needs to do rather than just take some steps mechanical.

Part of my mis-understanding (I believe) is due to how the textures are applied to faces in O2. In several cases there were syntax variations such as "CA\data\default.rvmat" i/o "ca\data\default.rvmat" which at least in O2, results in an increased section count for that resolution lod in the bottom left. Once you normalize the names the section count drops drastically.

Yeah, because for some reason things are read as case sensitive, which is not really the case (i haven't really tested it myself). But i really am less interested into helping people port content, but rather create new and optimized ones.

There is no doubt my approach is HORRIBLE... the original name for the modelling tutorials was going to be "A copy and paster's guide to modelling buildings in o2"

Not what i wanted to say, but rather that i find it important to know how certain things work (you don't need to know it in intimate detail though) in order to understand what and where things can be improved. There are no 2 projects alike, especially for the ones that want to push a bit he envelope, but are frustrated by certain unknown limitations.

But, I did say "people I know who went to school FOR modelling" not went to modelling school ;-P

in that case, my bad.

I actually did take a course in AutoCad in College in the 90's... but that was a Loooooong time ago... and was not geared towards anything other than industrial design schematics.

Autocad is not a modeling software really, or not in the sense of what i was trying to put down here. The above is aimed for real time engine (game engine) rather than archViz, BIM and/or Product / industrial design. Yes, i actually use ACAD for part of my commercial work.

[cifordayzserver 119]

So, just to put some final numbers out there, I did an excel spreadsheet and tracked the number of Sections for the 1st LOD of Each model in our package. I repeated the steps for every LOD and got equally drastic reductions in section count displayed in the lower left of O2.

Grand total of our package prior to the reduction was 2,217 sections for ALL the models (near 100)... After going through the outlined process the total package as 816 sections in the 1st lods...

That's 1,401 sections removed from the package.

I really wish there was some sort of test or something to quantify the effect or if there is one.

I'd love to hear from anyone at BI if then know if these numbers are artificially inflated in O2, or if they represent actual figures after binarization.

I still need to re-read pufu's post a few more times, and do some fresh research based on those lessons.

But I feel like a reduction like that HAS to be a significant enough saving to justify the effort... but I honestly don't know.... It was NOT a fun thing to do.