Addon Optimization

[nephilim 0]

Addon Optimization guide

by Nephilim  

March 8th 2006

im writing this cuz people were constantly consulting (rather nagging) me about that topic

So wots optimizations about?

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

1. For what kind of game am i making the model (in our case its ofp :P)

2. What can the games engine deal with?

3. Do i want only a good looking model or a well performing one?

4. What kind of model shall it be? (Protagonist, etc etc)

5. 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

Ok coming to some more "practical" things

I. Preparation

Ther 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 refernces and try to make up the shape in your mind to be clear

how it looks like so you dont mess it in the actual modelling process

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

II.Modeling Process

Ok 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 crossections.

When modelling its very important to use as much quads (4-vertices-polygons)

instead of tris (3-point-polygons).

Altough this is not avoidable sometimes.

Also the quad polys will make the mesh more clear and well shaped.

Other rules to memorize are folowing:

1. Delete unused or not visible faces

2. Small things eg aerials can be made from simple 3 segment pipes or even simple alpha channel planes instead of using 12 seg ones

  But this has to be set to relation to the objects size

  This basically means: the bigger the actualy object is the more segments it must have in order to look round and vice versa

3. Use planes instead of actualy "plastic" objects to create small aereals or grids for example

4. Alot of details can be achieved with textures

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

For this selec 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 squarizes planes that are even but are triangled.

-merges snaped 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 unneccesary 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 dont do any harm but they influence the model ligthning is a bad way because

oxygen/opf doesnt 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 diffrent directions.

After we´ve triangulated the mesh we again use "structure">"optimize" or "structure">"squarize"

The resulting mesh might look slightly diffrent 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 dont worry.

III. Lods

Lods are essential in any game and are the most important thing in ofp.

Lods 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 aswell 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 croweded with objects.

Also there is no need for excessive lod amounts like using 24 resolution lods

3-5 well made lods totally fit any model.

Aswell as that its not necessary to "calculate" lod valuses 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.

Heres a little chart for several types of models (arma/vbs1 standarts)

uh60 (vbs1/arma)

Polycount Resoution-Lod-Value

~7290 0.750

~5792 1.500

~2327 3.000

~1140 6.000

~535 14.000

~259 16.000

Unit (vbs1/arma)

~4369 0.150

~1850 1.000

~331 3.000

~101 5.202

M4 (vbs1/arma)

~1845 0.350

~1430 1.000

~18 1.915

Thats the standarts of arma and vbs1 atm.

The models that are made by 3rd party users shoudl be setteld around these values.

What people also tend to missundertand that the poly count is calculated per LOD not of all LOD´s together.

OFP/vbs1 doenst calculate the model at whole, if so it would have to display each lod at the same time which obviously isnt the fact.

Furthermore extra low-res textures should be used starting from the 3rd or 4th lod to enlight 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 isnt important but the vertices..

Thats BULLSHIT!

Why? lol i tell you why.

Textures are applied on polygons not on vertices

Light and relfections are calculated on polygons not vertices

and thats 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 ingame...

I kick everyones 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 rumour...

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 yoru model enourmously!

There are several techiques to map ,the easiest is the uv mapping, but unfortunatelly Oxygen doesnt support uv mapping like in advanced programms

like maya or max.

However if you do own such a program i recomend 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">"topolgy">"split"

and rotat them so that they fit within the oxygen grid.

make a screens shot of that "layed out" mesh and paste it in any painting programm.

After you converted the texture to resonable format apply the texture via planar mapping onto the unwrapped model.

After youve applied it you manually need to wrap the mesh back.

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

Next Step are the textures

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 seperatelly.

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 binerized addon is only 1mb to 600 kb big!

Quite a chunker arent they?

Ofp and even ARMA or VBS1 will take a lot more time to load these textures in comparison to smaler textures.

Another thing is that if you keep the textures reasonable you can invest alot 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 realtions to their size/appearance quantity (a beratta doesnt need to have 4k polygons)

VI. Binerizing

Alot of people connect binerizing with lockin down addons.

Altough binerize will make the p3d not readable for oxygen it reduces the p3d file size alot which accordingly

reduces loading time in ofp and increases fps.

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

Aswell its more userfriendly cuz the pbo file size is reduced and accordingly the download time (for the sake of all 56k users :P)

VII. Scripts

Im 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 programms that have several options to deal with.

New PBO programms have the possibility to "compress" the PBO archieve.

Altough its a good intention, bad because OFP/VBS1/ARMA take alot of more time to unpack these PBO´s

and load the models..

Further more it might increase lag aswell depending on the model and texture size and file size.

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

Another thing is to split up PBO´s in several archives to ease updating.

Means that you use a seperate 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/1487/sasr34ab.jpg

http://img372.imageshack.us/img372/774/sasr45ce.jpg

5122 polygons in first lod

11 Textures (ranging from 256x512 - 1024x1024)

optimzed and binerized

tex 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 theres some things i can improve

Oh and te textures are not blurry but theres a lot of dirt and dust on them

SASR operators are just really dirty after looooooong action and smell as hell aswell

To bad you can simulate that in ofp XD

Ok thats about it.

I have coverd this topic very briefly as it would take several more pages to do that entirely.

After all everyone needs to make his own expences:P

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

Cheers

[W0lle 1047]

A really comprehensive guide and definitely worth reading (and saving) it.

Thanks

[deanosbeano 0]

very nice tutorial/guide ty.

i do like the way your soldiers are proportioned, (allthough overall very thin). but unlike most yours have shoulders that look correct,others seem to narrrow to much.

oh and to add something heres world camo site

world camo

[God of Death 0]

I love this

I know you gave me some tips before but this is really great.

Well done Nephilim

- Rick

[nephilim 0]

most soldiers arent mister universe.. with a 60 cm diameter bicpes...

about the camo

the auscam is the desert version that has been used in the iraq theatre..

it is correct

[deanosbeano 0]

oops ,wasnt critisising ,just they would look thin in my co op against other units . variety is the spice of life , they say. and the camo was for other users as you can see , it says in the link i put that the aus camo was used in iraq and afghanistan so i already was aware :P . fills etc.

anyway ty for tute

[nephilim 0]

no prob wasnt anything harsh from my side

[Student Pilot 0]

Nice tutorial, thank you. If I ever get around to finishing my project I will be sure to incorporate some of your suggestions. (Like the optimize command, didn't know what that did)

-Pilot

[Messiah 2]

any insight to 'non linear mapping' and what it is, and how to remove it?

[nephilim 0]

non-planar polygons are basically quads

of which one vertices is pulled upwards or downwards so that the planaraty is gone.

in other progs like max maya etc this doest matter

but in pxygen/ofp it does

cuz the engine doesnt know how to calculate the light on that surface or it doesnt like you want it to be

basically jsut triangulate the polygon with structure / or \

or flatten the polygon witj the folowing techique

select the face to which the other ther should be flattened to

lock the pin onto that face

press the look on polygon button

now select the otehr polygon you want to flatten

but leave the pin locked onthe other polygon

now simply flatten it py press ing P (i think)

hope that helps a bit

[vektorboson 8]

Overall a good article,

I'm gonna make the usual nitpicking

Furthermore extra low-res textures should be used starting from the 3rd or 4th lod to enlight the CPU drain.

At these distances you cant make out any details anyway and models only appear as  tiny pixels on the screen.

That's basically what mipmaps are for; the graphics driver chooses a mipmap according to the triangle's onscreen size and thus uploads only a 16x16 texture instead of 1024x1024.

Extra textures would increase the memory footprint unnecessarily.

Quote[/b] ]Light and relfections are calculated on polygons not vertices

For OFP (and I guess VBS) this is not true. Light is applied to vertices.

For ArmA it should be as you say.

Quote[/b] ]

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 ingame...

I think that this is a very bad comparison, as the second one probably won't be transformed at all; if there are no polys to

draw, there are no vertices to send to the graphics-card.

Regarding the Vertices-versus-Polygons-argument: One should use as few vertices as possible anyway.

Let's look at soldiers: Their vertices not only have to be transformed for their position, but the head direction and the animations have to be applied, too.

Animations are applied to vertices, and therefore there are a lot of calculations to be done.

If one opens a BIS human model, one'll see that they have much much more Faces than Vertices.

Quote[/b] ]

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

a good example would be FHGM4.PBO

I think that descriptive filenames are better, especially if you have a lot of addons installed.

The PBO-names have to be kept brief because of the MLOD restriction on texture paths.

Best would be some kind of information in the PBO that could be extracted by a tool and tell the user what kind of addon it includes and what it requires.

Some question: Is this official information from the Devs, or is it self-learned?

Anyway, good article!

[vektorboson 8]

any insight to 'non linear mapping' and what it is, and how to remove it?

@Nephilim

He asked about non-linear mapping

@Messiah

It means that the UV-cordinates are f**ked up.

Example:

Create a plane and texturize it; then take one vertex of this plane and move it somewhere. Check-faces gives you non-linear mapping.

One possibility is to make two triangles out of the plane, another is to retexture the plane.

[BenceRAP 0]

Thanks a lot for everyone in the OFP community. I see you are a talented addon maker. Good job out there.

[sniping-jack 0]

Quote[/b] ]Another thing is that if you keep the textures reasonable you can invest alot more in polygons.

Means if you only use about 5 textures for a m1a1 it easily can have 6000 or more polygons.

That sentence is pritty critical because many people could missunderstand this.

Afaik you can't weight the texture sizes against the polycount.

These are two different things you have to handle separately in any case.

For each one you should say:

As much as necessary and as less as possible.

One further word to the tools of OË›:

You said to use the "optimise" button during the very early progress.

I can't recommend this for beginners! Why?

Well, everyone should try to modeling first "by hand" without this tool to get the right "feeling" to create models with moderate polycount.

Personally I use this button just as a control and in very most cases OË› can't find anything to "optimize".

In my opinion its a good way to get familiar with the best way of creating well balanced and efficient modells.

Some remarks to the LODs of funktionallity like geometric, view and fire:

Don't forget to check the LODs for non-closed faces and non-convexities! Check it twice!

Keep always in mind that overdosed LODs like above will drop performance dramatically if many units are around these models.

The KI don't look at textured models like the player does. They are allways "looking" at the non-visibel models! The more faces (components) the models have into the funktion-LODs the more calculations have to be done by OFP (CPU).

Many addonmakers don't keep enough attention to these parts of modelling. But it's a very important thing to get really best models into OFP. There's no need to overdose these LODs because in most cases nobody will notice a difference against moderate created ones - but the CPU does!

Well, I better stop now...

At least I just wanna say: It's a very good article!  

[ag_smith 0]

Furthermore extra low-res textures should be used starting from the 3rd or 4th lod to enlight the CPU drain.

At these distances you cant make out any details anyway and models only appear as tiny pixels on the screen.

That's basically what mipmaps are for; the graphics driver chooses a mipmap according to the triangle's onscreen size and thus uploads only a 16x16 texture instead of 1024x1024.

Extra textures would increase the memory footprint unnecessarily.

... and here I was, thinking that we've busted this myth forever.

Vektorboson is absolutely right on this one. OFP textures have precalculated mipmaps for this reason. There's really no reason for using low-res textures.

Just to quote Offtime: (source)

hmmm

1. checking some of my addons...

2. i found 1024x1024 pac texture - 682kb

3. im resizing it to 512x512 and 256x256

4. 512x512 - 179kb

5. 256x256 - 42kb

texturing lods with lower resolution textures will use in total 849kb of memory instead of 682kb with one main hi-res texture

6. comparing mipmaps

a) oryginal 1024 and first mipmap 1024

b) oryginal 512 (zoomed to fit 1024) and first mipmap of 1024 texture

wheres the point in texturing lods with lower resolution textures instead of depending on pac mipmamps ?

[DaSquade 0]

Good read jenny...but i mis the vertex-face (anti-)deformation guide for units though.

I don't want to step on your feets jenny, but i indeed also believe the mipmap option of textures are better then using lower res textures on lowest lods (like said...why would there be mipmap options availible). Although i used your principle in one of my (pending) addons, i still think mipmap is more optimized then multi-texture use.

My humble input regarding the optimize option:

Although the o2 (structure) 'optimize' option is very good. As said, good as double check for not-merged vertexes and double faces (that are not mirrored....afaik). But like i said somewhere else, the optimize option also have some bad actions on models sometimes. Meaning, the fact it can screw up 'correct' lightning values!

Example that i'm aware of (and is a eyeblowing effect imho):

Make a tube (and give it correct lighting values = select the end faces and give them the sharp lightning value)....delete the ends (cap faces). As we tend to make 'low' poly models, we normally decide to not give it a thickness, so we just copy/past the tube and invert the pasted tube to have an inner tube (keep one eye on bulldozer and lightning values). Hit the F5. Now run optimize, and see the light values change, as it merges the ends of tube (inner and out). Not sure if my above example methode was correct (out of head...but afaik it goes this way).

SO, just want to say the optimize option in some cases (it merges non-connected point and recalculates lightning values..in a wrong way imho).

So, keep in mind it can have negative influence on some methodes of modellling....and sometimes it is better to make your 'inner stuff' after the optimize option.

Just my 2 cent

[vektorboson 8]

Example that i'm aware of (and is a eyeblowing effect imho):

Make a tube (and give it correct lighting values = select the end faces and give them the sharp lightning value)....delete the ends (cap faces). As we tend to make 'low' poly models, we normally decide to not give it a thickness, so we just copy/past the tube and invert the pasted tube to have an inner tube (keep one eye on bulldozer and lightning values). Hit the F5. Now run optimize, and see the light values change, as it merges the ends of tube (inner and out). Not sure if my above example methode was correct (out of head...but afaik it goes this way).

Well, for this you have to select the affected faces, hit 'E' for Face Properties and select for Lighting 'Both Sides'.

[dm 9]

An interesting read...

Most of the critical points (poly Vs. vertex, multi textures etc) have already been covered.

To throw in my $0.02

90% of the work is done on the vertex (I should know, I've been programming GFX code for uni for the last 3 months)

Translations (thats EVERYTHING, where ever the model moves, where ever it turns, tips etc etc)

Lighting

Transformations (all the animations, rotations etc)

Culling (to an extent, the majority of out-of-view culling is done on verticies)

Textures - yes, surprisingly enough, the textures are actually applied to the verticies. The key UV information is stored in the verticies, the texture is then applied during rendering using polar coordinates between the veticies which make up the poly.

As for your recommended poly counts, yes I could agree on those, but I cant see how you can make statements about the ArmA standards when no-one outside of BIS knows what they are yet. Best to stick with what you know when making such statements

Texture suggestions on the whole are good, but like others have suggested, the low-res versions are not needed.

As for Binerization, its not the filesize that counts. Once Binerized the model is of the more advanced ODOL format. This format has advantages over MLOD (the editable in O2 version) including the way the engine handles the model, it allows for quicker parsing to the engine, and generally more economical memory use.

Binarizing also codes information about the models properties into the model, such as alpha levels, named selections etc.

As for PBO's, I agree whole-heartedly. Before V1.92 and the -nomap command, people were suggesting compressing PBO's to prevent the out of memory errors. That was a load of bull, as you correctly point out, compressing the PBO simply means that the engine then has to decompress it before using it. This leads to slower load times and less reliable handling.

think thats about it...

[Messiah 2]

any insight to 'non linear mapping' and what it is, and how to remove it?

@Nephilim

He asked about non-linear mapping

@Messiah

It means that the UV-cordinates are f**ked up.

Example:

Create a plane and texturize it; then take one vertex of this plane and move it somewhere. Check-faces gives you non-linear mapping.

One possibility is to make two triangles out of the plane, another is to retexture the plane.

cheers mate, the texture looks fine in O2 and bulldozer and ingame, so if i were to leave it, there shouldnt be any horrible side effects?

as for pbo size, compression or no compression - myself, vektorbosen and a few others had an interesting discussion about it on the oxygen forums, stating posisble pro's and cons of either way - cant find a link, but a quick search should find it - was full of lots of uselful info.

[Messiah 2]

that optimize tool is great, never realised it before now, it fixed by odol -> mlod wheels that had become 6x as many vertexes than they should have been...

the only problem (and it was my own stupid fault) was that it merged my doors into the main model but easy enough to fix

[vektorboson 8]

90% of the work is done on the vertex (I should know, I've been programming GFX code for uni for the last 3 months)

Translations (thats EVERYTHING, where ever the model moves, where ever it turns, tips etc etc)

The usual nitpicking

Translation is only movement, but not turning, and translations are transformations. (no matter if you rotate or translate, in the end it's all multiplying matrices).

Quote[/b] ]

Lighting

Depends on how you implement lighting. You can do per-Vertex-lighting, but you can also do per-pixel/per-fragment lighting. In OFP it's per-vertex-lighting (but for the light cones of vehicles it's probably per-pixel).

Quote[/b] ]

Culling (to an extent, the majority of out-of-view culling is done on verticies)

I hope that the majority of culling is not done on vertices! Best is to do culling on tree nodes, then frustum culling on bounding box/geometry, then bounding box occlusion (draw the bounding box and check if any pixel was drawn) and only then on vertices (backface culling!.

Quote[/b] ]

Textures - yes, surprisingly enough, the textures are actually applied to the verticies. The key UV information is stored in the verticies, the texture is then applied during rendering using polar coordinates between the veticies which make up the poly.

Polar coordinates? I hope that I didn't miss anything!

Perhaps you mean texture coordinate generation, where it is indeed possible to create spherical coordinates, which are transformed into rectangular coordinates.

As much as the UV-information (and normals) is passed to vertices, the texturing is done on pixels/fragments.

Very easy example: You have a face that is 1 sq meters and you have a face that is 100 sq meters in size. Both are at the same distance from the camera, which one is drawn faster?

It's not all about vertices, graphic cards do a very good job at transforming vertices (such a good job, that people try to use GPUs as coprocessors). But still, there is the pixel fill rate that is often the bottle neck.

[ebud 18]

Could one of you brainiacs explain in-depth the lod rendering? Why is it that I can have say 4 models, all roughly the same poly count, the same lod numbering, yet some switch lods quite differently.

Also is it "best" to let O2 do the lod numbering? Or if I number the lods myself what really is the best option?

Say I have these numbers for my lods for ALL the models say on a map

.5

2.5

5

7

9

Now, how exactly does the engine force the lod switching? Or what I really want to know is how can I try to force the issue by numbering lods myself with either higher or lower numbers?

I've been using O2 for several years almost daily, and I really just try to follow what's already been done by BIS, but I still can't wrap my head around the details about how the numbers actually affect the switching, and at what distance/poly load they switch.

[Student Pilot 0]

Quote[/b] ]the only problem (and it was my own stupid fault) was that it merged my doors into the main model

If I run the optomize command on a plane, will it merge the flaps, ailerones, and elevators into the main model?

-Pilot

[Messiah 2]

if you select the whole model, then yes...

i selected my whole model, and because the vertexes of the doors are obviously very close/on top of the veretexes of the door frame, optimization decided to merge them - creating a bit of a fuck up.

i think to be on the safe side, select your whole model, and then unselect the airlerons etc one by one

[Student Pilot 0]

Ok, thanks for that

-Pilot