Lag Issue Due to High Vertices in 3D

I have 3D models with high vertices in my scene rendering at the same time which leads to lag issue in-game and the game slows down FPS fall down too much lower. is there any solution for that?

 

@aleksandrk
this is the whole model made up of small sphere meshes.



using the dynamic batching technique

Dynamic batching (Meshes)
Unity can automatically batch moving GameObjects into the same draw call if they share the same Material and fulfill other criteria. Dynamic batching is done automatically and does not require any additional effort on your side.

• Batching dynamic GameObjects has certain overhead per vertex, so batching is applied only to Meshes containing no more than 900 vertex attributes, and no more than 300 vertices.
  • If your Shader
    is using Vertex Position, Normal and single UV, then you can batch up to 300 verts, while if your Shader is using Vertex Position, Normal, UV0, UV1, and Tangent, then only 180 verts.
  • Note: The attribute count limit might be changed in the future.

as referred to in https://docs.unity3d.com/Manual/DrawCallBatching.html.

problem is I cant decrease more detail in the sphere.

is there any other solution for this ?

 

This is an extreme case for dynamic batching. There are highly optimized dynamic batching with particle systems and sprites, but many really anything over a few thousand vertices is quickly going to become slow.

I'd highly recommend using camera facing quads with a normal map and alpha tested transparency to make it look like a sphere instead of geometry, on top of using instancing.

 

Already tried Man No Luck

 

Smart Phones (iOS and Android Devices)

I don't have much idea about raytracing. Let me get some data about that.

 

Thanks For Your Help. Lot of new things I have learned.

 

The real issues here aren't so much in the vertex count in itself, mobile GPUs are totally capable of rendering ~1m vertices at acceptable framerates. The issue here is the use of so many game objects & dynamic batching being done for so many meshes every update. You're getting CPU limited.

The solution is don't use a bunch of dynamic game objects, and don't use dynamic batching. If the magnet structures are mostly static, then switching to building them only when they change (and hopefully that's not too often) will speed things up significantly. You can take a bunch of separate mesh renderers and combine them into a single mesh using Mesh.CombineMeshes() that you render by itself.


However, you'd still be limited by the number of different colors you're rendering, which I'm guessing you're assigning via different materials. You'd be much better off with instancing or using vertex colors. You say you tried instancing, but if you have dynamic batching enabled, and you don't have your materials set to use instancing, Unity will usually default back to dynamic batching. You must disable dynamic batching for it to work. You'd also get a lot more mileage with the instancing if you used a shader that supported instanced color values, which the default Standard shader does not. Instancing may also be much slower to render on the GPU and if you rely on Unity's built in auto-instancing, it may still take quite a bit of CPU time.

The best solution would be to write a custom instanced shader that also has an instanced color property, and drive that with a Graphics.DrawMeshInstanced() or better yet Graphics.DrawMeshInstancedIndirect() so you can customize it further with only a position, 1 dimensional size, and color and have the shader orient a quad that looks like a sphere towards the camera.

The easier way to get here without needing to write as much custom code yourself may to abuse particle systems. You can create a mostly empty particle system, with a material using Particle/Standard Surface shader. Then you can use SetParticles() to set the Particle array with the positions, and colors you want and let the particle system handle the rest of it. By default the particles will be doing something similar to being dynamically batched, but it should be much faster than "real" dynamic batching.

 

Let me try this

 

Thanks for your time.I'll see into it