Question about continuous meshes for low poly bakes.
polycounter lvl 12
Hey all. I had a question that has been bothering me lately about low poly modeling.
I was told by someone on here in a thread that when they're doing their high poly models, they'll go ahead and use as many intersecting pieces of geometry as needed, but when they do the low poly they'll try and have as much of it welded together as possible.
I was hoping someone could tell me why people do this? What is the benefit?
In the following pic, I'd normally separate out each of those different colored sections as their own mesh, as that's how the high poly was.
I was told by someone on here in a thread that when they're doing their high poly models, they'll go ahead and use as many intersecting pieces of geometry as needed, but when they do the low poly they'll try and have as much of it welded together as possible.
I was hoping someone could tell me why people do this? What is the benefit?
In the following pic, I'd normally separate out each of those different colored sections as their own mesh, as that's how the high poly was.
Replies
Main benefits:
A. Better uv usage. You waste less space having to uv parts of the mesh that are partially/completely occluded, and you can have more continuous uv layouts which are easier to paint on(less uv islands).
B. The less unique mesh chunks you have, the easier your bakes are to set up. The less little separate mesh chunks you have, the less you'll worry about intersecting issues etc. Generally anything that doesn't move/animate or have complex overlap gets merged in my low meshes.
C. Spiting your lowpoly into lots of mesh chunks means more aliasing. Every edge that isn't merged between two mesh chunks is an edge that will alias and look bad in game.
Some reasons not to merge stuff:
A. It can cause some more extreme ray direction errors when you bake, that you may have to use a little more geometry to fix. Though here usually a few well placed verts will fix the issue, however, you may need a full extra edge ring in some cases.
B. It can use up a bit more geometry, so if triangle counts are very very low it may not be a good idea.
In addition to merging a lot of my lowpoly shapes together, I give a lot of thought and attention to exactly how my highpoly shapes line up. If you're sloppy here, and have a bunch of slight differences in how all your various pieces come together in your highpoly, you can end up with a mess in your low when you merge it all together(or very poor uv usage if you don't merge), with lots of thin little annoying strips to make up the small differences between the various shapes. so you really need to model your highpoly with specific lowpoly topology in mind. I rarely ever model a high poly object that I do not completely understand how the lowpoly will look, and have a rough idea of the geometry/polygon usage it will take to do it that way. Being careless here can cost a lot in terms of geometry count.
For reference, here is a mesh that is one continuous mesh chunk for the majority of the asset, separate chunks are used for items that will animate, be removed, and for the attachment rails at client request(to save triangles).
And here is what the high wires look like, how the low and high are constructed should have very little bearing on one another.
If I split up my low everywhere I split my high here, even for just the main segments, it would be massively wasteful.
Thanks for the awesome explanation and the info. I was already trying to keep as much of it merged as possible for the current weapon I'm working on. Glad to know it is a good approach.
Was a little worried about the extra tris it costs, but I suppose that matters less and less these days.
That gun looks sweet too. The bake looks awesome.
With things like that round bit I've pointed to, how did you get that to bake correctly? I recognize this gun from the Brink art dump and I read in that thread that you guys baked in maya.
I'm having a problem with baking a similar piece, as you can see in the next pic. Only way I know to fix it is to use hard edges, which I don't particularly want to, or to change the geo so that there is a vert right in the middle of that round bit. There's no vert in the middle of your bake so I was wondering how you pulled it off.
I didn't get that issue because there are a bunch of supporting edges cut in around that area and the mesh normals are very flat there.
If you're talking hundreds or 1000s of tris just to fix projection errors, or you have really strict poly budgets, its a nice trick.
I know having a vert right in the middle will fix it, I just couldn't figure out how you were pulling it off.
Here's how the geometry looks.
ZACD - I'd never even heard of Handplane. I always thought all the projection errors I get when I take models baked in maya over to marmoset were just due to bad modeling on my part. Probably still is, heh, but I can't wait to try that program out.
What you need to be checking is vertex normals. Once you do, you'll probably find that the vertex normals aren't perpendicular to the faces.
What you could do, is either adjust the vertex normals manually, or set up a cage so the rays in that particular area move along the faces normals.
bbox: editing the cage/envelope in Maya only affects ray distance, not direction(like in max).
Basically yes, bad modeling.
Handplane in itself won't fix your issues. Though it will allow you to create a copy of your mesh, cut in a bunch of supporting loops to fix ray errors, bake an object space map(in your baking app of choice) and then you can transfer that object space map down to the original mesh and output a tangent space map, so you'll save on your geometry count if you need to add a lot of supporting geometry to correct your bake.
The basic workflow is is described here: http://www.polycount.com/forum/showpost.php?p=817681&postcount=91 though I was using straight up object space maps at the time, so you'll do this + convert in handplane. You don't need to read that whole post, just the stuff on creating a duplicate mesh with extra edges cut in to correct ray projection errors. This post is really old and probably full of dumb advice, so read it at your own risk.
If you just have one or two areas that are giving you issues, its only a few extra verts or a dozen tris to fix it most likely, so its easier to just cut them in and leave them there.
Yeah that post is like 5 years old and I've changed the way I work a lot now. That was just how I did it back then, its sort of embarassing to look at now. :poly124:
And embarrassing for me is that that is how I do things now. Reading through that thread, its exactly like how I thought things were supposed to be done.
Building everything as one mesh is a bit of a pain, but I can see the benefits.