Texture variants

[LoTekK 0]

This is probably going to sound incredibly stupid, but I'm wondering if it's possible to have texture variants defined in config, rather than have separate .p3ds for each texture variant.

Right now I've got one kangaroo model with three texture variants representing different species. If I needed different unit types for each species (Red Kangaroo, Eastern Grey Kangaroo, eg), would I need one .p3d for each? Or is there a way to use the same .p3d with different textures in the config?

[hardrock 1]

Nope, you've got to do three different p3ds. There would be the very bad solution of using setObjectTexture, but better avoid using that command on whole models.

[LoTekK 0]

Kay, that's pretty much what I figured. Thanks for confirming.

[remcen 0]

There would be the very bad solution of using setObjectTexture, but better avoid using that command on whole models.

sorry, but i don't understand why. sebastian müller setobjecttextured the different variants of his dune buggy without problems - with 512x1024px textures if i remember rightly.

so... as long as the roo uses few large textures i wouldn't consider it a problem,

[hardrock 1]

sorry, but i don't understand why. sebastian müller setobjecttextured the different variants of his dune buggy without problems - with 512x1024px textures if i remember rightly.

so... as long as the roo uses few large textures i wouldn't consider it a problem,

I would although. You have to apply all possible textures on the model, if they are larger than 256x256. That means, that everytime you load a model with - say - 3 possible 1024x1024 textures, the engine has to load all the three textures instead of only one. Now think of everybody doing this, I don't think this would have a good impact on missions considering performance. Especially when you spawn such units, you would notice the difference, and IMO it's the best to create models as performance-friendly as possible, even if it means for the end user to download 3 more MB.

That's why I don't recommend to do this.

Also, I think there are problems with setObjectTexture combined with SP saves. It could be that textures aren't applied anymore when the game is loaded again, but I don't know.

[remcen 0]

as for the textures: let's say you have three large textures for three different variants. now, when you place a kangaroo on the map, the engine has to load two of them at most: the one applied in o2, and the new, setobjecttextured one.

now imagine, you map the kangaroo with a 1024^2px texture in o2 to make it look right; make two more variants. now you make a copy of one texture, scale it down to, let's say 128^2, replace the first, big texture and save it. then you code the three variants in the config, and setobjecttexture each one - violŕ: two textures loaded for each, one being only 128^2px (~11kb)

as this isn't applicable to all different kinds of models, cos most variants are too complex to setobjectexture all the single variants (you would hardly have the bird's eye view of the single parts of a lorry for example... ) there wouldn't be many models on a map making use of the setobjecttexture stuff - so your "if everyone would do so"-argument isn't really sound.

that's my point on the performance. wouldn't be a big problem i think... but the savegame issue remains one, that's true. don't know much about it though.

if it wasn't it would only be an addonmaker's personal decision about a tiny little performance loss for a milisecond and bigger/smaller files to be downloaded.

[ag_smith 0]

setObjectTexture does NOT work over the network in MP games. Please do not use it unless you really have to. Using different p3d models for variants is much better. Plus there's a problem with SP savegames, as mentioned by hardrock, set textures are not saved and then you're gonna end up with transparent model after loading the game.

[LoTekK 0]

I ended up just having three p3ds, each was an identical mesh, but had a different texture applied. Seemed the most sensible way to go.

Hopefully ArmA will allow texture variants within the model, though. I reckon this would be not only much more convenient, but also would cut down on redundancy (ie, instead of 15 separate identical meshes with different textures, you could have one mesh, and a config that specified which texture to use for each unit).

[hardrock 1]

as for the textures: let's say you have three large textures for three different variants. now, when you place a kangaroo on the map, the engine has to load two of them at most: the one applied in o2, and the new, setobjecttextured one.

Wrong. OFP has to load all textures, as you have to apply all of them to your p3d mesh (on small parts). If a texture isn't already loaded with an object or a dialog resource, setObjectTexture will use a maximum mipmap of 256x256. You can imagine, that a 1024x1024 texture scaled down to 256x256 doesn't look very good.

[LoTekK 0]

Wrong. OFP has to load all textures, as you have to apply all of them to your p3d mesh (on small parts). If a texture isn't already loaded with an object or a dialog resource, setObjectTexture will use a maximum mipmap of 256x256. You can imagine, that a 1024x1024 texture scaled down to 256x256 doesn't look very good.

Straying a little bit from setObjectTexture for a second, does this mean that the engine will load all textures even in the case of hidden selections? Let's say, for example, I have a camera model, and four different lenses plus a flash assembly as separate hidden selections, all using their own texture sheet.

So once the engine loads up the model, even with all hidden selections not shown, will it load up all of the textures used by the hidden selections as well? Or only when they're made visible?

[ag_smith 0]

So once the engine loads up the model, even with all hidden selections not shown, will it load up all of the textures used by the hidden selections as well? Or only when they're made visible?

From my experience, I'd say these textures will be loaded only if you use setObjTex on hidden selection (unless they are already used on the model apart from the hidden selection).

[hardrock 1]

So once the engine loads up the model, even with all hidden selections not shown, will it load up all of the textures used by the hidden selections as well? Or only when they're made visible?

I can't answer exactly on that one, as I don't know the process how OFP loads objects into a game. But I can say from experience that you have to load every texture bigger than 256x256 with an object or with a dialog to use it with setObjectTexture, else it will be blurry (mipmap: 256x256). I guess OFP loads them right away, but I'm not sure.

[LoTekK 0]

Hmm. Guess I'll have to do some testing once I'm ready to start configging the camera properly.

[rvirding 0]

Would using setObjectTexture work for static objects placed in the wrp? In that case it would be an easy method to get variations of buildings without going in and modifying the original models.

BTW how do you use setObjTexture?

[hardrock 1]

Would using setObjectTexture work for static objects placed in the wrp? In that case it would be an easy method to get variations of buildings without going in and modifying the original models.

BTW how do you use setObjTexture?

I don't think so, as setObjTexture needs specific entries done in the CfgModels and CfgVehicles class of the object, which aren't used by wrp-placed objects AFAIK.

Try to search for setObjectTexture or visit www.ofpec.com for information about the command. It's been explained several times.

[rvirding 0]

I don't think so, as setObjTexture needs specific entries done in the CfgModels and CfgVehicles class of the object, which aren't used by wrp-placed objects AFAIK.

Try to search for setObjectTexture or visit www.ofpec.com for information about the command. It's been explained several times.

I found the tutorials on OFPEC and read through it. Interesting stuff. I think you are right about the cfgs, and also the small size of usable textures make it impossible for what I have in mind. Pity, it would be nice to have an easy way to generate variations of buidlings and such.