It’s not just about triangles.
Unreal will only draw things that are visible.
I wouldn’t worry about this. Generally a lot of high polygon models will slow things down a lot, but so does shadows, foliage, texture sizes and a host of other things.
Basically, if you do something or put something in your viewport and the frame rate starts to tank, you have to ask yourself what you can do differently…
Well, i got some questions about max. visible triangles in a scene.
I know about console command state RHI to show triangle count. Is that the real visible count from both sides of meshes or 1 side only (backface culling) ?
I was reading that 1 mesh with 50k triangles is better than 5x 10k. Is that correct and why? Because i thought, if i got more smaller objects, it could reduce triangle count in the visible area. I created 1 object with arround 30k triangles and if i move the camera arround, the triangle count is still the same ( if i view only the half object i.e. )
Are the drawing calls more expensive than triangles?
Regards, NJ
Thanks for your answer. Yeah, sure. Well iam working on funfair stuff and for that i need many many small lamp meshes like arround 30-40k. Each one should have 8-20 triangles. I also working with lods for that. Thats the reason why iam think about performance.
- Unreal will only draw things that are visible.
Iam not sure, if i understand it right. So the triangle count will show me all faces or all without backfaces?
The engine wont be drawing anything you’re not going to see. So no back faces.
40k is WAY to high for a lamp by the way. If you want to make a game out of it, that is.
8-20 tris is absolutely fine, you could to may 1k tris at LOD 0.
But if you got 40k in the level, you’ll need to use instancing. That way, it’s only 1 draw call for the whole lot, because they’re basically the same thing.
Hi, the objects only get culled as whole object. If you see even a small part of its bounding box, then the whole object is gonna be processed by the GPU and you gonna see the whole poly count in the stat view.
If you have 30-40k meshes then you need to use instancing (but keep in mind that then you won’t have dynamic occlusion culling for them, only distance and frustum culling. So if you got 10k instances behind a wall were you can’t see them, they will still all get processed by the GPU if you look at the wall). You can use the console command “FreezeRendering” to see what is being send to the GPU.
working on funfair stuff and for that
i need many many small lamp meshes
like arround 30-40k
Why not make some different meshes each with a couple of hundreds of lamps and use those? Cause that will give you better performance or less headaches and in the end it does not matter how you made it as long as it looks the same.
Oh okay, thanks.
Why not make some different meshes each with a couple of hundreds of lamps
Yes i thought about to making it this way. Iam not a pro in ue4 and need much to learn xD
Well i was not sure how to realize 30k of mini lamp meshes with material animations , you know like blinking or flashing… with UV animations or blueprint, i also dont know, whats faster. My idea was to create lamp groups with differrent material instances and using BP to animate the material emissive channel for the blinking/flashing effect. So before ill think about thousands of meshes, thats why i wrote here.
I actually dont know what do you mean with instancing for the lamp meshes?
Btw i need 30-40k of this small lamps:
30k-40k individual lamps? oh wow!
I would suggest watching the UE4 learning videos on rendering. It will explain a lot about how the engine renders the items on the visible screen at every frame and will give you a better idea how to strategize building what you want to get done.
Start with Introducing the Principles of Real-Time, and I think you’ll realize 30k-40k individual items will cause you issues quickly!
i create a mesh with 2 lods, drag and
drop it in my level and duplicate it
in the level - that are no instances??
No, each static mesh you drag into your level will be a separate static mesh actor (an actor containing a static mesh component). So that will be two actors.
What I meant with instancing, was to use one instanced static mesh component and only add instances to this component. Then you will have one static mesh and an array of transforms. If you would then want to have 30k lamps you this array of transforms would contain 30k entries. So you would have one actor instead of 30k actors.
If you also want to use lods, then you would use a hierarchical instanced static mesh component.
But if you got 40k in the level, you’ll need to use instancing. That way, it’s only 1 draw call for the whole lot,
Ok so, i create a mesh with 2 lods, drag and drop it in my level and duplicate it in the level - that are no instances?? Because i thought, i hav only 1 mesh, so all lamps are the same…
Thanks for answer. I watched many tutorials, but i will giv it a try 
No not all individual, but the mesh is always the same and i asked me only, whats better for the performance - place/duplicate all lamps in the level on the right position or make some groups with hundred of lamps and duplicate them. Because i thought, if i hav only instances of 1 lamp, the engine see only this single lamps in the visible area and its better to handle only 50k tris than 500k.
Sorry for my bad english.
No, they are all drawn separately. You have to instance them. That would mean using the foliage tool or instancing by using merge actors.
I have take a look at instancing and i understand what you mean. I also can merge them into bigger meshes. I also dont need any collisions or cast shadows, but the only thing whats not clear for me is… how can i make them blinking in an ordering way (running light) ? If the instances got all the same material - then i see the only way to animate them by playing with the UVs or do i have some other ways? Because they shouldnt blink all together at the same time. I.e. only every 3-4 lamps blink, the rest dont…
Notice it’s not just merging meshes, there an option during merge to instance them.
As far as coloring after instancing, you’ve got a problem there.
It is possible to talk to instances from blueprint, but it’s quite a pain in the butt.
