I have run into some confusion on when is a static mesh actually an instance where it is reducing its draw calls in the project. Every static mesh in the detail panel has the word (instance) after it. However, from what I have gathered, these are not the same as instanced static meshes (ISM) created with a BP actor. Everything I have read on ISM’s seems to be related to when one is wanting to create an array situation where many copies are to be made of the same static mesh. It seems that the copies are all created as instances within the ISM BP setup.
What I am trying to figure out is what would be the most efficient way of of creating multiple copies of the same static mesh but not in a high quantity situation like an array. For example, if I have a wall sconce light with an associated point light and there will be maybe 22 copies of this in my scene, is there any draw call benefit setting this up in an ISM within a blueprint and then duplicating that BP ISM throughout the scene? I have used BP before to control the same repeated light type but I am looking for a way to reduce draw calls within a scene where I have various repeated objects but not in these large arrays.
Frankly, I thought that duplicating the asset by selecting it and pressing ALT as I moved it was creating an instance (like in 3dsmax) but someone told me I am just creating a copy of the static mesh each time I do this. If I do it 9 times, the static mesh exists as itself with its associated draw calls 9 different times rather than 8 objects referencing back to one object. Apparently the ISM with BP but I am not sure.
So the search continues and so does the confusion. I happen upon this response to a post in this forum several years ago and this is exactly why this is confusing.
By default, if you take an object from the content browser and use it multiple times then it will only be stored in memory once (instancing).
What can also effect performance is the number of draw calls, the more objects/materials you have the higher the draw call count, so if you have a lot of low-poly objects then it’s better to combine them and use more memory to reduce the number of draw calls. I believe though that the latest version of UE4 has a feature for doing some of that automatically, previously you had to manually combine things or use Blueprints which allow you to use the Instance Static Mesh feature where basically you can work with duplicates separately but when the game is running it’ll combine them to reduce the draw calls.
If I understand this post, selecting an object and holding down the ALT key to duplicate as you drag it is a form of instancing where that object will still count as one draw when the game is running.
Hey @arcitek, it seems like you’ve actually got a pretty good understanding of it.
Now, if you use Instanced Static Meshes they aren’t going to be culled on their own, so if you see one, all get rendered. They are also 100% static and can’t be moved in any way. Thirdly, they can’t use LOD’s like… at all. Unless that’s been updated in the last few years ( I tend not to use them because of these reasons, but I just haven’t made any games that could truly utilize the feature).
So if none of those downsides matter to you, that’s when you use an actor to do Instanced Static Meshes. Otherwise, just drag them into the level
I think the LOD’s work on the ISM but NOT the HISM (I think hierarchical instanced static meshes). However, you make a comment that I was not aware of which is you see one, you see them all sort of thing with culling.
Thank you @Mind-Brain. However, and I do appreciate your response, it really does not confirm my understanding or comments on the other points. Are you saying that if I do the ISM in the Blueprint Actor and then DUPLICATE this BP throughout the scene, it will only count as one draw call? I am asking because I am reading contrasting thoughts on this. I am still curious is I just duplicate the object as describe in my OP if this is it’s own instance that works.
I did learn a new thing though looking into this that may be the game changer in some cases. I am reading that if I would have, let’s say, 25 coffee cups on a shelf with them in slightly different rotations and positions and I MERGED those 25 cups to be one static mesh, this resulting SM would definitely be just one draw call versus the 25 coffee cups. This may be the way to go on some of this since it is very easy and fast to do versus setting up an ISM in a blueprint actor and doing an array inside the BP or setting the ISM BP and duplicating it 25 times. I think anyway.
Yes, the goal with smaller SM’s is typically to build out things that will not have physics or movement of any kind and then combine them into a single static mesh. The smaller things are for kitbashing, or for using as a SM for an actor. So you wouldn’t necessarily grab a whole room, but anything that isn’t supposed to be movable and will have the same collision settings, since once connected they’ll share those collision settings. While still building the game, things like “Wall A, Wall B, table A, Table B” are useful, they’ll tend to be left out of the final game to save space and the setups will be one static mesh, reducing size while also reducing the amount of calls done.
Typically the ISM in a blueprint actor at runtime is something more as a tool for building mechanics and functionality. If you’re building a level, you want to build out your set pieces and use that. Loading all those actors and having them populate the level with ISMs will hurt more than you think, not to mention all shadows would have to be dynamic throughout since they can’t be baked.
Well the word use of “instanced” seems to suffer from the idea that by default it implies a means of performance tuning when in fact as to what would be best practice can only be applied with in context for the purpose to be served.
For example and alt copy is a copy as presented in the view port but as an instanced copy, some what like in 3ds Max, as an instanced it could contain parameters that can be used to change the objects shape but since it’s a copy you save on memory foot print requirements.
Perhaps the best use of instancing is in the use of materials as the higher performance cost is base on the complexity of the applied material and not as much on the object who inherits the performance loss over and above what the mesh would introduce.
How you manage instanced material would make better sense as to decreasing at least memory requirements as you could LOD the material from complex to simple materials.
Yes it can be confusing as instancing is not something to be to concerned about at the beginning, except for the ability of the instance you have in 3ds Max, and best practice is to reach some level of completion and then “profile” your environment and the numbers will tell you what is actually happening as it’s being rendered to the camera.
Thank you FrankieV! Good stuff. So to your point, we did completely build out the level for VR on the occulus. It runs fantastic and looks great if it is tethered but slows down a bit and has more AA artifacts not tethered. So the one developer who specializes in shaders took a look at it where we were able to get feedback on what assets were creating the most issues and what should we be looking at to optimize.
So this scene is a coffee shop and there are alot of repeating assets like the coffee bags, the coffee cups, pastries in the pastry case and so forth. We were trying to find a way to reduce the draws on these repeated assets and the ISM’s were suggested but seemed cumbersome to create and use in this case. The merge actors feature seemed like a good idea becasue it addressed both the static mesh and the materials by taking it down to one static mesh with one material. This results in just one draw for the mesh and the material.
This sounds like the perfect use and reason to use HLOD’s
Have not use it my self but from what I gather it also converts your material texture to texture Atlas which is where you can save on a lot of draw calls
