Addon Optimization

[Flashpoint_K 0]

Interesting discussion. And nice guide.

I also think it is better not to use low-res textures in the last lods of a model except the case you can save faces this way. For example by using textures with alpha channel.

Also considering texturing. Can someone explain the gizmo-mapping function of o2 or is there already a tutorial about this topic?

When numbering the lods, it is also important how big an object is. When binarizing a model, binarize automaticaly calculates a number and gives this number to all lods which have bigger numbers than this one.

So very big objects can have very big lod numbers and this makes sence when you think about how long you can see these objects on your screen.

Details on small objects disapear very fast in ofp because they are simply to small to render (because of the pixels), such models can switch their lods quite fast, so the lod numbers should be smaller.

[sniping-jack 0]

Gizmo-Mapping:

Well...I'll try to explane the basics.

It's like a projector which will project textures onto a hull of faces.

There are existing two basic modes: cylindric and spherical.

Both are selfexplaining on what they depending to.

After pressing "g" you have to load a texture you want to wrap arond the model. Then you select the kind of projection method. In the main windows you will see now a tri-colored cross. You can manipulate this cross like any other object in OË›. The direction and position changes the so called projector and the size will change the projected size (cylindric method)of the texture.

Let's asume you want to wrap a stony texture around a sphere. Create a sphere and select it.

In this case you should choose to select "spherical (one sign)" to get the right result. This means that the projector will looks only into one direction - in other case he will project bidirectional.

Now you can change the size of the blue area that covers your texture preview in the gizmo window. A smaler area will project only a part of the texture and a bigger size will leads to tiling. To judge the results press the "preview" button.

As you can easily see it's much more faster and in most cases more precise like the usual UV-method.

It takes a little bit time of experiments to get familiar with the gizmo tool and sometimes you just wanna bite into your keyboard. But though I think it's worth to test it.

---------

[Romolus 0]

...It runs hell of a good even if have 4 squads of these guys on the map at the same time...

Take 4 squads of different units that use the same ammount of different high resolution textures together with a few vehicles that also use a huge ammount of high resolution textures on an island that has high resolution ground textures and objects that use many high resolution textures with a config that uses high resolution replacements for dust, smoke, fire and sky and then tell me how well OFP runs then.

Many people forget the big pictue when they're working on a single addon and testing it on desert island.

If everyone keeps pushing the performance limits on their own small addons then things get messy pretty fast when everything is put together.

[zyklone 1]

Thanks for this.

To the addon makers i can only say: LODs! LODs! LODs!

They make us CTI players actually able to use your nice addons.

[sniping-jack 0]

...It runs hell of a good even if have 4 squads of these guys on the map at the same time...

Take 4 squads of different units  that use the same ammount of different high resolution textures together with a few vehicles that also use a huge ammount of high resolution textures on an island that has high resolution ground textures and objects that use many high resolution textures with a config that uses high resolution replacements for dust, smoke, fire and sky and then tell me how well OFP runs then.

Many people forget the big pictue when they're working on a single addon and testing it on desert island.

If everyone keeps pushing the performance limits on their own small addons then things get messy pretty fast when everything is put together.

That's really one of the biggest problem with many addonmakers. Highpoly models with huge textures without any LOD. That will run on dessert island though but never into a rich environment.  

[dm 9]

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)

Touché

I originally had Translations/Transformations in one list, but separated them out to look longer, serves me right I suppose.

Quote[/b] ]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!.

Yup, got confused on that one too, havent really been programming the culling in too much depth yet, so put that down to inexperience

Quote[/b] ]Polar coordinates? .... .....

Ooops, probably should pay more attention in lectures. We were looking at the coordinate interpolation, so i guess the pol stuck somewhere. More sleep would probably help there I guess...

I agree with you on the pixel fill rate being the bottleneck, but was trying to make the point that the majority of the math is done on the vertecies, which is why vertex count IS important.

[BraTTy 0]

Interesting topic and it woke up talented modellers

Very nice tips

Only tip I can add coming from a amateur as myself would be to add a exempt to the "using different textures on your other lods" is the fact that you could for example remove a 300 poly wheel and replace it with a very low poly and maybe even a box and would require you to make a different texture to make it look more like a wheel, which was already said

K some of my questions related to optimization.

Back to an old asked question.... do you think a larger single texture has better performance than several smaller textures?

(you would think the smaller textures would perform better because they may be applied on parts that hide,but the engine has to load all the textures anyways)

Gizmo mapped textures have better performance than planar mapped textures?

Poorly lighted addons cause performace impact?

The number of named selections?

Maybe I skimmed this topic too quick ,possibly already answered

[nephilim 0]

about well basically its like that

you can sum up the amount of textures and compare them to the filesize of of one single big texture

most of the time the sperate textures are 512*512 for just a gren pouch

if you put that gren pouch on one largeer canvas say 1024*1024 and add all the equipment you need on it

theres definatelly a save in performance

of course youd had to reduce the size of the actual pouch a bit but that doesnt really do harm as you can fix some stuff with photoshop tricks.

as for the gizmo/planar mapped stuff

basically i dont see any diffrences here

though the actuall process of mappin is diffrent

all textures use uv coordinates which are applied planar!

it becomes obvious when you look at uv editors in progs such as maya or max

the lightning doesnt have much impact i think

altough difficult shadows could cause impacts i assume

number of valid selections is about 250 i think

but ive never tried if this has an actual performance impact..

250 tags would be kinda "difficult" to handle

the guide i made just skims this topic its not 100% complete or so

itll take several pages to cover that

but if you got through it youll get the glimpse of wot is good and wot is bad when creatin an addon

[berghoff 11]

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 think when you get a low framerate It switches to a different LOD not sure maybe some distance is needed too.

[ag_smith 0]

I've always assumed that LOD switching is based on calculations involving:

- current framerate

- system performance & LOD values set in the OFP Preferences

- face counts of the current and the next/previous LOD

- object size (size of bounding box)

- distance from player

- LOD 'resolutions' set in O2

Well, at least that's how I would make it if I was to implement such a system. So you can see it ain't exact science. It depends a lot on your current system workload and I think there's no possible way to force the values to switch at certain distances.

What LOD values should be optimal then? I have no idea... I always try to determine that by trial and error method and testing addons on a few different machines. Generally for regular models I would follow BIS model guidelines. For very large objects, though, from my experience you have to set much higher LOD values, ie. 3, 8, 16, 40 (don't ask me, why these particular numbers ).

[llauma 0]

I dont think that the lods are adjusted after your framerate.

The amount of objects and the total poly count rendered matters so it might look as if your framerate matters as those things normally lowers your framerate. If framerate did matter we would see the lower lods in laggy mission but unless the lag is caused by lots of objects and high total poly count the engine wont switch to the lower lods.

[nephilim 0]

your right smith

basically its best to let the engine switch to the next lowest possible lod asap

that doesnt necessarily mean that a setup distance it will switch

its means that IF the cpu load is drained to a certain ammount it will switch

eg

if you set 0.150 as value for the second lod

it will switch to it (when a certain cpu drainiage is reached)

after ~ 1.5 meters (the lod value- distance is still a riddle to me) to it.

but if the cpu drainage is low eg one single unit on des island

it wont switch to the 0.15 lod at once just because of the distance.

there´s a lot of factors to deal with

@ llauma fps does matter to some extend

of course ofp will force the model to stay at its high res lod when at close distances and if the lod values are set up badly

thats why the lag actually happens.

proper lods dont cause lag

[Blackblood 0]

Many people forget the big pictue when they're working on a single addon and testing it on desert island.

If everyone keeps pushing the performance limits on their own small addons then things get messy pretty fast when everything is put together.

Very very true.

Besides that, sitting on a killer-dual core-sLi-rig when performance testing is only satisfactory for the lucky few.

I always use the worst case scenario technique when trying out my work. Bombarding the map with objects and several duplicates of the p3d on trial. My poor AMD 1,33 Ghz w GF3 cries like a newborn but if the result turns out ok it should work for anyone.

Sadly my uk desert shit lacks optimization o2 wise. I learnt the importance of triangulating and proper mapping post BLEED.

[Messiah 2]

Sadly my uk desert shit lacks optimization o2 wise. I learnt the importance of triangulating and proper mapping post BLEED.

not to worry, all will be ok

[JdB 151]

and if the lod values are set up badly

thats why the lag actually happens.

proper lods dont cause lag

Lag is network related. The network itself and all of the nodes it has to travel through (can) cause lag, it has nothing to do with the computer itself.

When your computer is old, or the units badly made you just get a bad FPS, not lag.

[berghoff 11]

Btw, Can one please explain why binarizes sometimes tends to f**kup my models? When I test a tree in MLOD all the geo lods work but after binarizing mostly the viewgeometry doesn't work anymore.

[LizardX 0]

One big texture vs. alot of small ones:

could someone explain the "merge textures" function please? I found a topic but it's like Chinese to me (btw that's a nice language). Isn't it related to the point? Thanks

[nephilim 0]

theres a topic about the merge function in the oxygen thread

search :P

@JdB

hmm strange i never played ofp via network..

so when i have only 5 fps isnt ofp laggy then?

and if i have lagg can my fps be around 60 fps?? not really..

anyways

lets dont argue but offtopic stuff.

if anyone has experience to share please do

[Sniperwolf572 758]

Quote[/b] ]Lag often refers to delays experienced in computing communications, however it may also apply to written or other forms of communication.

Within computing, Lag refers to the time taken for a packet of data to travel between the local computer, the destination and back again.

Whilst in the strictest sense every packet experiences lag, the term lag is implied to refer to noticeable delays to the user caused as a result of extended or unexpected delay. As the time taken for a packet to travel from a server in Italy to a client in Spain is likely to differ from a trip from Italy to Australia, it is possible that two users may experience different lags from the same source.

Anyways, nice guide.

[dm 9]

Lag is network related. The network itself and all of the nodes it has to travel through (can) cause lag, it has nothing to do with the computer itself.

When your computer is old, or the units badly made you just get a bad FPS, not lag.

Indeed, the correct term for it would be "Slowdown"

proper lods dont cause lag

Actually, proper LODs cause LESS slowdown. However, the switching between LODs has been proven to cause its own slowdown. (See Lee H. Oswolds "Better FPS" tute)

Btw, Can one please explain why binarizes sometimes tends to f**kup my models? When I test a tree in MLOD all the geo lods work but after binarizing mostly the viewgeometry doesn't work anymore.

When you binarize a model, it requires that all the necessary LODs are present and correct. The MLOD format has a certain amount of leeway as to the function of the LODs. For example, MLOD will work to an extent with non-convex or open shapes in the geometries, ODOL will not.

As has been mentioned before, in the Geometry LODs, use the check tools in O2, check for non-convexities, check for open faces, and check for non-planar faces. Any of these in any combination will prevent the Geometry from working.

I've also had some experiences where overlapping shapes in the geometry will prevent it from working, but this is not always the case.

Also, the Geometries are limited to 128 (0-127) components each, so more components than that will also break it.

One big texture vs. alot of small ones:

could someone explain the "merge textures" function please? I found a topic but it's like Chinese to me (btw that's a nice language). Isn't it related to the point? Thanks

There is a script that you need to run along with the Merge Textures function, there is a whole thread here which explains how to use them, unfortunately the example project (which makes it super-easy to understand) is long gone.

I'll have a search of my archives and see if I've got it somewhere, as its a damn handy resource to have.

Basically, the tool takes a lot of small textures and tiles them together on one larger one.

[dm 9]

hmm strange i never played ofp via network..

so when i have only 5 fps isnt ofp laggy then?

and if i have lagg can my fps be around 60 fps?? not really..

Sorry for the double post.

To quote the Owls "Ya, rly!"

If you're experiencing 5 FPS then your OFP is running SLOW, not laggy.

Infact the term "lag" is technically incorrect too, its a simplification of Latency which is the time-delay between a packet of data being sent and recieved.

And yes, you can have "lag" and be running at 60 FPS, when you "lag" (which can only occur on a networked session, since a local single-player session does not have to transmit data anywhere other than your PC) you become de-synchronised with the other clients, which can cause the mobile units in the session to "zoom" over large distances as the code tries to compensate for the delay.

Something that is much easier to understand when you see it happen.

[vektorboson 8]

You might want to check PaNTool, as it can merge textures and create the script for the merged texture. Eventually you have to edit the config-like merge script for correct paths.

As for the LOD switching, there was a formula in the MLOD-description by OFPInternals:

p3d-description.txt

Quote[/b] ]

Other values (< 1100.0) are extact LOD's resolution.

LOD selected for displaying if

DistanceToObject * LODCoef * M <= LODResolution

Where:

- LODCoef is value from OFP preferences (I have LODCoef = 0.019).

- M is some value that changed by OFP developers (I use M=1 in WRPEdit and M=2 in P3DEdot).

So probably that M value is dependent on FPS or some other value.

[sanctuary 19]

Nice reading.

Question : is there a list of requirement to know, model or texture wise, to get an addon MP totally compatible without crashing dedicaced servers.

The basic i know to have a texture not crashing OFP in MP is that the texture size must be of a power of 2 (8-16-32-64-128-256-512-1024-2048..)

And as recently demonstrated with the Diesel A10 thread, the ratio between the height and the length must not be 8 or more (by example 512x32 and 512x64 should crash OFP, 512x128 will be totally OK).

[Guest RKSL-Rock]

Btw, Can one please explain why binarizes sometimes tends to f**kup my models? When I test a tree in MLOD all the geo lods work but after binarizing mostly the viewgeometry doesn't work anymore.

Try simplifying your view geometry a bit - the only time I’ve had a problem like this was due to complex geo lods.  Binarise seems to do a full convex hull optimisation so it will merge objects/vertices and remove faces it deems to be inefficient.

Continuing vertices vs polys argument, since i'm one of the vertices camp, thanks to Vektorboson and co for clearing up the misconception.  But to add my own 2pence about OFP's handling of vertices:

Look at a destroyed model - you'll see the OFP engine moves the vertices rather than whole faces - its a good indication of how OFP deals with models.  If this was a different engine we were using then maybe i'd be inclined to agree with the Poly supporters too.  But to prove the point sometime ago we setup a 4 person Internet MP session (lowest ping of 31 and highest 168) an applied 3x 2048x2048 textures to the C-130  (The 1st lod model has 6649 Vertices and 7741 faces with all the details (aerials etc) and managed to get 8 planes flying in fairly close formation without causing substantial lag.  We then swapped the C-130H out for MC-130P SPECOPs version that wasn’t optimised (8294 vertices and 7804 faces and same textures) into the game and we got lag with just 4 aircraft.  We had to kill the 3 AI planes to make it playable.  While its not conclusive proof its fairly indicative.

As for Textures:  we’ve done quite a few test sessions and came to the same conclusion as Nephilim – it doesn’t see to matter if you use lots of textures or just a few big ones as long as the total area is the same.

We did the same test for Texture panels as we did for the vertices and came up with some interesting results - upto 7 aircraft with 5x 2048 panels without too much trouble.  The only problem came was when one of the guys PC's desynced and starting lagging the rest of us.  But I will admit that all the guys testing here have pretty good PC’s  and connections. The lowest being an older Althon with 512mb and a ATI 9200SE the best (at the time) AMD 4000+ 2gb and FX6800GT.  All but 4mb+ ADSL low ping connections so results are a bit skewed in favour of the high-end pcs.

Finally Lighting:  How much of an impact to the engine it has I can’t really say for sure but logically it should be easier for the engine to render – this depends on the game engine’s handling - if the lighting is similar for large areas, rather than changing every tile/poly/tris – so it makes sense to correct the lighting just in case anyway.

Hope some of that helps - only had 5 mins to type this so any dodgy/unclear bits point them out and i'll explain.

Cheers

Rock

[dm 9]

But to prove the point sometime ago we setup a 4 person Internet MP session (lowest ping of 31 and highest 168) an applied 3x 2048x2048 textures to the C-130 (The 1st lod model has 6649 Vertices and 7741 faces with all the details (aerials etc) and managed to get 8 planes flying in fairly close formation without causing substantial lag. We then swapped the C-130H out for MC-130P SPECOPs version that wasn’t optimised (8294 vertices and 7804 faces and same textures) into the game and we got lag with just 4 aircraft. We had to kill the 3 AI planes to make it playable. While its not conclusive proof its fairly indicative.

Again, the whole "lag" terminology isn't quite right here.

The addons themselves do not cause "lag" (latency) that is down to the quality of the network connection.

If having an un-optimised addon in the game causes greater latency when playing a networked session then there is something critically wrong with the net code.

What you were most probably experiencing was slowdown (reduction in the FPS count)