Project Reality Forums

Hey there,

While learning for my garage, Rhino mentioned things like draw calls, textures and something something.

Anyway, I made an air conditioning unit for the side of a norwegian static, and at first could only find a decent air-con texture on the \objects\staticobjects\pr\textures\portacabin.dds file, which is in the same directory as all the other textures I'm using. I stumbled across the same textures but on a much smaller (11kB vs 680kB) sheet located in \objects\staticobjects\common\textures\aircon.dds.

I'm not sure which is better... and need some advice:

- Which is better: use a considerably larger texture sheet from the same directory, or use the much smaller texture sheet from an external directory?

Drawcall wise, unless your already using any of thous textures in the same material as you would for the air con, your going to have 1 more draw call from the new material w/e texture you use so that isn't really a factor in choosing which texture here, but if there was an aircon texture on a palette you where already using on your model, especially if it was in the same material, then yes it would be a massive factor.

there is also another factor to consider here, which is the texture detail. The textures are not actually identical, although very similar (most likely made off the same texture from CGTextures or something ) but the aircon.dds is in fact, much smaller, with the front face only being 70x64px, where on the portacabin.dds file, its 140x128px which is twice the size. However this shouldn't be the overall deciding factor on picking which texture to use but it is a factor. There is also a few small aircon textures on \staticobjects\_asia\village\textures\chvillage_obj_01_de.dds but they are pretty much irrelevant.

The biggest factor here is simply, is there a high probability of one of these these textures being loaded already in a map using my static by another static and if yes, which one is the most likely and if there isn't a high probability, which texture has the least impact on the memory and also other smaller factors to consider, like pixel detail and what else can you use from this palette on this static or similar statics being used with it.



Now onto where each of these textures are used, the aircon.dds is a vBF2 texture, used on pretty much every middle-eastern city building (including many of the pr me city buildings, + other pr statics too) and most likely a bunch of other vBF2 objects although its mainly used on the ME city buildings.

The portacabin.dds texture is pretty much only used on the PR portacabin (\objects\staticobjects\pr\military\portacabin\) and also the PR Tent_v2 and the new Tent_v3. Other than that, can't think of anything significant that uses it. The palette is also more used in the next version of PR as the new tent_v3 tents add another, bigger aircon to it, its front door texture and some other stuff, although isn't 100% filled yet.

As such I think we can conclude that the portacabin texture, even thou is pretty common in many main bases, it isn't outside that and if its an insurgent map, with a carrier for example, very good chance it will not be loaded and loading this pretty large texture for a tiny portion is really not worth it here. The aircon.dds if your static is going to be used with a lot of ME City buildings is a certain yes to it, and even if not, the texture is so small that loading it isn't going to impact very much on the memory and the more you use this texture on other statics in the same possible series possibly, the more it will be worth loading it.

So unless you can pretty much guarantee it being used with the portacabin or the tent_v2/3 objects, I would go with the aircon.dds texture here, even thou its 1/2 the detail of the other (although if you really wanted to, you could remake the texture from scratch, upping the rez as long as you kept the UVs etc the same then the new detail would translate over all the statics using it).



There is another option, but I very much doubt that in this case it would be worth it but going to go into the basics anyways just so your aware of it, which would be to make a new texture as part of a new palette (with a bunch of other textures) that your new object series uses enough to make it worth using. Like for example, with my new afghan static palette textures, one of the things I did was integrate the basket texture into it from the pr/village/ buildings, which I did for two reasons. The first is to cut down on draw calls, with the props all using a similar material/texture, it cuts down on draw calls rather than having another material loading another texture. The second was because I added a normal map to it as part of it, and a spec map as the old one was just a colour texture, the new one is a detail texture which also meant making it grayscale, so it gets the colour off a separate colour texture. As such, with my new afghan statics I don't load the old basket texture from the village textures (which also had some stuff on that palette I didn't need for the afghan statics), saving on draw calls and also adding more detail, as well as saving on memory assuming that the new palette size would be the same, and loading the new texture on top (note the palette isn't 100% finished yet so ignore the unused space etc)

Thank you for the very comprehensive answer, as always, Rhino.

The last part is a little confusing to me especially with all the different maps you're talking about, since I thought they were on different layers of the staticmesh texture type.

It has definitely cleared up a lot of my original questions though! Will continue working with my newfound knowledge

You mean your a little confused as to why having multiple materials has an impact on performance?



Here is a basic cube I've made which I've assigned 3 different materials to, with there own colours, in the same way you would add a different bf2staticmesh2 material with different textures on it to different parts of a model.

Here is the vBF2 hotel in BFMeshView which shows us all the material an object is using in each lod and what textures are in each material:


Now we can see lod0 has 8 different materials in it, and even thou many of the materials use many of the same maps (like common_01_c.dds), this only means that that map is already loaded ingame but having it again in a different material, even if the material is excatly the same texture setup (but different mat name and/or shader technique) as another used by the object/lod, still means another "Draw Call" for the CPU to process before the GPU renders the object.

Now one extra draw call on its own isn't a lot, but a thing to keep in mind is that especially with a static object, with this object potentially being repeated throughout a map, that extra draw call or two is going to be multiplied multiple times over (although you do then get into a thing called common draw calls which are not as hard for the CPU to process as unique draw calls but still can be pretty hard).

What happens is if you have too many draw calls, it can potentially bottleneck the CPU from being able to tell the GPU what it needs to render, causing lag even if the GPU isn't working very hard just because the CPU can't get the information to the GPU, although multiple draw calls don't help the GPU to do its job either but draw call lag normally comes from the CPU becoming a bottleneck.


This information however shouldn't deter you from having lots of different multiple materials on an object, just you need to be aware of what it means for performance and being aware of it means that you can optimize for it in the main mesh and in the lods, cutting away materials you don't need (also final lod should only have 1 material in it, if it has multiple its dynamic shadow casting wont work correctly, and much, much easier to process as then its just 1 single draw call which means map VDs are affected as little as possible by draw calls).

Thanks Rhino, that material/draw call stuff makes infinitely more sense now. I'll try to keep it as optimized as possible with as few draw calls as possible whilst maintaining visual integrity. And I'll definitely make that final LOD have just the one material.

I should probably post a WIP thread with my apartment thingo sometime soon... I've held off though because while it's nice to receive feedback, it does kinda sting a little when there are so many things I inevitably have to change

======

Oh I do have another unrelated question - Is it worth making the .occ occlusion mesh for an object that is 16m x 34m x 14m (LWH)? Does PR now have the occlusion something something flag enabled?

also another thing I forgot to mention is draw calls are not just down to object's materials, they are down to many factors, a new, individual object is another draw call for example, which is one of the big reasons why the Afghan v2 statics, the ones that the buildings/walls are made up of lots and lots of tiny little pieces that are seen on Lashkar Valley, Fallujah West etc cause so much lag for the maps, as most CPUs just get bottlenecked by all the individual static draw calls, even thou each static only has only a few materials on it (most of them only having 1 per lod and common materials too) but a building can end up being something like 20+ draw calls since its made out of so many individual wall and roof bits.


As for the .occ meshes, it very much depends on the object itself if it can have one and what it should be like. Generally an object of that size probably should have one, but if it can is another question.

I wouldn't worry about .occ meshes at this point, its something that is made separate from the static.