Using a generated mesh to draw information graphics to

Kilgore__Trout

In a 3d tile & turn based game, would it make sense to use a procedurally generated mesh, the same size as the game area, just above ground level, to draw information like movement paths for characters, cover provided by structures, weapon range etc?

satchmo

Sure, sounds like it makes sense. Procedurally-generated meshes are often used for dynamic in-game effects that can vary a lot based on gameplay so it isn't possible to use pre-built assets. For example motion trails (used sometimes in action games to show fast movement - here's a couple from Heavenly Sword) are often built procedurally on the fly because they have to follow the positions of the animation bones, which are only known at runtime.

But from your description it sounds like you want to draw one huge mostly-transparent mesh above your ground level. That's not a good idea - it could be pretty costly to render an almost-fullscreen piece of geometry, which doesn't make sense if most of it isn't going to contribute anything to the image.

In general, since procedural geometry is usually defined mostly by code, it can be harder to iterate on and get the look right. So make sure you have a good reason to use a procedural mesh and not a regular pre-built art asset.

Kilgore__Trout

satchmo wrote: »

But from your description it sounds like you want to draw one huge mostly-transparent mesh above your ground level. That's not a good idea - it could be pretty costly to render an almost-fullscreen piece of geometry, which doesn't make sense if most of it isn't going to contribute anything to the image.

This strikes as being a problem. I'm curious if the quads that made up the mesh didn't share vertices (so you wouldn't need to generate a huge texture to wrap around the mesh, and instead could just draw small textures between certain UV coordinates) would you still have the overhead of rendering the entire mesh?

Torakx

Kilgore__Trout wrote: »

This strikes as being a problem. I'm curious if the quads that made up the mesh didn't share vertices (so you wouldn't need to generate a huge texture to wrap around the mesh, and instead could just draw small textures between certain UV coordinates) would you still have the overhead of rendering the entire mesh?

If the mesh renderer component is switched on for the whole mesh, then yes(if the whole mesh is not broken into separate meshes). But if they are different objects, then you should be able to just load certain ones as needed.

I suppose you could try a grid/matrix of the same prefab stacked together the size of your grid spacing. Then on the root prefab have code to SetActive whatever feature is triggered on the gameobject.
Depends on how hungry that is resource wise though..
I've not much of an idea how big or busy the scene is going to be.
Worth testing with a grid of prefabs with the texture rendered deactivated, to see drawcalls. I have a feeling if an average object is 2-3 draw calls you might lose 1-2 on each prefab with an inactive mesh renderer.
Maybe 1 for the actual game object?

Kilgore__Trout

Good to know. Starting to suspect a generated mesh may not be ideal, as its purpose would be for things like drawing paths, cover provided by tiles, rather than a more essential function like drawing terrain to. These things could likely be done more easily and with less overhead, using other methods.

Paths could be done pretty easily with line renderers, and cover with images childed to the object for selecting tiles, and area of effect markers could be done the same way, or by instantiating a grid of objects, as you suggested.

Another question: Will probably use construction kit asset packs of 3d models to build the levels. The levels are going to be fairly complex, so procedurally generating them is likely to be the stuff of nightmares. Am looking at manually building a certain number of levels from these models, of varying sizes, which will have a small amount of randomisation performed on them after they load.

Then the data layer will be generated, and all structures will be found, and factored into it. I'm aware that the structures will have to be a multiple of the tile size, and that anything non rectangular is going to be a pain, but does this seem like a someway viable approach? Anything in particular I should be wary of?

Torakx

Yeah the cover and any other pop ups could be done with the objects prefabs in some cases.
If the trigger to bring up cover is on the wall prefabs and the code to turn switch on is on the player, you could use a spere collider to check when their in range.

I have had to consider random generation for the FPS game we are planning too.
We wanted mission levels based on and inside the same structures, but varying level designs.
My first and maybe only idea, is to create a framework of empty objects(volumes to me in this case) side by side and a layer(separate gameobject parent) for each level. Then use a levelManager to load in different room types, which I would design later.
Maybe a door facing north is represented by N, east by E and so on.
The grid number could be 00 for x,y coord on grid bottom left.
The bottom left volume with a door facing north and east would then be assigned any room inside the NE list/array and NE would be applied to 00

To pull it off, I am going to have to figure out arrays and lists properly. i have used an array for object pooling. But it also had a for loop which made the whole thing a little hard to pick up foundationally. I need to revisit a lot of basic stuff still
But that was my general idea for our game levels that were instanced.
I've no idea yet about how to organise well the code to sort the types.
At my basic level of coding it could be reduced to a crap load of "if" statements lol

Kilgore__Trout

Keep us posted on how this approach goes. I can see the logic behind making the rooms single entities, and then slotting them together. Hard to say how difficult it will be, but I wish you luck : )