Anyone got recommendations for runtime mesh combining?

Hi all. I'm looking for particular functionality which i'm sure is common, and i'm hoping someone has written a full featured, nicely polished package to accomplish what i need. Unfortunately my preliminary searching hasn't turned up much.

I need a package which can, at absolute minimum: take several skinned meshes and combine them all into one mesh, at runtime.

I believe there are free tools to accomplish that, so i'm looking for a little more too, and happy to pay for it!
An additional feature i really need is to be able to remove hidden geometry. That is, faces which are completely occluded after the joining, and will never be seen.
An automated method of detecting and doing that would be nice. OR;

Some way to specify which vertices/faces should be removed, on a per-mesh basis. My application here is wearable equipment for a character, so i'm thinking something like a mask texture based on the underlying actor's UV map, to determine what parts of their body should be hidden by whatever meshes get attached to them.

Is that a lot to ask? i don't know, but it seems like a problem that must have come up before in lots of games, so hopefully someone has a store recommendation for me.

 

Does Mesh Baker qualify? It appears to have a runtime API.

 

it looks pretty neat, although it lacks either of the geometry optimising features i mentioned. Is that something which should be done seperately? anyone know of a package for that?

 

The mesh optimization is the tricky part. I would think that removing faces/verts on a skinned mesh could cause problems. More importantly my thoughts would be that cost of heavily modding/calculating meshes at runtime (even trans/hidden) would outweigh the costs of A) dealing with it in the pre-prod pipeline and/or B) the actual performance cost of just leaving it.

Geo is cheap, even on mobile. How many faces are you anticipate saving? Depending on the amount of faces and area to be removed, ripping up a skinned mesh may not result in savings, and may add geo (in some cases). For example, remove a single tri won't really save if the verts are shared. Typically, we don't worry about removing faces (but we keep covered areas light geo in the first place). And usually even with extra, it is way under our budget. If the outfit is super heavy, we'll just have another mesh (skin) available. (lots of belts, dangly bits, etc).

What are the poly/vert counts on your base mesh and an example of your equipment?

 

I had thought of that, but some mitigating factors;

1. I plan to do the baking of meshes at a time-insensitive point. IE, when loading the next level. I'm thinking i can leave the base mesh in place while fiddling around in the equipment screen, bbut my intended game will use a hub map and a level system so i could do the mesh baking then (and i won't allow changing such things during a level)

2. The masking system i mentioned seems like a good idea. I could pre-calculate that at authortime (based on an AO bake, for example) and then have the script just use it as a guide for what vertices to remove during the level loading/. that wouldn't be too performance-expensive, i hope?

my character is currently 33,350 tris, naked, although i've yet to optimise that a bit. I've not decided on the detail of the additional equipment yet, but i'd like to go fairly high.

this isn't an option in my case, as customiseability is a major feature i'm going for, and i want to allow players to run around half-naked if they choose. The coverage of planned equipment might vary widely from an all-obscuring baggy sweater, to a tiny belt across the torso.


no equipment examples yet, but I was thinking o;f having the polycount be loosely based on the amount of polys it would cover, so that if the system works right, any given piece of equipment wouldn't change the total polycount much with or without it.

 

33,000 tris isn't much. A single character in our game has 4k tris which goes up to 12k, once shadow passes are over, and that's fine on ipad2-level hardware with 8 characters on screen.

We also have clothing and attachments which push it up, we didn't bother with optimising the draw calls for it or the geometry in particular since attachments are hardly going to be more than 4 more draw calls per character and 32 draw calls aren't anything for me to worry about.

Is this actually profiling as being the bottleneck or issue?

 

Yea, that is what I meant by trans/hidden. Hiding the calcs with cut scenes/loading menus/etc. I guess it could be done. However I would say that is crazy high for naked (human I presume) character.

A big chunk of what I do is performance and pipeline optimization. My approach is focus on the actual result of what I am doing (or trying to do) and balance that between risk, performance cost and quality. (and when appropriate development cost).

What I see is that you are actually trying to do is mitigate performance bottlenecks. Trimming mesh is one approach. I would see that a heavily risked approach. Mostly because it isn't a common approach, there isn't much off the shelf to deal with it. You would have to create (unless you can find one) a fairly complex system. That is also a development cost, and risks associated with making it a solid system. Bugs, unexpected behaviors, and heavy testing to ensure that something that seems simple like putting a shirt on a character doesn't break your game.

Alternates to developing that scale of system would be heavy character optimization so the geo cost is a performance factor. Obviously you want to keep quality high, but 33k is wicked high for even AAA games, and characters approaching that count are usually very complex. But this is something that you might consider regardless.

My suggestion would be splitting up your character in the first place. Cut it up in logical segments (sleeves, shirt, torso, legs, head, etc.) that match as many as possible of your gear (or potential gear). This would you would have a bunch of meshes for a body instead of one. But since you are already planning on baking, this works out nicely. So if your character has a shirt with sleeves, just don't include those (body) meshes in the bake. And for things like a tiny belt or like bracers or anything small, you can probably absorb the cost. Things like that should only obscuring a couple of hundred polys max.

There are a few advantages here. First, low risk, baking is common an a built in feature of Unity. Second, fast. Third, precise control since you are actually determining where things are cut/excluded.

Downside is that you will have to plan ahead, because there will be development cost associated to make modifications to the base mesh. But this may still be less work than building/planning a dynamic mesh cutting system. It shifts the dev costs more toward the art side, but not a huge time sink.

Anyway, just some thoughts. I don't know enough about your game to give too accurate advice. But my general thoughts are that you can probably achieve your performance goals in a less risky way.

 

I see your point here, this may not be a major performance issue. There are still some reasons i'd like to do it

1. I'm a perfectionist and an idealist. To me, this seems like the "right" way to do it, the most flexible.
2. It would cut down on development time in some ways, as i'd have less time spent carefully rigging that sweater to ensure no muscles poke through
3. It would allow equipment to "shape" the character, eg something like a corset which pulls the flesh in.

But that said you do have many points. It could be problematic and time consuming. That is primarily why i'm interested in buying such a system.

however if, as you suggest, no such system exists, then i guess that could be viewed as an opportunity. If i write it myself, perhaps some others would be interested in buying it =) that's what the asset store is for

of course for all i know, there is such a system and i just can't find because of the utterly terrible search (thanks UT). I've tried various combinations of occlude, geometry, optimize, mesh, vertex and mask. with no good results.



I've spent half an hour poking through the various mesh and texture functions, and i think a basic implementation wouldn't be too hard. Crawl through all the vertices of the mesh, and for each one, grab it's uv coordinate, translate that into a pixel, and check the alpha value of that pixel on the Mask texture. if 0, cut it out. Making a face-based implementation seems a bit harder though.




re: optimisation, some of that is definitely in order anyway. a lot of the polygons here are for musculature, tendons, etc. i'm sure i can do plenty with light baking

can you clarify, re: the cost of modifying the base mesh? I read somewhere that altering the bone heirarchy irreversibly breaks animations, are there any other pitfalls i should be aware of in that regard

I really don't like your idea about cutting up the mesh, but i guess it makes sense. It feels messy and fiddly though, my instincts say "hell no" to the idea, but i can see the logic, and i may yet do exactly that.

 

Have you ever seen UMA? This is open source avatar system for unity funded by unity partially which contain skinned mesh combiner designed for rpg style item system (as edge case but you could use it for any type of game)

 

thanks for this tip[. having a look now, but i''m struggling to figure out exactly what it is, or whether it can fulfil my needs re: mesh optimising