Question for the Devs / Modelling organization
-
I need to find out this small detail, so pls provide some light here.
Let’s say that an aircraft model uses 4 big skins. I presume these are loaded into memory when the model is within the lod distance value as set in LE (lod model bubble). These 4 skins will map the whole model details, paintscheme, gear, cockpit etc, in various positions on the skin template.
Is there a logic, from the initial texmap-sinning process, to have some plane specific parts in a different skin? For example, moving the gear and dragchute (cannot think something else for now) to the 4th texture, and have the main body paintscheme and details to the 3 first skins.
This way, the memory will load only the 3 first textures when the plane is in the air with gear-up, and only kick-in the 4th texture with gear-down command.
Is this logical towards helping improving performance?
Or all the -child model parts/skins are “tight” to the -parent model (the main lod model itself), and consume the memory as a whole?
-
hmm you’re referring to the blocks aspect in LE
source: tutorial 3ds.txt in lod editor
Details: It is not necessar to have all the added details in the 3ds file itself. When talking about details I am referring to landing gear, lights, afterburner, etc. Those can be easily added by means of the Block functions.
interesting solution and i wondered about this when i saw that MLU jets came complete with dragchute in the model, maybe a limitation in bms that makes be like this?
-
well with lods u actually say to the code which model to load. So each model drugs - have an inheritance like the textures. So when u load the new model you load the new textures. If the textures are the same I believe it just reloads them.
Using one texture for those models for some parts it’s efficient and saves time and texture space I believe. So you can - must map which parts you want to those files 4th texture as you say which in many cases might be just the same for all models.
This technique I believe is mostly for modeler easiness than memory load. -
Hi, While I’m not in a position to tell you EXACT details because I’m not familiar with the 3D models loading in BMS, I can tell you that for sure there is no such thing as loading a texture per switch/DOF usage, I mean once a model is loaded to VRAM, all its vertices and textures are allocated in video memory.
Regarding texture skin sets, I don’t know if a model is loading all skins to VRAM at runtime, if yes then this is highly inefficient and while original Falcon used to do that, I doubt if BMS does that as well. Anyway I’ll try to check.
-
So all objects textures are loaded at runtime and when you have to display a model it tells the code where to find this texture? hmmm
-
So all objects textures are loaded at runtime and when you have to display a model it tells the code where to find this texture? hmmm
No… you can’t load all textures at Init because you don’t have enough VRAM to store everything, so V-Card will start swapping which is BAD. Instead of that the sim is loading models/textures by request… Anyone who ever played with external views during campaign can see how it takes sometime for Airbases models and textures to be loaded (Without SSD it can be really slow, sometimes even a couple of seconds).
-
Yeap I’ve seen that many times but I thought the delay was cause it was loading all first then showing the correct ones or cause it was loading and terrain tiles.
If that is the case then it should be quicker???What if I have enough vram? IIRC there was a say that it loads until it’s full then starts management, like loading what should be shown and the rest not
-
Well no it’s not terrain tiles, that is for sure, you don’t see the terrain tiles getting “sync” right?
Regarding the Loader in general, well I don’t have the knowledge to tell you what’s going on EXACTLY, but I don’t think there is a check for VRAM getting topped-off… GFX coders usually fit the loaded resources at init to the expected VRAM amount. Look at the weight of the resources that the sim can load at runtime:
Koreobj - ~1.5GB of 3D models textures
Terrain tiles - ~1.2GB
KoreaObj.LOD - 3D models data ~1.1GBYou can’t practically load all that at init and keep it in VRAM. And that’s without counting particle system vertex and index buffers, terrain, autogen, all that takes VRAM.
-
So it loads them every time. So less textures where higher resolution covers the subject is more efficient like 1x4096^2 texture is better than 2x2048^2 textures or a 8192^2 better than 4x2048^2 or 8x1024^2.
So Raptor if the gfx engines use cache for common used textures it might be the best way for having such parts in a different one texture.
In general I believe the impact or gain might be way low for the trouble. this could be nice maybe for the license plate? Like in one texture have 4-5 different plates and instead of loading 4 different textures load only one. Me thinking…
-
Maybe for a couple of planes in the mission formation the fps impact is small to nothing, and maybe for big missions with 20-30 similar planes it has an increased potential to save some fps, but the logic in the end of the day is better model / texture / memory / cpu management.
Still waiting feedback voices from other devs and 3D modelers to put some light into this small detail, that could however turn to a new fact in future designs.
-
Raptor this is answered already.
Using less textures for many models. WaveyDave said one texture for 16 buildings and damaged models. -
I’m not sure what answers are you looking for here?
Textures sampling in GPU shaders code is one of the most expensive operations, so practically the less you do that, the better. For general idea of how to build 3D models for Falcon, you can already see many examples in the DB… Torando, MIG-23, MIG-29, Harrier and many more. 1 big sheet for the skin and another smaller sheet for transparent stuff, that’s probably the best you can do.