Do all polys have to be connected?
I've been going through a lot of portfolios for people creating game assets, and I've noticed that some of the pieces to a whole object arent fully connected by polys, they're just kinda "sitting/ floating" in the main piece. Is it ok to not have every thing fully connected in a model? For example, take a look at the SCAR that this guy created:
http://www.mikebrainard.net/IMG/fnscarh_wires.jpg
If you look closely, you will notice that some pieces aren't connected.
Is it ok to do that, especially if you are putting it into a game engine, such as UDK?
http://www.mikebrainard.net/IMG/fnscarh_wires.jpg
If you look closely, you will notice that some pieces aren't connected.
Is it ok to do that, especially if you are putting it into a game engine, such as UDK?
Replies
Here are some advantages of modeling solid
Baking setup is easier:
If you have a solid mesh there is rarely any reason to explode the mesh before baking. since there is no overlapping you just push the cage out and bake.
Baking results are better:
Since the entire mesh is solid you get much better quality concave bevels. when you split the mesh you tend to miss information when you are baking which creates seams and other artifacts. (these meshes could be much more optimal)
Also keep in mind that these problems get worse when the texture mips
Less Wasted UV space:
Because your not putting geometry ontop of geometry you end up with less invisible uv space.
This is the part I don't get. In an example like that, there's practically a 90' angle between the two parts, with the length of the cylinder being pretty long. So there's a good chance that they're going to have to be on separate UV islands anyway (especially in OP's example, where many of the knobs are more complicated in their nature and could also move around for animation, meaning they'd be physically seperate in reality). So wouldn't the UV map usage and mips be the same?
The seam on that example also looks a bit exaggerated towards bias too, as if no padding was used?
Im not advocating merging moving parts, just saying there are advantages to solid modeling, and making sure new modelers are not dismissing it.
The UV split doesn't change anything. the error is because the rays are not cast from a continuous surface. the cylinder and the plane are cast separately so you miss details and get a seam. (this is the same thing that happens with smoothing groups and ray distance)
Like Noors said about the padding, the renderer wont pad that area as it will pickup the high poly plane underneath and return the normals from it, again creating a seam. also FYI both maps were rendered with loads of bleed and 64 pixel padding.
Setup that example and bake it yourself if your critical.
I did, and I've seen quite a few examples of it being done and looking swell without sudden black lines highlighting the difference. Hence my confusion.
What Fletch is saying is entirely correct. Just look at his example. The less hard intersections the more seamless and "highpoly" your bake will look.
If you've got a complex mesh, the UV savings really start to add up, and you can cram random little bits into the "uv holes" created by merging bits together.
If you have split objects and bake them without explode baking, you can get some really nasty errors. Especially on complex meshes(ie: not a simple plane) where your mesh normals will be bent and the two objects simply wont match up without extra geometry to soften the normals(at which point any savings from split meshes is lost).
Personally I merge as much as I can, splitting meshes where things need to animate, parts can be toggled on/off or where bakes with become really complex and produce errors(complex overlaps etc).
Can you make nice looking meshes with lots of intersections? Sure, but it won't look as good, it will be more work, it will be less efficient with UV space, and it won't really save you many verts(which is generally the important thing, not triangles).
So whats the big benefit to doing it? Saving a tiny amount of time while doing the initial lowpoly modeling work?
In the split version there is a circular area in your uv tile which is dead space. In the merged version there is a circular hole which you can put other uv islands into
It may seem like a small saving but it adds up
the only way to use the space in an overlapping mesh is to do 2 bakes and merge them after the fact.
the UV's need to be split anyway, yes, but there is no extra space to UV where the mesh protrudes into the other mesh. Theres going to be extra space no matter what if you split the models because you need to have mesh padding so that the edge of the mesh you are inserting into another mesh doesnt show.
while this amount can be pretty negligible, it can add up.
this also, so i guess you just would add the top of that cylindar to the circular hole and have the side of the cylindar somewhere else as a UV island
everythings in sections and makes it more managable..
am no 3d expert tho and pretty much amature at it but am sure thats the case
You'd be suprised the time it can save actually. Since I've started merging i spend less time cleaning up my bakes.
yup
Yeah I really wouldn't bother with this, it would be way way more of a hassle than its worth, plus weird mipping issues and things of that nature, really not a good idea.
Your main problem is you think this takes a significant amount more of time to do. The extra lowpoly modeling should be extremely fast to do, and it saves massive amounts of time dealing with bake setup etc(especially doing test bakes, revisions, etc it really adds up). In reality it SAVES time.
Practice your modeling a bit if you would spend that much time merging meshes together. =P
I don't think this kind of modeling is significantly faster, merely I don't think it is as bad as it is being portrayed here.
Hey, you can do whatever you want, create models however you want, whatever gets the job done. But when it comes to giving advice to others on how to do things, its important to look objectively at the pros/cons of different methods. When one method has many cons and few pros compared to another, why insist on doing it anyway, or suggests others do the same?
Dude, that's not even the conversation. The guy wanted to know if every polygon had to be connected in game engines. They do not (as many games will prove), so that was my answer to him. I've yet to advocate one method over any other other, that just appears to be your assumption because I've been questioning the notion that such a practice instantly means a noticeable loss of UV space while creating large black seams around the connection. If AAA games are throwing out models that are made of several islands because they think the results are acceptable to them, I don't see how that warrants you trying to attack my own skill level?
Is this really necessary?
Anyways, these things are so context and situation based, I feel like sometimes it does save you some time to not make every surface contiguous, and other times it's necessary.
I kinda agree with cryrid, it's not the worst thing ever, but you don't want it up in your face with something like say an fps weapon model.
I'd try to make the context clear for people learning this stuff, that there's no right or wrong way... just what works for when.
A no go are Modells wo will be stretched animated or so on because the seams will be visible.
You DO NOT need to merge it all. With time and some mistakes you'll learn what to merge, what to intersect and what to float.
Its a perfectly legitimate point to make. If a large concern to an artist is speed when doing the lowpoly modeling using many intersections vs merging bits together then that artist's workflow is something that needs to be looked at. I've explained the various other benefits and how modeling merged meshes can really save on baking setup etc, to the point where its actually faster than modeling with a lot of intersections.
But at the end of the day, if you still think its slower to merge things together, that would suggest the bottleneck is lowpoly modeling speed. If this does not apply to you personally there is no reason to get defensive or upset.
Maybe I was a bit condescending and could have worded it better, for that I apologize.
Oh and to be a bit more clear, when I'm talking about this sort of thing I'm referring mostly to hero type assets where you would notice the difference between a merged(and thus seamless) mesh vs intersections. For less important assets or assets that won't be seen up close its really moot.
One more thing to note; certain engines require completely solid, seamless meshes. This means that when you intersect bits together, you still have to keep the backfaces. This is really inefficient and you're better off merging as much as you can at this point. These engines are becoming less common though thankfully, but I have worked on projects relatively recently that required this.
It can be either, but usually for physics systems you have a simplified or automatically generated(convex hull) mesh so it wouldn't be an issue.
Rendering wise, certain shadow systems require "water tight" meshes, there may be other reasons too but that is the most common that I know of.
I mean, if you have parts of a model embedded into OTHER parts of the same model, along with all sorts of overlaps, isn't that going to be a SERIOUS waste of rendering, since those "buried" parts aren't ever going to be seen by the eye, yet they WILL be seen, AND addressed by the engine? Also, I would've thought this kind of thing would cause problems with lightmaps.
I dont know if theres a right and wrong practice out of the two of them, but the "other" way just seems a bit dodgy for some reason, like your cutting corners. Maybe I just feel that way because I've always done it the other way.
thank you lol, I KNEW I wasn't crazy!
Yes its sort of an often overlooked part of the issue. If half your model is intersected into other parts(and I've seen this before with complex assets) you're rendering a lot of pixels that simply are never visible. Same with UV space. Its one of those things, have you ever seen a texture flat from someone where a massive % of the texture is black from AO? Too much intersecting bits, those are wasted pixels in terms of rendering on screen and texture space.
The common theory that most artists seem to operate under is "less triangles is better" without regards to how those triangles are used, how the uvs are used, and how many actual verts(verts + hard edges + uv seams + material breaks) are in the final mesh. Your actual ingame vert count is the most important number to performance, and the MORE polygons you have while keeping a reasonable vert count the better and more optimized your mesh is. Size and shape of triangles come into play too, but thats another thread....
Well, that works in some ways and doesn't in others, say you have a large "base" chunk and many smaller chunks that are slightly intersected, the lost uv space on the slightly intersected smaller bits is moot, but the lost uv space on the larger base mesh that has lots of intersected meshes adds up.
Its actually really easy to benchmark this, load up a model you've made, move any intersected parts that will animate off to the side(they don't count as they need to be model this way regardless), and bake AO from the (non-exploded)lowpoly mesh. All the large patches of black that are totally occluded are wasted uv space, if that = a significant % of your overall texture, there is room for optimization/merging. If its a small %, you're golden aside from other issues previously brought up like aliasing because of the split meshes and more complex bakes.
In my experience you usually run out of memory before you have so many polygons onscreen that it's actually a performance hit. Perhaps on the iphone it might be a problem.
I've modelled meshes using both these techniques in both max and
Maya an wanted to clarify one thing. - wouldn't sometimes it be a must to have meshes that aren't connected in models I.E organic or character models?
Prime example: bullets, helmet, backpack etc wont be modelle to the mesh
http://forum.i3d.net/attachments/battlefield-series-news/943229798d1310663537-battlefield-3-offdutygamers-breakdown-character-models-bf3-support.jpg
I'm not saying it's a good or bad thing I recently modelled a low poly character with a similar design of bullet belts etc and although the polygons are not connected the object groups are all merged and in one bake... Didn't find a problem with the textured seams either..
Wouldn't want to cause more aggro but I would like further clarification on my example if possible for a student who requires knowledge!!
Cheers
There's no reason why you couldn't model the helmet or backpack into the mesh. It depends.
It might be better for animation to model the helmet separately so you can have it move around independently.
But it might work better if you have it modeled into the head because you don't need to texture the hair and there's no chance you'll get weird intersections (hair showing through helmet etc). It also may LOD better.
Yeah, I guess for students or what not it's probably important to point them in a path that's good 100% of the time.
I'm always surprised how little is understood about this artform for people getting into it.. so much fking stuff to learn and understand.