Question about draw calls

[JonnyAnomaly]

I've been confused for a while about draw calls in game for textures and assets, and I was hoping someone could help clear something up. At the moment, I've been using this single wood texture to texture some props and things, thinking that the engine will recognize that it only has to use this one texture across multiple objects and therefore only have to call it once - But is it right to assume it will only call it once, or do I have to do something else in the 3D package, like bring them all into a scene and assign the one material to all of them before exporting?

It would be nice to know that its loading the texture only once, and not loading the same texture 7 times or something, which would be wasteful. My method so far for creating the assets has been to start a new scene, model the object and then assign a new material, point it to my wood texture and then export. Then do the same again with a new object (new scene, new material).

Or does it only come down to using the same material in the material editor to determine whether it calls it once?

[xxxxxxxxxxxxxxxx]

I'm no engine coder, so I'm not 100% sure, but here's how I think things are:

First of all, the number of drawcalls depend on 1.: The number of separate meshes and 2.: the number of different materials that are on screen at the same time.

Furthermore, if you have the texture multiple times in multiple model folders, the engine obviously can't know that it looks the same. It will thus lie in memory multiple times. (duh... )
If several materials point to the exact same texture file, it will only lie in memory once. Since the number of drawcalls depend on the number of materials though, that doesn't get reduced. You'll just save memory.

If several meshes use the same material, that will reduce the number of drawcalls. You'll still get a drawcall for each separate mesh though, so for maximum drawcall reducing you would have to also combine them into a bigger mesh.
This, however, isn't necessarily better for the overall performance in the end, since instancing the same small mesh multiple times will save memory compared to having one big mesh lieing around in there. In addition to that, you might also lose performance depending on how the engine handles culling. (= throwing out meshes that are not visible) If it can only cull whole, separate meshes, having one big mesh that sprawls through your entire level can hit performance quite hard.

So it's always a bit of a balance act between memory and render time, depending on the inner workings of the engine at hand. Maybe someone with more knowledge of how hpl works "behind the scenes" can help you with that.

Here's a nice article about reducing drawcalls, btw. It's for Unity, but the general techniques shouldn't be too different. (Apart from the fact that hpl doesn't have the built-in functions mentioned, like the auto mesh-combine, you'd have to do that by hand)

[JonnyAnomaly]

Awesome, thanks! You mention the number of separate meshes - I'm using a wood beam to make lots of things in the level editor by duplicating them. If I use this object 10 times to make a banister for example, would you say that is generally a better practice than creating a separate, complete banister piece and using the same texture?

I mention this because I have hundreds of these, I'm making everything out of them

[xxxxxxxxxxxxxxxx]

I'd say with something relatively small, like said banister, it would be better to have it be one mesh. A whole fence surrounding a huge meadow on the other hand should probably be broken up into a few smaller repeating fence parts.
I guess it's best if you just look at the original Amnesia meshes for reference and see what they put in one mesh and what they decided to build from smaller ones. That should give you an idea on how big the meshes should be

Also keep in mind: For drawcall reducing, meshes need to use the same material, not just the same texture.

[JonnyAnomaly]

Thanks. Its interesting to see how far I can go before things start to slow down, hopefully that doesn't happen too soon, anyway!