Best approach to having 10,000 individual lines on screen (line renderer is bad).

I have a very large number of hexagonal cells, each of which has 6 "walls" which consist of a button (aligned onto the wall), a line renderer that renders the brown part, another linerenderer which renders a white outline, and a third line renderer below that which renders the final black outline. Now, most of these are turned off (because of overlapping walls) (so about 600 hex cell game object, with 6 cell wall game objects each (each wall has a line renderer on it, and each with 2 child game objects that also have line renderers on them.). Taht's about 600*6*3 = 10,800 game objects. Subtracting the hex cell game objects (which do have meshrenderers), that's still 10,200 line renderers!

This was no problem when the map was 1/4 this size! But it's not a very scalable solution. As I move to larger and larger maps, this obviously is causing issues with performance. But before I start wildly stabbing in the dark about what to change and how to change it, I wanted your thoughts.

How would you go about doing this?

 

I think I would use a custom geometry creator that would create the hexes and lines at runtime.

You could subdivide them into areas and only update areas that change.

I was curious so I made a little Make Lines 2D script that "runs" 1000 lines onscreen and added it to my MakeGeo repository... you're welcome to take a look for ideas.

Look for the

MakeLines2D

scene.

MakeGeo is presently hosted at these locations:

https://bitbucket.org/kurtdekker/makegeo

https://github.com/kurtdekker/makegeo

https://gitlab.com/kurtdekker/makegeo

https://sourceforge.net/p/makegeo



Or perhaps make each hex cell a model that has pre-made center and edge geometry you just colorize by moving the UVs around?

Those here with better shader chops might suggest the shader route, which I suppose might work well too.

 

Another option in addition to Kurt's suggestions is a Hex Tilemap
https://docs.unity3d.com/Manual/Tilemap-Hexagonal.html

Finally, you might want to check the asset store to see if there's an asset that fits exactly what you're looking for. For example I've never used this but this asset looks decently close: https://assetstore.unity.com/packages/tools/terrain/terrain-grid-system-47215

 

To be honest, I've never worked with a "custom geometry creator" before.

Could you give me a few sentence run-down, or a suggestion for a good readup? Google seems pretty sparse when it comes to that search.

 

Ah no. Looking the your code now I get it.

You're basically just making a class that makes the LR's, but using mesh's instead, and then taking advantage of static meshing, eh?

 

You asked about this problem before and left solution proposals unanswered..
https://forum.unity.com/threads/any...gies-down-to-30-fps-all-in-rendering.1250935/

Think it's more like you make one single mesh with all lines so you do not need separate game objects. Even with static rendering, the sole objects themselves would take their toll (because MonoBehaviors are sadly not very efficient in large numbers)

By the way, there are a couple of free assets for hex maps:
https://assetstore.unity.com/?q=hex&orderBy=6&free=true

 

I tried all the suggestions given, none of which were well suited to my use case.

Unfortunately, the same is true for hex map typesets.

My game is really more about having arbitrary walls that can be moved around to form a maze, so it's not the hex grids per se that I'm interested in, but the walls themselves. Moving to a hex grid, for instance, makes voronoi maps and square maps later on impossible. HexCell is a child class of the Cell class, which can have an arbitrary number of walls. I doubt I'll ever use square cells, but the voronoi cells will likely happen one day.


--
Isn't that one static batching of meshes does though? It takes all the meshes you have which are marked static, and bakes them into one mesh? If not, then I must be misunderstanding satic batching.

 

It does that with the rendering, but the existence of the objects is still there. It's worth a try though.

Another idea: You could use particles for the walls. If you enable GPU batching, 10k particles are easily manageable. ParticleSystems have a GetParticles and SetParticles method which allows to manipulate through code without "emitters" etc.

 

What about

LineRenderer.BakeMesh https://docs.unity3d.com/ScriptReference/LineRenderer.BakeMesh.html

then

Mesh.CombineMeshes https://docs.unity3d.com/ScriptReference/Mesh.CombineMeshes.html

You keep the versatility of LineRenderer but bake it and merge neighbors to be more performant.

 

Ah. That's good. I can do that!

Sorry!

 

I'd read about this the other day. I think this might fix at least 2/3 of the problem.

The white and black underside of the walls (The highlight and then lowlight for increased visibility) could definitely be run with particles, no problem. But the main one I thinks should still be run by a scriptable object because it needs to change material states as it takes damage (the walls are destructible), manage health, have collision detection, etc.

Still. 2/3 of the solution is probably "good enough".

 

The walls are destructible, take damage, and have a different visual damage state for each one. I'm worried that if I have to constantly rebake the mesh as walls get destroyed, take damage, or whatever, that this will end up with slow average frame rates, but higher spikes. Still - worth trying. Good idea.

 

Did you have success with any approach?