Some notes about model editing

[CTI player IF 32]

And corresponding CONFIG editing as well.
Will keep on updating for long...

[CTI player IF 32]

Converting

It's necessary to convert ODOL into MLOD for editing. And convert MLOD to ODOL can optimize it as well (ODOL support longer texture path for unique AddOn's name, and able to have CfgMaterials effect).

 

Hex Editor

Spoiler

MLOD format doesn't support texture path more than 31 characteristics, but ODOL does. Some ODOL format use long texture path. If a converted MLOD has such error paths, the editor should use hex editor to edit those paths first.  
Aiming to make your pbo unique, don't have name conflict not only with other one's but with yours as well, a not short name with version number is a good choice. This is a nightmare to MLOD format, but you can hex your model after having convert it to ODOL format.

Vertex Lighting Property

Spoiler

If using ODOL_Explorer on some vertices belonging to some faces whose "user" aren't 0, those vertices' lighting property might be "broken". The indicator is that editor can't use "filter" to select those vertices by "lighting" property, and those vertices will have a "255" user value. The lighting probably of these vertices won't work normally no matter whether the editor reset their property. They are "broken" actually.  

(Vertices in picture above are all "shining", but only seldom are really shining. Model is fresh converted from original M1_abrams.p3d.)
To solve this problem, a feasible way is to standarize the property of those vertices and faces they belonging to. Make sure faces' user is 0. Then save the model and binarize it, and use ODOL_Explorer convert it to MLOD again, to gain normal vertices.  

Sharpen Edges

Spoiler

MLOD format converted by ODOL_Explorer won't have ANY sharpen edges. All of them are smoothed. Editor should fix this by themselves. A principle is to sharpen the bottom but not side surface of cylinder.  
By the way, the P3DEdit will save Sharpen Edges info and won't create broken vertices (all vertices will have "normal" lighting property). However it seems can't convert so many ODOL format as ODOL_Explorer do.  

Vertices' Lighting and Faces' User

Spoiler

Since the lighting property is "broken" by ODOL_Explorer (or unified by P3DEdit), editor has to reassign it by himself. Luckly mostly BIS models using single design. Lightings (svetlo) and instruments should be "shining", interior view (vertices in view - crew LOD) and the inner side of track and whell (pasoffset and kolo) should be "always in shadow", and others are "normal".
"User" property of face is meaningful to models going to be used by vehicles whose "simulation" is "TANK". This property won't be remained properly by ODOL_Explorer or P3DEdit. Editor must fix this manually.

 

Edited June 6, 2020 by CTI player IF
UPdating

[CTI player IF 32]

Multiple Textured Model

It'll be interesting if integrating different texture into 1 model. Editor don't have to design multiple models for different vehicles but applying setObjectTexture command.

Videos displaying its effect:

 

Selection/hiddenSelections

Spoiler

Of course they should be well defined. The strings of their names can contain underline, backslash and dot, i.e., '_', '\' and '.'. This design is useless for 1.96/1.99, but in 2.01 Arma:Resistance there're script commands able to obtain parameters of CfgVehicles object, and thus can read the path of texture directly from hiddenSelections[] array.

Multi-painting vehicle

Spoiler

There're probably some parts aren't included by all versions. Editor should fix them by himself like make textures and adjust uv mapping.

BE AWARE! If such a vehicle doesn't design the Init-EH to texture it, those faces won't have shadow effect in future game no matter it has been textured later.

Another noticeable thing, although it remains some unknown details, is that big texture should be loaded in the first resolution LOD of the model, otherwise they'll be indistinct. Editor can create some faces for those textures, but don't have to assign uv value to them. After having set texture's path, those faces can be scaled into very small and put inside the vehicle to be hided. Small texture don't require this. The most superficial problem remain to the readers: what's the definition here of "big" or "small"? (2020.07.02 Update) Besides, such a design will invalid if use "hex editor" to replace the textures' path with captical letters. Path of textures in ODOL format should be lower-case. If replaced with captical letters, the ODOL model can still work for OFP, but big size textures switched by "setObjectTexture" will become indistinct no matter whether they've been defined in the model, namely the method above will fail. Thus one must replace textures' path with lower-case letters when using hex editor.

Alpha Channel

Spoiler

If applying the "setObjectTexture" command on a face whose texture assigned in model doesn't have the alpha channel, the transparent of the being set texture will loss and display totally white/black.  
This point should belong to "Converting", but it's unnecessary to be pointed out if never apply "setObjectTexture" command, because in that case any faces of the model always use textures having same alpha channel property as when being binarized (unless editor adjust the texture after having binarized).  
With this design editor is able to remain unique selection/texture of each version. Those selection/texture of other versions can be assign to an empty texture (like clear_empty in default Dta\data.pbo).

Materials Effect

Spoiler

A surprising conclusion is that the materials effect will work on FACES whose texture assigned in model is included in CfgTexturesToMaterial. Namely editor only need to list textures being loaded in the model but not those going to be set by script command.

Face order/position

Spoiler

Don't forget to adjust the position and order of newly pasted faces for proper displaying if encounter something abnormal.

 

Edited July 2, 2020 by CTI player IF
Updating

[CTI player IF 32]

Rotation of Commander Turret (otocVelitele)

 

[CTI player IF 32]

Lights(svetlo)

The front "svetlo" (can be switched by button "L") should be defined in both CfgModels and class Reflectors of vehicle's object, otherwise the "shining" vertex won't be hided when lights are closed, and the lighting cone will appear at improper position.
Other kinds of "svetlo" require only correctly defined in CfgModels.

[CTI player IF 32]

Hit Points LOD, Hit-Class and Vehicle's Armor

By now I've explored about simulation tank only.

Total Armor

Spoiler

• The product of armor and armorStructural defined in CONFIG linearly affect the total armor.
  • Those "armorEngine", "armorHull", etc, or the "armor" factor in Hit-class (like class HitGun), WON'T affect the total armor.
    • Actually for simulation "tank" vehicle, those "armor..." except for "armorLight", can be totally removed from CONFIG. It seems they won't be used in game.
    • They can only be removed from simulation "tank". At least the armorEngine parameter is necessary for simulation "helicopter".
    • For tank, it uses armor factor defined in Hit-classes.
• The size of Geometry LOD of model will affect the total armor. The variable probably is the maximum distance between 2 vertex in Geometry LOD.
  • The size of Fire Geometry LOD or Hit Points LOD WON'T affect the total armor.
  • The reason M1A1 so firm partly due to the front-end vertex. It's position is abnormal comparing to resolution LOD or Fire Geometry LOD.
• Whether a model has Hit Points LOD or not will affect the total armor.
  • But how Hit Points LOD designed WON'T affect the total armor. Editor can remove all vertices and selections in this LOD, and will verify that total armor won't change.

By the way, when exploring this I found that if scale Geometry LOD only, the selections' damage will become abnormal, unless scale Hit Points LOD as well. Thus probably we can conclude that although the collision caused by projectile is received by Fire Geometry, the damage calculation happens between Geometry LOD and Hit Points LOD.

Selection Damage

Spoiler

Selections of tank receive damage from Hit Point LOD, and the selection's name must be same as defined in Hit-class. Default name is engine, hull, turet (NOT turret), gun, pasL and pasP.

All kinds of vehicle requiring armorLight parameter. Lights' hit point is defined in class Reflectors. If lights broken, the lighting cone won't appear even though having turned on the light.

It seems the game will only check selections given by HitEngine, HitHull, HitTurret, HitGun, HitLTrack, HitRTrack and Reflectors classes (of tank vehicle). Other self-defined Hit-classes and selections probably will be ignored by OFP.

 

The selection damage will be affected by armor parameter, and armor factor defined in Hit-classes, but WON'T be affected by armorStructural. More functions about armorStructural still remain unknown, but at least we can adjust it to make selection damage more reasonable without modifying total armor, as long as we keep the product of armor and armorStructural unchanged.

Argument: Some players once complained that in CTI the M1A1 has a weaker gun than T80. This probably due to M1A1's bigger Geometry LOD and thus less armor value, which cause its selections weaker (M1A1 and T80 have same total armor in CTI since XR mission, but the armor value of M1A1 is only 1100 while T80's is 1500).

 

The number and distribution of vertices in Hit Points LOD will affect the selection damage too. It seems the selection damage related to

(the number of vertices being hit) / (total number of vertices of this selection).

This can explain why tanks get different selection damage by same ammo hit at different position. However the damage of total armor is different when being hit at different position as well, but as mentioned above, total armor won't be affected by hit points LOD. The author guess similar system exist in (Fire) Geometry LOD when calculating damage to total armor.

Example: one can compare the pasP of M1A1 and T80, and test how firm their track when being hit by same projectile.

It's possible to adjust the armor factor defined in Hit-classes to balance selection damage for different models, however the distribution of vertices still requires editing the model directly. It's better to set reasonable vertices in Hit Points and define it uniformly for vehicles of same strength.

(Whether faces exist in Hit Points LOD or not seems won't affect selections damage.)

Example: The M1A1 of INQ_M1.pbo has many vertices in its pasL selection. Their number and distribution cause the RTrack very hard to be broken.

 

Actually editors might try to use the hit-points to design tank's "health". The "health" isn't the total armor. For tanks, if its hull/engine is badly hurt (probably being damaged more than 90%, or 100%), the vehicle will self-destroy few seconds later. Other broken selections will cause functional loss as well. If raise the vehicle's total armor but weaken some critical selection and assign proper hit points LOD, it's possible to design a different tank comparing to original-fashioned ones.

 

 

Besides, the meaning of passThrough parameter in Hit-class remain unknown. I tested it in many cases including when exploring topics mentioned above, but unable to conclude something. This parameter can't be removed as "armor..." of tanks, but don't know how does it effect. A might-be relative phenomenon is the damage of tank given immediately by Hit-EH is different from the value given with a delay.

Edited June 6, 2020 by CTI player IF
Updating

[CTI player IF 32]

Memory (general settings)
Only list some general, separated settings here. Those complex, systematic topics won't be contained in this floor.

pos driver/gunner/commander/cargo

Spoiler

All of them can contain more than 1 vertices. Their position is for "Get In" action, and are often used in UserActions.  
It's unnecessary to define all of them. The "Get In" action of undefined seat will use defined one's selection.

zarmeny

Spoiler

 

This selection will tell AI the position to aim at.  
This selection don't have to be defined. But AI sometimes can't attack models accurate enough with this selection undefined.
Well-defined zarmeny can make AI aim better. BISM2A2's zarmeny is too high and tanks often miss when shooting at M2A2.  
If the zarmeny is lower than the ground, AI will never shoot at this model.  
Read more at

 

 

 

 

[CTI player IF 32]

animationPhase

If the command animationPhase applied (e.g. for UserActions), it's necessary to define the animate-corresponding selections in all resolution LOD and view - crew LOD. Otherwise, the animationPhase command won't return changed value if player is in that LOD (e.g. no selection in view - crew LOD will cause inner seat can never get changed animationPhase in 1st-view. But if the selection is defined in the 1st resolution LOD, the moment player get off the vehicle or activate 3rd/tactic view will lead toanimationPhase's change and obtain correct value).

The selection don't have to include any faces/vertices, but it must be defined in LOD's.

Besides, the animationPhase won't return changed value for vehicle out of sight, no matter whether the last resolution LOD has defined corresponding selection. And we might conclude from phenomenons above that animationPhase is related to player's view (and camera, if switched) but not any of its members.

(Update on June 14, 2020) The animationPhase won't return changed value, if player isn't facing the vehicle, even though distance is only few meters.

Edited June 14, 2020 by CTI player IF
Updating

[CTI player IF 32]

Plane's taking off/landing

(preliminary finding)

The way AI landing is by "autopilot" system. Observing how it works on different planes, the authot think the main problem AI fail to land is "turning" during autopilot on. There're few factors known that affect this.

• Mass distribution
  • The mass distribution defined in Geometry LOD will affect both sensitivity and effect of turning the plane.
  • The sensitivity can be adjust by CONFIG parameter aileronSensitivity, but the effect can't. And the aileronSensitivity can't help autopilot do better when turning the plane.
  • Refer to BIS-Su25, it'll be good to centralize 50%+ mass in the center part of the body. Editor may simply add a box Component in the center and raise its mass.
    • Don't forget to check the position of the centroid. If it's beyond the gear's range, plane can't stand on their gear.
• CONFIG parameters
  • AFAIK brakeDistance, landingSpeed and noseDownCoef is related.
    • The brakeDistance probably affect the position plane start to turn around to the airport. If set it a small value, plane will turn around at a short distance and can hardly adjust its direction in such distance.
      • Not verified yet, but the name of this parameter seems mean "the position AI start to brake". For plane, it's meaning might be the position start to turn around to the airport.
    • The noseDownCoef seems affect the "nose down" when turning left/right. Don't know why, but this parameter's improper value  will fail autopilot landing.
      • Besides, AI planes' will always turn left/right when they've just taknig off. This parameter's improper value will make their flank hit the ground.
    • The landingSpeed will affect autopilot as well. Don't know how it works yet. Keep it same as original plane's definition, namely set it 0, might be a good choice.

 

[hitman1987 69]

Talking about ODOLexplorer, after conversion to MLOD with it assignes some polys user vaues to "1", so have manually to reassign back to "0". That would fix "shining" of muzzle flash dets and so on. P3Dedit might to offset the model's center coordinates on conversion. There are numerous Arma models debinarizing tools, but no single proper for OFP.