We are getting lots of art back from outsources that have problems (zero area faces, lamina faces, coincident map verts, zero-area map faces, etc). Before I wrote my own mesh-checker/fixer, curious if anyone has any examples or code (for Max).
Very quickly - have you tried Meshlab?
http://meshlab.sourceforge.net/
It might not solve everything, but might be a useful first pass.
Mesh Cleaning Filters:
* removal of duplicated, unreferenced vertices, null faces
* removal of small isolated components
* coherent normal unification and flipping
* erasing of non manifold faces
* automatic filling of holesWe did have a spat of plugin errors that we used the…
missingDLLsAction:#logmsg missingDLLsList:&dll_val options on file load.
If you haven’t used them, they basically store errors as a variable or to a log
file.
We haven’t had any mesh level issues, but some of the plugin cruft was
gumming up our pipelines downstream. I didn’t want to reprocess everything
so we identified the problem files first. Made the cleanup a little less painful.
Hope that’s helpful in some way.
As far as possible I like to get the exporter and/or converters to do this sort of job. It’s impossible to make sure nothing dodgy gets through so it’s a hell of a lot easier if the converter will solve its own problems. Saves loads of time over having to go through all the source files and find and fix things.
So far our exporter will merge verts and uvs (which would also resolve zero size uv faces), the skinning converter renormalises weights to the most relevant four bones and so on. As we find more things that cause problems we add them to the converters. Since the conversion is done from an intermediate file we don’t need to re-export anything to deal with any re-converting. And the data build is a batch process too so it only needs to be fired up and it’ll reconvert anything that’s changed. Nice and easy.
The converters handle data they don’t expect elegantly (one of the first things I do when providing test data is to make some wrong but likely data so handling errors happens straight away). Typically the converter ignores data it isn’t interested in. Our intermediate files can store any and all data and the converters pull what they want from that file so they’ve always had the ability to handle data they don’t want. There are one or two exceptions that need resolving next time.
The converters supposedly log all errors too, but due to a recent change in the pipeline it fails to save them right now, so we only get them in the console window. We’ll get that resolved next time.
On the other hand we’ve had very good quality work from our outsourced artists. Hardly any major problems. The only thing I’ve had to fix up was some naming convention issues for textures which isn’t too bad for non-english speakers. And some of those were my fault too.
BTW, to follow up when I ended up doing:
I made a list of everything I wanted to check for. I made a struct containing the different cleaner functions. I used a RayMeshGridIntersect for some of the things, and made sure to be as efficient as possible (I needed a RMI for coincident verts and lamina faces, so I have a function for them individually, and one for them at the same time). I checked for: coincident verts, zero edges, zero faces, lamina faces, coincident UV’s, zero map faces, and (in the future) non-manifold geometry. I won’t go into the specifics of how I checked for each of these unless asked (not that difficult, except for the coincident UV’s).
Each function passes out a bitarray of the problem bits. I created an annotation struct that I use to label all of the problems (color coded, and the annotation states the problem and the vert/edge/face number). I then open a results rollout, and the user can unhide/hide and select the annotations for each type of error. We’re still testing and will iterate on it, but that’s the essence of it.
robinb: Personally, I am completely against auto-fixing art except in minor circumstances. I would never auto-merge verts- there are valid reasons to have coincident verts. Auto-reducing vert influences is another thing an artist must do. Especially on current game meshes, 4 influences is really not enough. Getting it down to 4 is not really something that should be done automatically, it should be done by an artist (especially around the shoulders). Some things may be auto-fixed (like merging verts on zero-area faces or edges), but generally, I’d shy away from it. But if it has worked for you, more power to you I guess.
[QUOTE=Rob Galanakis;942]
robinb: Personally, I am completely against auto-fixing art except in minor circumstances. I would never auto-merge verts- there are valid reasons to have coincident verts. Auto-reducing vert influences is another thing an artist must do. Especially on current game meshes, 4 influences is really not enough. Getting it down to 4 is not really something that should be done automatically, it should be done by an artist (especially around the shoulders). Some things may be auto-fixed (like merging verts on zero-area faces or edges), but generally, I’d shy away from it. But if it has worked for you, more power to you I guess.[/QUOTE]
In the case of the coincident verts, they’re matched against UV and vertex colour before auto welding, those are the only occasions I ever found that they needed to stay separate. That has never caused any issues so far and if it did I could easily get it changed in the tool without having to re-export anything.
Four bone weights per vertex was the hard limit on the PS2, again chosen as a fair trade off between artistic fidelity and speed on the target platform. It was possible to use only two bones, but that made for weighting issues so was only done for crowd characters. Again it’s just a setting in the tool so can be changed to include more weights should we need to without re-exporting. The tool took the four most important (highest weights) and renormalised them leaving out only those that had least effect. The models were skinned to four bones anyway, that was just an error trap.
This whole process is designed to prevent the artists having to fix minor (IMO) problems and re-export and re-convert assets which takes time. We only have two artists, so our time is better spent on major problems than fixing things that are minor tech issues. They’re mechanisms I came up with alongside the export/ converter coder to speed things up for us, not just arbitrarily forced upon us, so they’ve been designed to do what we all want.
It’s all a question of time/cost efficiency. If I had to go over all the character meshes for our last character based game (35 characters) and make sure we had all the weights set just right (whether I had a tool showing the ones that need fixing or not) it would have taken too long. We had two artists for four months. No time for that stuff and plenty more things to do.
And of course some of these settings would vary depending on the platform too. The advantage of this process is that if for instance we had the same asset on the PS2 and Wii and the PS2 version only used two bones per weight and the Wii used four then that can be done for each platform independantly by the tools. The Wii one would be as we designed it and PS2 would be compromised to get the speed up. We wouldn’t have to edit the skin and save out two separate assets. As a for instance.
Oh yeah, and another advantage of this approach is that we don’t need to keep such careful track of outsourced assets. We can drop them in with less (often no) fixing up. There is still some stuff that needs fixing of course (naming issues chiefly of late, which is fair enough getting assets from non-english speakers) but those get output as error messages and are fairly easy to find and fix by hand from there.
I think you misunderstood my point. Four influences per vert is still the current limit on this generation of hardware. My point is that, auto-culling weights, when the model isn’t weighted to the correct number of bones, can (and will often) cause problems. This is true if culling from 6 to 4 or 4 to 2, or whatever. Skinning in particular should be fixed by the artist, I’ve often changed the number of bone influences to ‘4’ in Max and watched my skinning go to hell, I can’t imagine if I went down to 2. It requires deliberate weighting decisions, and I wouldn’t leave it in the hands of an auto-culler. On the other hand, PS2 spec models would have less of a problem (the problem gets worse with more bones and verts), and it does cost time. I’ve been in productions where the time is and isn’t worth it, so I know where you are coming from.
Oh yeah, and another advantage of this approach is that we don’t need to keep such careful track of outsourced assets. We can drop them in with less (often no) fixing up. There is still some stuff that needs fixing of course (naming issues chiefly of late, which is fair enough getting assets from non-english speakers) but those get output as error messages and are fairly easy to find and fix by hand from there.
Again, I guess it just comes down to allotted time. Auto-fixes are nice because they are, well, automatic, but nothing can beat artists fixing the non-automatic problems that are pointed out by a checker (I’d consider an automatic-fixable problem isolated verts or UV’s).