Ditto, when I uv, I separate my model off into various chunks and work on them one at a time, making sure each small section has really polished uvs, then I make sure the scale on each individual "mini uv" is consistent, and scale up the detail areas. This also helps to keep similar UV items near their buddies in the layout. One of the worst things you can do is pack uvs randomly with no relation to the elements in 3d space. When I have my solid uvs and texal density set up, only then do I start packing
Everything EQ said. I don't think the model is ready for UVs yet though. The model itself needs work, especially in merging shapes. This will again benefit your UVs, because your UV islands will be merged as well, reducing the number of seams.
As you pointed out in one of your draw overs you suggested combining the fire selection switch/safety and the main body of the gun. I attempted to do this a few days ago but it kept producing bake errors. I made the selection switch + body one object on the LP but they remained 2 separate objects on the HP, so that may be the problem. Does the LP have to coincide with the HP in how many objects a part is to work correctly?
Here is a complete list of the separate parts that may be need to be merged. As well as me guessing what else might be merged besides the fireselction switch to the body.
Your uv density is all out of whack. Many areas that are seen close up have half the density of areas that are farthest from view. You should find a script to unify your uv density, then go in and scale up all the stuff that is clear in FPV, then repack it all.
Initially I thought thats what I did. After everything was unwrapped I selected all the objects and "normalized" them with the relax by face angle tool in max. After doing so I went in and scaled up important parts such as the body and handle. But yes the texel resolution clearly needs to be upped in parts as you stated.
Seriously, EQ and per went all Bob Ross up this bitch.
I love it. I need experienced straight shooters such as EQ and Perna to provided their valuable input. Because clearly I have no experience doing anything in the pipe line except SubD modeling.
Oh just a note, the selector switch, and the trigger, would generally both be separate meshes, as they could potentially animate independently. I don't think Per realized these were separate elements, because he's not a big gun nut. I meant to mention this before but forgot about it.
Looking at the previous page, 5, here it doesn't look like you took perma and EQ's advice too much. IMO the model still has tons of screwball edges and modeling strangeness to it. I think you need to concentrate on cleaning up the geometry and using less edges for the same effect before you worry about baking and such. My 2 cents
You merge literally everything, unless you have a compelling reason not to.
so, to put that another way: You don't decide what to merge, you decide what not to merge, which is stuff like the safety switch (because you need to be able to animated it), clip and attachments (if you want to be able to remove them). Merge everything else. Worry about baking later. You fix that with smoothing groups and corrective geometry.
The only parts from my model that have any compelling reason to keep as separate parts are as follows: magazine, front handle, trigger, fire selection/safety and a latch on the side that slides after reloading I believe. Everything in the below image then must become one LP mesh then if I am understanding you correctly. Also per I still need to change some LP parts on the handle that you pointed out on the paintover e.g. the edges on top that I made stick out that are actually flush etc.
If the images above are the correct understanding, then this is my WIP of conjoining the shapes.
Right track before I proceed conjoining shapes further?
@n88tr, feel free to reply to my PM in this thread. I didn't wan't to clutter this thread too much.
Conjoining/merging Update. I am curious, for most of the tutorials I read they state the reason to keep a gun as many different separate meshes is because it allows you to explode it and get good AO bakes with everything apart. Is it problematic at all for AO bakes when the gun becomes only a few separate meshes?
Ideally you want AO bakes with everything together. Otherwise the stuff that's occluding the light isn't in the correct places and you don't get a proper representation of the AO.
Just explode out all the parts that would be animated and have obviously misplaced AO should they move (e.g. the top of the magazine that's in the gun shouldn't have AO on it because if it's removed from the gun, the top of it would appear to stay in shadow even though it's not - or the cocking lever leaving an AO shadow at it's original position even when it's drawn back).
For normal bakes you may want to explode some bits apart if they end up on the bake of another part of the weapon (i.e. the ray travels too far and picks up another part of the weapon) but normally just doing a few bakes at different distances and merging into one final normal map is usually good enough.
I'd try not to tweak the cage's verts other than the projection distance because it means you (or, even worse, someone else) have to replicate all the tweaks whenever the model is edited and re-baked.
1.
It is a common mistake to think that you need to work with the exact same model when uvwing, baking normals/AO/whatever (in the same scene even, if you are working with max) You create clones. I've seen were people actually create animations so once they'v exploded the model, the can rewind and get it back to its former assembly, but why I have no idea. It doesn't cost you any extra to make clones of your model.
2.
The only thing that needs to be intact is the model geo itself:
vertices indexing vs uv's,
Uv splits should coincide with the geo splits ofcourse (smoothing groups)
3.
The only time you actually want to explode your model is when you know you have intersecting cages that will create artifacts, if you don't have that, you really don't need to explode the mesh.
4 . To make a proper AO you need to let the model be assembled as it would be if it was hit by AO rays. Meaning, if you have a skylight, geometry that are hidden or covered of other geo, should naturally not get as much lit as other parts. So for the AO, you probably have to live with getting artifacts, but often you go and post work it a bit.
5. Read through what the pro's been telling you here, again. :P
As far as AO goes, actually, the less elements you have the easier your AO is to bake. Generally I will create a high AO pass, and a low ao(lowpoly in base position) pass, so that all AO is taken into account. Some people like to bake AO unexploded, but this results in lots of errors and is a pain in the ass.
Really, you should follow the same workflow for your normals and your AO, not bake one way here and another there, this will be a mess.
So no, I think you're thinking of it backwards, it is helpful when you have a small % of meshes for AO, not harmful.
Metalmind: You make keyframe bakes because it is a pain in the ass to duplicate and work with multiple meshes, there just really is no need to do this. With simple keyframes you can easily edit your mesh, and just slide the keyframes back and forth from the base to bake position, working with multiple versions is just messy, and saves you absolutely no time, which is why it isn't advised.
My rules of thumb for mesh chunks:
1. Merge as much as possible
2. Never merge bits that need to animate
3. Take care merging areas that have complex and strange intersections, sometimes you will need to separate some stuff to avoid errors when your cage is expanded, it little nooks and shit the cage can collapse in on itself
4. Sometimes I will have 2 or 3 main chunks for the base of my asset(not counting animating details). This can be a little easier to deal with at times, and again, may help with #3.
4 . To make a proper AO you need to let the model be assembled as it would be if it was hit by AO rays. Meaning, if you have a skylight, geometry that are hidden or covered of other geo, should naturally not get as much lit as other parts. So for the AO, you probably have to live with getting artifacts, but often you go and post work it a bit.
This sort of stuff really confuses me, your AO sould be baked the same as your Normals, if you've got errors on your bake, you fix your mesh and both AO and Normals are fixed. Do not waste your time painting over your maps in photoshop post-bake, instead spend that time figuring out WHY you get errors and understanding how to avoid them in the future, eventually, you'll be able to create meshes that simple bake with one click on the first try(or after a few simple tweaks).
Also, if you manage to merge everything BUT the areas that will animate, you will have a *perfect AO bake* without any extra work, as you never want intersecting AO on animating mesh chunks. With the high + low workflow, you need to mask off your animating chunks, or leave them exploded when you bake the low ao.
As far as AO goes, actually, the less elements you have the easier your AO is to bake. Generally I will create a high AO pass, and a low ao(lowpoly in base position) pass, so that all AO is taken into account. Some people like to bake AO unexploded, but this results in lots of errors and is a pain in the ass.
When you say exploded/unexploded, you're talking about exploding the moving elements only, not the whole thing, right? Because I can't see a reason to bake things exploded that aren't modular/repeated bits or moving parts.
What do you gain from the lowpoly AO that you don't get from the highpoly AO?
Exploding any parts that would animate, or any parts that would cause ray intersection problems. With the low AO, you gain AO on the intersections between parts that are exploded, but wouldn't otherwise animate, so static exploded chucks. With a complex mesh, this is common to do.
This is important to "tie everything together" when baking your AO from the exploded position(which really is highly recommended).
ah okay, so you're using the low AO for the bits you split up due to ray intersection issues then?
For the ray intersection issues, I will explode the low and then dupe the relevant part of the high, excluding one half of each high poly piece from the projection on the low, so I get the high poly AO on both parts but only raycast normals from one piece.
in this image, the red high poly pieces are excluded from the projection and only lending shadow information for AO.
You can sometimes end up with issues where the AO needs a bit of cleanup because the AO breaks at the high poly intersection but it's usually just painting a few pixels and gives you a cleaner AO shadow than compositing a low and high together I would imagine.
But aren't you then left composting multiple bakes together or something? I've seen a lot of silly AO workflows posted on polycount, most of them seem like much more of a hassle then its worth.
Also, what app? The methods me/per talk about will work in max, maya, xnormal, etc all the same. Being able to carry your workflow from app to app is very important imo, if you're a freelancer its super important, but even changing software in-house, or working at various studios, means you likely wont be able to count on "X trick" in max for everything(tweaking cages for instance, as it doesnt work the same way in maya).
...My high+low AO workflow is up there, if maybe a bit outdated(like saying make a copy instead of keyframe =P)...
:P
What I meant with the AO, is that you can get away with artifacts because the AO won't interact with the engine as the normals do, since most of the time its an add-on to the diffuse. Fiddling out the AO artifacts post could be easier, if you're not a pro and can't always plan your bakes to a "one-click-bake", like me ;P. I'll just go back to my cave now. :P
Also, I think Pedro is after me. Or was it just a dream...
But aren't you then left composting multiple bakes together or something? I've seen a lot of silly AO workflows posted on polycount, most of them seem like much more of a hassle then its worth.
You're compositing with the high/low and making two bakes, aren't you? How are you rendering a low poly AO with the tricky-bits unexploded and a high poly AO with the tricky-bits exploded without doing 2 bakes and compositing?
This is one bake - the low-poly is exploded and the low-sphere is aligned with the green sphere, with the red box excluded from the projection map so all it is doing is adding to the AO/lighting. Additionally, this way I'm getting high poly AO all around.
This is Max specific but it's a single-bake system that doesn't require me to do multiple bakes - I can mash one button and get everything I need, no key-framing multiple bakes required.
Yes, you'll end up with two AO layers instead of one in your PSD(but little manual editing), but this still seems way faster than what you're suggesting, especially for something with any sort of complexity. Also, keyframes take like 10 seconds to set up, I'm confused why you seem to think this will take all day to do. Certainly faster than making multiple copies or your meshes and setting up all the exclusion options and all this stuff.
In reality you're doing exploded workflow(just not setting up keyframes) + the weird AO exclusion thing.
And i'm doing exploded workflow + unexploded low bake
Maybe i'm just being an idiot here though, i'll try to look into it a bit more later. It seems like you would still benefit from keyframing your low(possibly your high as well). Theres no reason to keep two copies of your low in this instance it would seem.
Maybe i'm just being an idiot here though, i'll try to look into it a bit more later. It seems like you would still benefit from keyframing your low(possibly your high as well). Theres no reason to keep two copies of your low in this instance it would seem.
There aren't 2 instances of the low. The low is exploded but is one object (the sub-objects are exploded).
You can keyframe it or not, it doesn't matter, but the point is mine gives me one bake that's accurate to the high without me requiring multiple AO bakes, one for the high, one for the low, with the low in different positions for each bake.
My point is to exclude the bake of the low-AO, as I'm not aware of any time it will give me a superior AO map, given that it sounds like you only use the low to make up for areas where you've exploded both meshes to fix ray miscasts for complex
Sure, I get the concept. I think initially I didn't entirely understand what you were saying. I'm gonna do some tests and see if I can sort of simplify the idea and translate it to maya/xnormal as well.
How do you generally explode your low? In max its really easy just to keyframe by element, you dont need to split your mesh up or anything, then you can quickly switch bake from the base position, to the bake position, which can be very useful when doing revisions and such, test bake, preview end result, test bake, etc etc all by just scrolling the keyframes. So if you're doing this by hand, I think you'd see the benefit of using keyframes.
Sure, I get the concept. I think initially I didn't entirely understand what you were saying. I'm gonna do some tests and see if I can sort of simplify the idea and translate it to maya/xnormal as well.
How do you generally explode your low? In max its really easy just to keyframe by element, you dont need to split your mesh up or anything, then you can quickly switch bake from the base position, to the bake position, which can be very useful when doing revisions and such, test bake, preview end result, test bake, etc etc all by just scrolling the keyframes. So if you're doing this by hand, I think you'd see the benefit of using keyframes.
With our current tools I have to export a copy of the preview mesh and view it outside of Max to get proper normals, so having a preview of the bake in my bake file is rather useless. Previously I'd just have a test unexploded mesh hidden in the scene with my shader on it, but that's personal preference more than anything.
I'm not against keyframing the mesh explosion, just the notion of rendering two separate AO passes when I can do one
A. select your highpoly element(s)
B. key them at frame 0
C. key them at frame 10
D. move them at frame 10
E. Repeat for low
F. Repeat for the rest of the elements.
A. select your highpoly element(s)
B. key them at frame 0
C. key them at frame 10
D. move them at frame 10
E. Repeat for low
F. Repeat for the rest of the elements.
Yes, you'll end up with two AO layers instead of one in your PSD(but little manual editing), but this still seems way faster than what you're suggesting, especially for something with any sort of complexity. Also, keyframes take like 10 seconds to set up, I'm confused why you seem to think this will take all day to do. Certainly faster than making multiple copies or your meshes and setting up all the exclusion options and all this stuff.
I dunno, I fixed up the AO for a character yesterday.
At the projection distance that got most of the big forms, some of the small detail ended up clipping through and catching the bake from the mesh above it.
So I just ran another bake at a tiny projection distance and slapped that on top of the other in PS and masked out the small distance bake to ensure I got the best bits of both.
AO bake in modo took all of about 15 seconds a pop at 2048. I think the entire process took me maybe 20 minutes whilst eating my sammich, it's really not that much work.
And no messing around with exploding meshes, either.
I dreamt you wanted some bromance with me, or that you wanted to kill me, please to don't kill me, I have many sheeps to feed =((
I can be a fat polish girl for proper money. =(
EQ: I don't remember the animation process been explained that simple, but now that you put it down so simple, my two braincells went "duh" :P. I probably just confused the thread creator a bit there now that I re-read my input. Thanks for clearing things out man.
I don't think the model is ready for UVs yet though. The model itself needs work, especially in merging shapes.
WIP, Right direction? thumbs up or thumbs down? I dont want to trouble you with a paintover or anything.
A. This part can look flush depending on the reference, but I have several that show that these parts do not appear flush, but all of them have some perspective distortion on them as well so take this with a grain of salt. In addition, I used to own the gun and I do not recall this part sitting flush. Also this area is for iron sights, and the extrusions might make it more interesting in FPV
Better topo for B as show below possibly?
C. Messy areas previously pointed out by Perna, hopefully this topology is more acceptable.
Exploded parts
Thanks again everyone.
EDIT: just noticed there s a whole loop I can remove on the magazine.
WIP
I selected all objects and did a quick planar map as perna suggested, and broke off individual parts and relaxed them. Not worrying about packing, just keeping UV density the same with normalized clusters off so the scale is similar for all objects. I am not certain I corrected the weird seam EQ pointed out on the grip (since I am not entirely sure what constitutes a weird seam in this case), but hopefully my new rendition is better. Hopefully a significant improvement over my last iteration.
Need to:
-Check for slightly rotated parts as EQ suggested and align more edges
-Check seams
-look at the larger pieces such as the body, and see if anymore pieces can
be stitched together/quick planar as one piece.\
-adjust harsh edge on the front grip handle.
Pack WIP. I hope this is a Significant improvement from last time. In terms of number of seams and UV islands and texel resolution. I hope there is an appropriate amount of padding room for baking/mipmapping
Below shows me attempting to clamp down too much resulting in poor stretching and resolution problems. In the WIP shot above(figure A) I am not really happy with the banana shape it has since thats not very efficient, but at least there is no distortion. Additionally, I need to scale up some of the parts that are in FPV, but I am unsure how much to do so. I don't want it to look uneven in the texel/pixel density like it was in my last attempt.
You have an extreme amount of seams. Why do you use so many UV seams everywhere? A lot of them seem randomly placed, too, like in areas where there's a soft angle on the seam, which should never happen.
Your first step is to keep smoothing groups to an absolute minimum, split UVs at the smoothing group borders and do quick test bakes to test whether it holds up, then you can proceed with the rest of the UV mapping.
Thanks again Perna, I really appreciate it. I thought the amount of seams I had was a significant reduction from last time, but clearly not enough, thanks for the input.
No seams on soft angles, I understand now I think (check WIP shot below for confirmation). However, areas that have many 90d angles are still split into a bunch of groups are a little more troublesome for me to grasp, such as the handle. On one hand you want a split at 90d angles at the very least I thought, but on the other hand doing so in an area like this breaks it into numerous pieces. How would you recommend I approach a piece like this with so many hard 90d angles,thus many seams currently.
Is the shot below a correct example of removing seams from soft angles?
Up close shot of the handle, unmodified from last time (this is not a subtle request for a paintover)
Well, unless the model is going into unreal or something, which has fucked tangent bias, then you will want to avoid excessively stitching UVs.
However this is a choice that should always be made depending on where the asset is ending up. If you're going to display it in the viewport, with a quality shader that has synced normals, 3ps in max, the latest max with the tangent fix, maya, or exporting to an engine that has synced up normals, then use as few UV islands as possible.
So you really need to understand where the asset is going, and use judgement in this case, if you know you're exporting the model into a broken engine, you'll want to be liberal with you UV seams on hard 90 degree angles. Much more important than following a "Never use smoothing groups" or "Use smoothing groups on 90 degree" rule, is simply understanding where your asset is going, and adjusting accordingly. This is where doing test bakes is key.
Also I personally try not to get too excessive with welding uv borders, as it can make UV packing much more difficult, when you end up with the weird shapes and such. In reality, if the texture artist needs to paint a lot of unique details over seams and such, he's gonna do it in a 3d app anyway, so, i mean if you've got one less seam here, but it causes a smoothing error, it isn't helping anyone.
If you know for a fact you want to paint X detail over X shape, it can be good to use extra geometry to account for any smoothing issues, and keep the UVs solid, this lets you deal with both issues at once.
Oh also, I think Per is trying to say keep your UVs simple in the start, while you're still doing test bakes, and only start splitting them up, where needed, after you've done your test bakes and find problems. This I totally agree with 100%.
[edit] With those last images, you should have a central loop running down the middle of the grip area, this is where your uv seam should be. you've got this tiny planar strip there, and it doesn't make any sense. Cut a loop down the middle, and round that area out a little with those 2 loops that are planar now. When mirroring, you should generally have a central loop.
[edit] you've got this tiny planar strip there, and it doesn't make any sense.
Very good thanks. Perna pointed this out several pages back, and believe it or not that was actually the next thing I was going to work on before I checked the responses in this thread.
Here was pernas original paintover for the grip area showing the problem you speak of.
Anyways, something like this EQ? Also I think I may need to round it a little more.
Yes, that is the basic idea. I'm going to bring back some stuff all the way from page one, because you're still essentially making the same mistakes here.
soften up those lines on the grip! its a nice cylindrical shape that has a smooth transition into the planar base, but you've got a hard edge and an angled thing going on.
Like A, not B.
This is just a small chunk and not accurate to the ref, but the concept applies to most of the shapes here.
Also, keep in mind that this cylindrical shape is uniform and even throughout the entire front/rear grip area, only changing in the couple spots where there are cut-outs. In your mesh it has a lot of variance.
No, both A and B. The bottom of A is actually mostly ok, but it still looks a little uneven and sloppy.
The curves here in red are all the same uniform, smooth shape. Its basically just a simple half cylinder extruded to create this shape, and then 1 supporting edge(like in the first image I posted) to retain the edge there.
You seem absolutely determined to model a cylindrical shape, using any and all means except starting from a.... cylinder. What you've got here now is just a mess, so I made a little gif.
A. Place half cylinders along the straight edges of your shapes. All of the curves are exactly the same width, so all of our cylinders will be the same size. I used a 12 sided cylinder, which gives us 6 faces here - a good amount.
B. Extrude the shape of the curve, giving an appropriate level of detail(number of segments) to the curves so they all look "curved" and not blocky. I used the "curve extrude" tool in modo, which is really fast and ensures a nice, evenly spaced and curvy result. You can do this by hand or with a similar tool in max i'm sure, whats important is the end result, and that you're not tweaking individual verts. This is a vert specific geometric shape, so we shouldn't be moving verts around by hand here.
You could give/take an edge loop here or there from this example, it was just to quickly show the concept, not necessarily to model exactly as shown.
C. Join segments together, using bridge or whatever tools
See how nice this looks? Really, this is how your highpoly should have been modeled in the first place, then it would have been super easy to translate it to a low. This took just a minute or two to model.
Next step is to remove the 90 degr seams (make sure you perfectly understand the relationship between SGs and UVs first).
In summary here is my understanding:
-Have as few UV splits as possible keeping smoothing groups in mind, they should be used sparingly. Because the more smoothing groups, the more UV splits, the more UV islands, the more likely your texture artist will kill himself.
-Dont excessively weld parts together for the sake of welding stuff together if it produces a smoothing group error
With that being said here is my latest WIP, am I on the right track?
For the magholder, I would like it to be even less UV islands if possible; however, I am getting significant texel stretching if without breaking certain parts off.
Yes, that is the basic idea. I'm going to bring back some stuff all the way from page one, because you're still essentially making the same mistakes here.
Many thanks for the .gif and pointers. Is this Better? Not sure why I started with a box either, probably because I used some of my block in mesh to create the HP without realizing I was making this mistake. Otherwise I dont think I would have normally modeled whats essentially a cylinder with a box. Thanks!
That bottom uv is exactly what I mean by excessively welding stuff together, you have that bottom quad sticking way out in the layout, and it will make it a pain in the ass to pack. In this case, that quad should have been welded to the bottom, not the side anyway.
I have to say I'm pretty confused with your rail geometry. Some rails are modeled solid, while others are separate meshes? You can also save some geometry on the rails if you remove the "curve" of the rails, from the low and the high - this isn't in your ref. So just kill that center loop, and flatten it in the high as well.
I have to say I'm pretty confused with your rail geometry. Some rails are modeled solid, while others are separate meshes? You can also save some geometry on the rails if you remove the "curve" of the rails, from the low and the high - this isn't in your ref. So just kill that center loop, and flatten it in the high as well.
I was attempting to follow what perna suggested on the end post of the previous page where he said:
you shouldn't instance the same UVs for each of the teeth there, it will look too obvious. Have a few unique ones, especially at the ends (as they will have more wear/tear showing)
Before each one of the teeth on the rail was an instance, and that wasn't going to allow for unique detail, and as perna noted would be obvious that they are all the same instanced copy. Therefore I welded a few of the teeth down on either side for unique texturing. But I suppose I could just have multiple Unique non instanced teeth floating and keep them separate objects without having to instance all of them or having to weld them down to the cylinder. And thanks for pointing out the center line I will remove that.
Yeah, all you had to do was select a few of the teeth in UV and move them elsewhere, not change anything modeling-wise. The modeling part is just confusing, some teeth merged and some not, doesn't make much sense there
Ok thanks, done.
Since the individual islands are looking ok I am proceeding with the final UV layout WIP. Before doing so I did a quick pack and test bake to verify there were no problem areas, and it looks fine.
Current WIP
While doing this I tried to keep in mind:
-Leave enough padding room for baking and mip mapping
-Keep related UV islands together
-objects have the same orientation in UV as they do in 3D (with the exception of a few parts such as the magazine, had to rotate that to fit it in with this current iteration)
- No slight rotations of objects, clamp down edges where possible
In addition I need to scale up the parts that are closest in FPV, but I am uncertain how much I need to do so.
Here you're packing everything before doing test bakes, or scaling up appropriate detail areas. tisk tisk....
I do 125% for close up areas, and 150% for areas that will be zoomed in on(iron sights and scopes, generally). Areas that will rarely/never be seen, I scale down as well. like the insides of parts that are totally occluded.
Sorry to let you down guys. I just reread the whole thread back from where UVs started to come up as the topic of discussion. I actually did do quick test bakes on the above pack, but that doesn't matter since my final product is wrong.
So in sum this is what I need to do to end with a good result next time. I dropped the ball at scaling up the detailed areas, and instead had final UVs as islands that were all uniform in texel resolution and packed them that way which was a waste of time.
1. Make UV islands uniform in density
2. Before laying out final UVs quick auto-pack and test bake with no SG use, find problem areas, add SG where needed. Add corrective geometry if needed.
3. Go in and scale up detailed areas 125/150% and scale down occluded areas (e.g. the bottom area of the mag holder no one will ever see)
4. Make Sure UVs are final at this point
5. Proceed to final uv packing ASSUMING your temporary quick packing + test bakes are error free
Does the above look correct to get on the right track? I was under the impression as far as seams and islands were concerned, they were acceptable based on pernas reply where I showed the old and new objects with their seams and UV islands. As well as LP merging to reduce the amount of seams. Pernas comment "Just saw Joe's reply.. there's more too.. your asset.. is not ready at all for uv packing, and you haven't followed previous advice for uv density" is phrased such that it sounds like there are other components wrong besides the density at this point.
Yeah, that pretty much covers it there. Here are a couple more:
6. Do another test bake
7. Another round of corrective geometry or smoothing group tweaks - I'll often find one or two little things after my final uv pack is set, that I didnt notice with the quick bakes
8. Prepare for final bakes
- Explode high/low
- Make sure highpoly meshes have RGB, or RGBCMYW colored materials assinged so you can easily bake material masks
- Make sure any floaters are set up properly, ie: as seperate meshes and have shadow casting turned off(or whatever you do in max, i think thats it)
Step 1 Make UV islands uniform in density using textools. Also below are images of areas I plan on scaling up for step 2. Using the failed pack above as a temporary pack.
FPV up close areas +125% scale:
1. Silencer
3. Nitrotac
4. Grip
6. Trigger
7. Safety
FPV Zoomed areas +150% scale:
2. Body (body includes handle and ironsight areas since this is all one mesh now)
5. Laser sight
On the right track? Ready for step 2? For totally occluded areas how much would you generally scale down %?
Silencer is furthest thing from FPV view, why would it need to be scaled up? the stuff you scale up is going to be closest to FPV. You dont need to scale up the entire sections either, generally just a uv island that is facing backing towards the camera or whatever.
Silencer is furthest thing from FPV view, why would it need to be scaled up? the stuff you scale up is going to be closest to FPV. You dont need to scale up the entire sections either, generally just a uv island that is facing backing towards the camera or whatever.
Thanks.
Here is what I am thinking with that critiques logic
test bakes, sg where needed, corrective geo etc. Basic renders with max 2.5 star so some antialiasing issues, will probably use hammersly for finals which should remove them.
Replies
As you pointed out in one of your draw overs you suggested combining the fire selection switch/safety and the main body of the gun. I attempted to do this a few days ago but it kept producing bake errors. I made the selection switch + body one object on the LP but they remained 2 separate objects on the HP, so that may be the problem. Does the LP have to coincide with the HP in how many objects a part is to work correctly?
Here is a complete list of the separate parts that may be need to be merged. As well as me guessing what else might be merged besides the fireselction switch to the body.
Initially I thought thats what I did. After everything was unwrapped I selected all the objects and "normalized" them with the relax by face angle tool in max. After doing so I went in and scaled up important parts such as the body and handle. But yes the texel resolution clearly needs to be upped in parts as you stated.
I love it. I need experienced straight shooters such as EQ and Perna to provided their valuable input. Because clearly I have no experience doing anything in the pipe line except SubD modeling.
The only parts from my model that have any compelling reason to keep as separate parts are as follows: magazine, front handle, trigger, fire selection/safety and a latch on the side that slides after reloading I believe. Everything in the below image then must become one LP mesh then if I am understanding you correctly. Also per I still need to change some LP parts on the handle that you pointed out on the paintover e.g. the edges on top that I made stick out that are actually flush etc.
If the images above are the correct understanding, then this is my WIP of conjoining the shapes.
Right track before I proceed conjoining shapes further?
@n88tr, feel free to reply to my PM in this thread. I didn't wan't to clutter this thread too much.
Just explode out all the parts that would be animated and have obviously misplaced AO should they move (e.g. the top of the magazine that's in the gun shouldn't have AO on it because if it's removed from the gun, the top of it would appear to stay in shadow even though it's not - or the cocking lever leaving an AO shadow at it's original position even when it's drawn back).
For normal bakes you may want to explode some bits apart if they end up on the bake of another part of the weapon (i.e. the ray travels too far and picks up another part of the weapon) but normally just doing a few bakes at different distances and merging into one final normal map is usually good enough.
I'd try not to tweak the cage's verts other than the projection distance because it means you (or, even worse, someone else) have to replicate all the tweaks whenever the model is edited and re-baked.
It is a common mistake to think that you need to work with the exact same model when uvwing, baking normals/AO/whatever (in the same scene even, if you are working with max) You create clones. I've seen were people actually create animations so once they'v exploded the model, the can rewind and get it back to its former assembly, but why I have no idea. It doesn't cost you any extra to make clones of your model.
2.
The only thing that needs to be intact is the model geo itself:
vertices indexing vs uv's,
Uv splits should coincide with the geo splits ofcourse (smoothing groups)
3.
The only time you actually want to explode your model is when you know you have intersecting cages that will create artifacts, if you don't have that, you really don't need to explode the mesh.
4 . To make a proper AO you need to let the model be assembled as it would be if it was hit by AO rays. Meaning, if you have a skylight, geometry that are hidden or covered of other geo, should naturally not get as much lit as other parts. So for the AO, you probably have to live with getting artifacts, but often you go and post work it a bit.
5. Read through what the pro's been telling you here, again. :P
Really, you should follow the same workflow for your normals and your AO, not bake one way here and another there, this will be a mess.
So no, I think you're thinking of it backwards, it is helpful when you have a small % of meshes for AO, not harmful.
Metalmind: You make keyframe bakes because it is a pain in the ass to duplicate and work with multiple meshes, there just really is no need to do this. With simple keyframes you can easily edit your mesh, and just slide the keyframes back and forth from the base to bake position, working with multiple versions is just messy, and saves you absolutely no time, which is why it isn't advised.
My rules of thumb for mesh chunks:
1. Merge as much as possible
2. Never merge bits that need to animate
3. Take care merging areas that have complex and strange intersections, sometimes you will need to separate some stuff to avoid errors when your cage is expanded, it little nooks and shit the cage can collapse in on itself
4. Sometimes I will have 2 or 3 main chunks for the base of my asset(not counting animating details). This can be a little easier to deal with at times, and again, may help with #3.
This sort of stuff really confuses me, your AO sould be baked the same as your Normals, if you've got errors on your bake, you fix your mesh and both AO and Normals are fixed. Do not waste your time painting over your maps in photoshop post-bake, instead spend that time figuring out WHY you get errors and understanding how to avoid them in the future, eventually, you'll be able to create meshes that simple bake with one click on the first try(or after a few simple tweaks).
Also, if you manage to merge everything BUT the areas that will animate, you will have a *perfect AO bake* without any extra work, as you never want intersecting AO on animating mesh chunks. With the high + low workflow, you need to mask off your animating chunks, or leave them exploded when you bake the low ao.
http://wiki.polycount.com/AmbientOcclusionMap?action=show&redirect=Ambient+Occlusion+Map
My high+low AO workflow is up there, if maybe a bit outdated(like saying make a copy instead of keyframe =P).
When you say exploded/unexploded, you're talking about exploding the moving elements only, not the whole thing, right? Because I can't see a reason to bake things exploded that aren't modular/repeated bits or moving parts.
What do you gain from the lowpoly AO that you don't get from the highpoly AO?
This is important to "tie everything together" when baking your AO from the exploded position(which really is highly recommended).
For the ray intersection issues, I will explode the low and then dupe the relevant part of the high, excluding one half of each high poly piece from the projection on the low, so I get the high poly AO on both parts but only raycast normals from one piece.
in this image, the red high poly pieces are excluded from the projection and only lending shadow information for AO.
You can sometimes end up with issues where the AO needs a bit of cleanup because the AO breaks at the high poly intersection but it's usually just painting a few pixels and gives you a cleaner AO shadow than compositing a low and high together I would imagine.
Also, what app? The methods me/per talk about will work in max, maya, xnormal, etc all the same. Being able to carry your workflow from app to app is very important imo, if you're a freelancer its super important, but even changing software in-house, or working at various studios, means you likely wont be able to count on "X trick" in max for everything(tweaking cages for instance, as it doesnt work the same way in maya).
:P
What I meant with the AO, is that you can get away with artifacts because the AO won't interact with the engine as the normals do, since most of the time its an add-on to the diffuse. Fiddling out the AO artifacts post could be easier, if you're not a pro and can't always plan your bakes to a "one-click-bake", like me ;P. I'll just go back to my cave now. :P
Also, I think Pedro is after me. Or was it just a dream...
You're compositing with the high/low and making two bakes, aren't you? How are you rendering a low poly AO with the tricky-bits unexploded and a high poly AO with the tricky-bits exploded without doing 2 bakes and compositing?
This is one bake - the low-poly is exploded and the low-sphere is aligned with the green sphere, with the red box excluded from the projection map so all it is doing is adding to the AO/lighting. Additionally, this way I'm getting high poly AO all around.
This is Max specific but it's a single-bake system that doesn't require me to do multiple bakes - I can mash one button and get everything I need, no key-framing multiple bakes required.
In reality you're doing exploded workflow(just not setting up keyframes) + the weird AO exclusion thing.
And i'm doing exploded workflow + unexploded low bake
Maybe i'm just being an idiot here though, i'll try to look into it a bit more later. It seems like you would still benefit from keyframing your low(possibly your high as well). Theres no reason to keep two copies of your low in this instance it would seem.
There aren't 2 instances of the low. The low is exploded but is one object (the sub-objects are exploded).
You can keyframe it or not, it doesn't matter, but the point is mine gives me one bake that's accurate to the high without me requiring multiple AO bakes, one for the high, one for the low, with the low in different positions for each bake.
My point is to exclude the bake of the low-AO, as I'm not aware of any time it will give me a superior AO map, given that it sounds like you only use the low to make up for areas where you've exploded both meshes to fix ray miscasts for complex
How do you generally explode your low? In max its really easy just to keyframe by element, you dont need to split your mesh up or anything, then you can quickly switch bake from the base position, to the bake position, which can be very useful when doing revisions and such, test bake, preview end result, test bake, etc etc all by just scrolling the keyframes. So if you're doing this by hand, I think you'd see the benefit of using keyframes.
With our current tools I have to export a copy of the preview mesh and view it outside of Max to get proper normals, so having a preview of the bake in my bake file is rather useless. Previously I'd just have a test unexploded mesh hidden in the scene with my shader on it, but that's personal preference more than anything.
I'm not against keyframing the mesh explosion, just the notion of rendering two separate AO passes when I can do one
Is there a tutorial anywhere about using keyframes to move the hi and low poly elements?
A. select your highpoly element(s)
B. key them at frame 0
C. key them at frame 10
D. move them at frame 10
E. Repeat for low
F. Repeat for the rest of the elements.
=D
In addition there are also tools such as RTT assist that will help you with this. http://www.polycount.com/forum/showthread.php?t=81405
At the projection distance that got most of the big forms, some of the small detail ended up clipping through and catching the bake from the mesh above it.
So I just ran another bake at a tiny projection distance and slapped that on top of the other in PS and masked out the small distance bake to ensure I got the best bits of both.
AO bake in modo took all of about 15 seconds a pop at 2048. I think the entire process took me maybe 20 minutes whilst eating my sammich, it's really not that much work.
And no messing around with exploding meshes, either.
I dreamt you wanted some bromance with me, or that you wanted to kill me, please to don't kill me, I have many sheeps to feed =((
I can be a fat polish girl for proper money. =(
EQ: I don't remember the animation process been explained that simple, but now that you put it down so simple, my two braincells went "duh" :P. I probably just confused the thread creator a bit there now that I re-read my input. Thanks for clearing things out man.
It could end up scarier if pedro voice chat Metalmind :P
WIP, Right direction? thumbs up or thumbs down? I dont want to trouble you with a paintover or anything.
A. This part can look flush depending on the reference, but I have several that show that these parts do not appear flush, but all of them have some perspective distortion on them as well so take this with a grain of salt. In addition, I used to own the gun and I do not recall this part sitting flush. Also this area is for iron sights, and the extrusions might make it more interesting in FPV
Better topo for B as show below possibly?
C. Messy areas previously pointed out by Perna, hopefully this topology is more acceptable.
Exploded parts
Thanks again everyone.
EDIT: just noticed there s a whole loop I can remove on the magazine.
I selected all objects and did a quick planar map as perna suggested, and broke off individual parts and relaxed them. Not worrying about packing, just keeping UV density the same with normalized clusters off so the scale is similar for all objects. I am not certain I corrected the weird seam EQ pointed out on the grip (since I am not entirely sure what constitutes a weird seam in this case), but hopefully my new rendition is better. Hopefully a significant improvement over my last iteration.
Need to:
-Check for slightly rotated parts as EQ suggested and align more edges
-Check seams
-look at the larger pieces such as the body, and see if anymore pieces can
be stitched together/quick planar as one piece.\
-adjust harsh edge on the front grip handle.
Ok, thanks.
Below shows me attempting to clamp down too much resulting in poor stretching and resolution problems. In the WIP shot above(figure A) I am not really happy with the banana shape it has since thats not very efficient, but at least there is no distortion. Additionally, I need to scale up some of the parts that are in FPV, but I am unsure how much to do so. I don't want it to look uneven in the texel/pixel density like it was in my last attempt.
Some more texel shots
Thanks again Perna, I really appreciate it. I thought the amount of seams I had was a significant reduction from last time, but clearly not enough, thanks for the input.
No seams on soft angles, I understand now I think (check WIP shot below for confirmation). However, areas that have many 90d angles are still split into a bunch of groups are a little more troublesome for me to grasp, such as the handle. On one hand you want a split at 90d angles at the very least I thought, but on the other hand doing so in an area like this breaks it into numerous pieces. How would you recommend I approach a piece like this with so many hard 90d angles,thus many seams currently.
Is the shot below a correct example of removing seams from soft angles?
Up close shot of the handle, unmodified from last time (this is not a subtle request for a paintover)
However this is a choice that should always be made depending on where the asset is ending up. If you're going to display it in the viewport, with a quality shader that has synced normals, 3ps in max, the latest max with the tangent fix, maya, or exporting to an engine that has synced up normals, then use as few UV islands as possible.
So you really need to understand where the asset is going, and use judgement in this case, if you know you're exporting the model into a broken engine, you'll want to be liberal with you UV seams on hard 90 degree angles. Much more important than following a "Never use smoothing groups" or "Use smoothing groups on 90 degree" rule, is simply understanding where your asset is going, and adjusting accordingly. This is where doing test bakes is key.
Also I personally try not to get too excessive with welding uv borders, as it can make UV packing much more difficult, when you end up with the weird shapes and such. In reality, if the texture artist needs to paint a lot of unique details over seams and such, he's gonna do it in a 3d app anyway, so, i mean if you've got one less seam here, but it causes a smoothing error, it isn't helping anyone.
If you know for a fact you want to paint X detail over X shape, it can be good to use extra geometry to account for any smoothing issues, and keep the UVs solid, this lets you deal with both issues at once.
Oh also, I think Per is trying to say keep your UVs simple in the start, while you're still doing test bakes, and only start splitting them up, where needed, after you've done your test bakes and find problems. This I totally agree with 100%.
[edit] With those last images, you should have a central loop running down the middle of the grip area, this is where your uv seam should be. you've got this tiny planar strip there, and it doesn't make any sense. Cut a loop down the middle, and round that area out a little with those 2 loops that are planar now. When mirroring, you should generally have a central loop.
lol. Thank you again for the in-depth reply. I will get to work on the 90d splits.
Very good thanks. Perna pointed this out several pages back, and believe it or not that was actually the next thing I was going to work on before I checked the responses in this thread.
Here was pernas original paintover for the grip area showing the problem you speak of.
Anyways, something like this EQ? Also I think I may need to round it a little more.
You seem absolutely determined to model a cylindrical shape, using any and all means except starting from a.... cylinder. What you've got here now is just a mess, so I made a little gif.
A. Place half cylinders along the straight edges of your shapes. All of the curves are exactly the same width, so all of our cylinders will be the same size. I used a 12 sided cylinder, which gives us 6 faces here - a good amount.
B. Extrude the shape of the curve, giving an appropriate level of detail(number of segments) to the curves so they all look "curved" and not blocky. I used the "curve extrude" tool in modo, which is really fast and ensures a nice, evenly spaced and curvy result. You can do this by hand or with a similar tool in max i'm sure, whats important is the end result, and that you're not tweaking individual verts. This is a vert specific geometric shape, so we shouldn't be moving verts around by hand here.
You could give/take an edge loop here or there from this example, it was just to quickly show the concept, not necessarily to model exactly as shown.
C. Join segments together, using bridge or whatever tools
See how nice this looks? Really, this is how your highpoly should have been modeled in the first place, then it would have been super easy to translate it to a low. This took just a minute or two to model.
-Have as few UV splits as possible keeping smoothing groups in mind, they should be used sparingly. Because the more smoothing groups, the more UV splits, the more UV islands, the more likely your texture artist will kill himself.
-Dont excessively weld parts together for the sake of welding stuff together if it produces a smoothing group error
With that being said here is my latest WIP, am I on the right track?
For the magholder, I would like it to be even less UV islands if possible; however, I am getting significant texel stretching if without breaking certain parts off.
Many thanks for the .gif and pointers. Is this Better? Not sure why I started with a box either, probably because I used some of my block in mesh to create the HP without realizing I was making this mistake. Otherwise I dont think I would have normally modeled whats essentially a cylinder with a box. Thanks!
That bottom uv is exactly what I mean by excessively welding stuff together, you have that bottom quad sticking way out in the layout, and it will make it a pain in the ass to pack. In this case, that quad should have been welded to the bottom, not the side anyway.
I have to say I'm pretty confused with your rail geometry. Some rails are modeled solid, while others are separate meshes? You can also save some geometry on the rails if you remove the "curve" of the rails, from the low and the high - this isn't in your ref. So just kill that center loop, and flatten it in the high as well.
Noted, thank you.
I was attempting to follow what perna suggested on the end post of the previous page where he said:
Before each one of the teeth on the rail was an instance, and that wasn't going to allow for unique detail, and as perna noted would be obvious that they are all the same instanced copy. Therefore I welded a few of the teeth down on either side for unique texturing. But I suppose I could just have multiple Unique non instanced teeth floating and keep them separate objects without having to instance all of them or having to weld them down to the cylinder. And thanks for pointing out the center line I will remove that.
Ok thanks, done.
Since the individual islands are looking ok I am proceeding with the final UV layout WIP. Before doing so I did a quick pack and test bake to verify there were no problem areas, and it looks fine.
Current WIP
While doing this I tried to keep in mind:
-Leave enough padding room for baking and mip mapping
-Keep related UV islands together
-objects have the same orientation in UV as they do in 3D (with the exception of a few parts such as the magazine, had to rotate that to fit it in with this current iteration)
- No slight rotations of objects, clamp down edges where possible
In addition I need to scale up the parts that are closest in FPV, but I am uncertain how much I need to do so.
I do 125% for close up areas, and 150% for areas that will be zoomed in on(iron sights and scopes, generally). Areas that will rarely/never be seen, I scale down as well. like the insides of parts that are totally occluded.
So in sum this is what I need to do to end with a good result next time. I dropped the ball at scaling up the detailed areas, and instead had final UVs as islands that were all uniform in texel resolution and packed them that way which was a waste of time.
1. Make UV islands uniform in density
2. Before laying out final UVs quick auto-pack and test bake with no SG use, find problem areas, add SG where needed. Add corrective geometry if needed.
3. Go in and scale up detailed areas 125/150% and scale down occluded areas (e.g. the bottom area of the mag holder no one will ever see)
4. Make Sure UVs are final at this point
5. Proceed to final uv packing ASSUMING your temporary quick packing + test bakes are error free
Does the above look correct to get on the right track? I was under the impression as far as seams and islands were concerned, they were acceptable based on pernas reply where I showed the old and new objects with their seams and UV islands. As well as LP merging to reduce the amount of seams. Pernas comment "Just saw Joe's reply.. there's more too.. your asset.. is not ready at all for uv packing, and you haven't followed previous advice for uv density" is phrased such that it sounds like there are other components wrong besides the density at this point.
6. Do another test bake
7. Another round of corrective geometry or smoothing group tweaks - I'll often find one or two little things after my final uv pack is set, that I didnt notice with the quick bakes
8. Prepare for final bakes
- Explode high/low
- Make sure highpoly meshes have RGB, or RGBCMYW colored materials assinged so you can easily bake material masks
- Make sure any floaters are set up properly, ie: as seperate meshes and have shadow casting turned off(or whatever you do in max, i think thats it)
Step 1 Make UV islands uniform in density using textools. Also below are images of areas I plan on scaling up for step 2. Using the failed pack above as a temporary pack.
FPV up close areas +125% scale:
1. Silencer
3. Nitrotac
4. Grip
6. Trigger
7. Safety
FPV Zoomed areas +150% scale:
2. Body (body includes handle and ironsight areas since this is all one mesh now)
5. Laser sight
On the right track? Ready for step 2? For totally occluded areas how much would you generally scale down %?
Thanks.
Here is what I am thinking with that critiques logic
Up close +125%
Zoom +150%
Scale Down:
and a plain FPV shot for good measure.
test bakes, sg where needed, corrective geo etc. Basic renders with max 2.5 star so some antialiasing issues, will probably use hammersly for finals which should remove them.