PMC Editing Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== OFP Addon Optimization Guide ======

[[https://www.pmctactical.org/forum/viewforum.php?f=43|OFP Forum]], [[:ofp|OFP Home]], [[ofp:file_formats|OFP File Formats]], [[ofp:tools|OFP Tools]], [[ofp:missions|OFP Missions]], [[ofp:modeling|OFP 3D Modeling]], [[ofp:terrain|OFP Terrain]]

**Operation Flashpoint (OFP)** aka ArmA: Cold War Assault (CWA)

**OFP Addon Optimization Guide** by nephilim.

March 8th, 2006.

So what is optimizations about?

Basically there´s several factors to be aware of before starting with a 3d game model.

  - For what kind of game am i making the model (in our case its OFP)
  - What can the games engine deal with?
  - Do i want only a good looking model or a well performing one?
  - What kind of model shall it be? (Protagonist, etc etc)
  - How much polygons do i roughly need to create that model?

This is important to keep in mind in order to create a well performing game model.


====== I. Preparation ======

The very first thing to do before starting to model is to gather as much information about the object we want to make.
This includes: Blueprints, Pictures, video etc etc.

This gathering of reference has the benefit that we will know much about the model and its shape. Look intensively at the references and try to make up the shape in your mind to be clear how it looks like so you don't mess it in the actual modeling process.

In my case the research actually takes longer then the modeling process itself.


====== II. Modeling Process ======

We proceed with creating a basic shape of the model. In case we are creating for eg a plane we follow the blueprints and its cross sections.

When modeling its very important to use as much quads (4-vertices-polygons) instead of tris (3-point-polygons). Although this is not avoidable sometimes. Also the quad polys will make the mesh more clear and well shaped.

Other rules to memorize are following:

  - Delete unused or not visible faces
  - Small things eg aerials can be made from simple 3 segment pipes or even simple alpha channel planes instead of using 12 segment ones (But this has to be set to relation to the objects size), (This basically means: the bigger the actually object is the more segments it must have in order to look round and vice verse).
  - Use planes instead of actually "plastic" objects to create small aereals or grids for example.
  - A lot of details can be achieved with textures.

After we've done the model we going to run some optimizing sequences withing oxygen.

For this select the model with CTRL-A and under "Structure" select optimize.

The mesh optimization will start now.

Depending on the complexity of the model it may take several minutes.

What the Optimization does is pretty simple.

  * It squares planes that are even but are triangled.
  * Merges snapped vertices or very close vertices.
  * Deletes unused faces.

If you run a prior made model that has not been optimized before it will loose several unnecessary faces.

Another thing is that people often have non-planar faces. These are quads with one single vertices moved off the polygons planar surface.

These actually don't do any harm but they influence the model lightning is a bad way because oxygen/OFP doesn't know how to render the light on that face.

To avoid this we use Structure -> Triangulate \ or Triangulate /. These options triangulate the selected faces in different directions.

After we've triangulated the mesh we again use Structure -> Optimize or Structure -> Squarize.

The resulting mesh might look slightly different from the prior made one as the polygon flow might have changed due the triangulation/optimization process but the textures and UV's are not harmed so don't worry.


====== III. LODs ======

LOD's are essential in any game and are the most important thing in OFP. LOD's have a strong relation to the current CPU load, the current fps and the calculated distances.

Briefly.

The assigned LOD values do not necessarily need to pop up at the setup distance value. They are as well influence by how much units are on the map etc etc.

Eg if only one object is on the map the next lod will pop up at a later time as when the map is crowded with objects.

Also there is no need for excessive lod amounts like using 24 resolution LOD's, 3-5 well made LOD's totally fit any model.

As well as that its not necessary to "calculate" LOD values with programs...

A good rule is that if you have a very detailed model in the very first lod, to set the next lod in order to a value so that the ofp engines switches to it a quickly as possible.

Here is a little chart for several types of models (arma/vbs1 standards)

UH60 (VBS1/ArmA)
^ Poly count ^ Resolution LOD - Value ^
| ~7290 | 0.750 |
| ~5792 | 1.500 |
| ~2327 | 3.000 |
| ~1140 | 6.000 |
| ~535 | 14.000 |
| ~259 | 16.000 |

Unit (VBS1/ArmA)
^ Poly count ^ Resolution LOD - Value ^
| ~4369 | 0.150 |
| ~1850 | 1.000 |
| ~331 | 3.000 |
| ~101 | 5.202 |

M4 (VBS1/ArmA)
^ Poly count ^ Resolution LOD - Value ^
| ~1845 | 0.350 |
| ~1430 | 1.000 |
| ~18 | 1.915 |

That's the standards of ArmA and VBS1 at the moment.

The models that are made by 3rd party users should be settled around these values.

What people also tend to misunderstand that the poly count is calculated per LOD not of all LOD´s together. OFP/vbs1 doesn't calculate the model at whole, if so it would have to display each lod at the same time which obviously isn't the fact.

Furthermore extra low-res textures should be used starting from the 3rd or 4th LOD to en-light the CPU drain. At these distances you cant make out any details anyway and models only appear as tiny pixels on the screen.

A common mistake is that people think that the actual poly count isn't important but the vertices... That's wrong!

Why? Well I tell you why.

Textures are applied on polygons not on vertices. Light and reflections are calculated on polygons not vertices
and that's only a few to name.

You can try that yourself.

Create a crude object containing 32K polygons save it as test1.p3d, now select the object and delete all polygons by pressing "D" and save it as test2.p3d.

stuff it in a pbo and test it in-game...

I kick every ones butt that says its not true that hard so he cant sit on his four letters for the next 2 years... Its simply a idiotic rumor...


====== IV. Mapping the Object ======

Mapping is something that is pretty bitchy in oxygen for most people. But this is the part where you can improve the CPU friendliness of your model enormously!

There are several techniques to map, the easiest is the UV mapping, but unfortunately Oxygen doesn't support UV mapping like in advanced programs like maya or 3ds max.

However if you do own such a program I recommend to map it in this program and then port it into oxygen.

You can UV map objects in another way. Manually unwrap the mesh by splitting off parts of the model Structure -> Topology -> Split and rotate them so that they fit within the oxygen grid.

Make a screens shot of that "laid out" mesh and paste it in any painting program.

After you converted the texture to reasonable format apply the texture via planar mapping onto the unwrapped model. After you've applied it you manually need to wrap the mesh back.

This process is extensive but the results have enormous advantages towards the "sloppy" mapped objects.


====== V. Textures ======

A basic rule: The less textures the better!

Means: Use one larger texture (for example for equipment such as pouches etc.. with a 1024x1024 size) instead of 6 or more same sized to map objects like grenade pouches, com, holster separately.

Stuff as many objects on one texture as possible.

Keep the texture count and the size as low as possible but reasonable.

Bear in mind that one 2048x2048 is over 2mb large! An optimized and binarized addon is only 1mb to 600kb large! Quite a chunk aren't they?

OFP and even ArmA or VBS1 will take a lot more time to load these textures in comparison to smaller textures.

Another thing is that if you keep the textures reasonable you can invest a lot more in polygons. Means if you only use about 5 textures for a m1a1 it easily can have 6000 or more polygons. Same goes for any other models in relations to their size/appearance quantity (a Beretta doesn't need to have 4k polygons).


====== VI. Binarizing ======

A lot of people connect binarizing with locking down addons. Although binarize will make the p3d not readable for oxygen it reduces the p3d file size a lot which accordingly reduces loading time in ofp and increases FPS.

Eg an 1.4mb large p3d will be only about 600kb after binarization, which is quite a bit when you have a lot of models.

As well its more user friendly because the pbo file size is reduced and accordingly the download time (for the sake of all 56k users).


====== VII. Scripts ======

I'm not scripting expert so anyone can give the input here.

Basically to be handled like textures- the less the better.


====== VIII. PBO's ======

There are several PBO programs that have several options to deal with. New PBO programs have the possibility to "compress" the PBO archive.

Although its a good intention, bad because OFP/VBS1/ArmA take a lot of more time to unpack these PBO's and load the models... Further more it might increase lag as well depending on the model and texture size and file size.

Not convinced? stuff a pbo a and look on a watch... there is a big difference.

Another thing is to split up PBO´s in several archives to ease updating. Means that you use a separate PBO for the config/scripts textures and models.

Eg BLAC.PBO >cfg and scripts\\
BLA.PBO >textures\\
BLAM.PBO >models\\

Also keep the PBO names brief! Things like FHG_M4_SOPMOD_PACK_V12.PBO is idiotic...

a good example would be FHGM4.PBO

Same goes for textures

Stuff like F14_right_fuselage_VFH12.pac is bad F14_1.pac is better.

Here are some pictures of a well balanced and scratchmade model i made for VBS1. (Aussie SASR)

{{ http://img372.imageshack.us/img372/7696/sasr23aq.th.jpg }}

[[http://img372.imageshack.us/img372/1487/sasr34ab.jpg|image 1]], [[http://img372.imageshack.us/img372/774/sasr45ce.jpg|image 2]].

5122 polygons in first LOD, 11 Textures (ranging from 256x512 - 1024x1024).

Optimized and binarized.

Texture list:

top.paa 1024x1024\\
arms.paa 1024x1024 (both arms on texture canvas)\\
legs.paa 1024x1024\\
load1.paa 1024x1024 (all the equipments like pouches, com etc)\\
sfgear1.paa 1024x1024 (6004 holster etc- texture contains more than only the holster )\\
char1.paa 1024x512 (face and hands)\\
lowa_boot.paa 512x512\\
shemaghtop.paa 1024x1024\\
shemaghbot.paa 512x512 (2 seperate models/textures as the bottom part is used sepetelly on other models and was already uv mapped)\\
ESSgogBK.paa 1024x512\\
ESSglBk.paa 256x512 (used to xchange visiors more easily)

It runs hell of a good even if have 4 squads of these guys on the map at the same time... Its not entirely finished yet so there is some things i can improve.

The textures are not blurry but there is a lot of dirt and dust on them, SASR operators are just really dirty after long action.

OK that's about it.

I have covered this topic very briefly as it would take several more pages to do that entirely. After all everyone needs to make his own experiences.

In general you need to find a balance of these points to create a good addon.

Cheers.