So, in The Galactic Line, you build space ships out of modules. Therefore, I model and texture the modules, animate them as needed, and so on. It's reasonably decent.
It inevitably results in an "industrial" look. The modules get slapped together in whatever way seems best. Even though you're not locked to a grid like in many voxel space ship games, you're still working with parts that have a fixed size and shape, and their seams will always look heavy and industrial.
Moreover, repeated parts will always be the same size, so you tend to end up with straight lines and boxy profiles. This is especially noticeable with habitable areas, since you rely on door-to-door connections, and that typically means all your habitable areas have the same connection profile - leading to straight lines and flat profiles.
Most space ships that are properly designed have flowing lines, tapered elements. They feel almost organic.
That's a high bar for modular spacecraft. Flowing lines and tapers are tough to do in modules, because baking them into the modules means the modules can only be assembled in one order, and with no missing parts. No reason to make it modular, then!
I've been struggling with this as I try to make a spaceplane set, so let's talk about a few methods to make modular ships have flowing lines.
1) Algorithmic tapering
It is possible to adjust the meshes of the modules to taper according to some algorithm. You can easily make a fuselage of modules into an organic tapered shape. This has some problems, though.
First, it can't mask the seams of the modules. This means most of the modules have to have identical connectors, which radically limits the overall look. It's always going to be a tapered fuselage, just with different surface greebles representing the different parts. More complex seams are possible, but the tapering won't mask them, so you'll need to be aware of that.
Second, if the modules have interiors, it's going to screw up the tapering. A room that shrinks or grows might become inaccessible or out of proportion. If the rooms are size-locked, now you have a problem where the windows need to stay attached to the outer hull, so now there are specific sub-elements of the mesh that must be scaled at different rates to get the final taper. Interior halls twist and grow, room ceilings rise while the rest of the room remains the same size... it's a mess.
Without R&D, tapering could only be applied to non-habitable elements such as engines, tanks, machinery, etc. I don't know if that's worth the effort.
2) Masking elements
Slipping coats on the outside or shims on the inside is perfectly possible. For example, if you want your straight fuselage to take on a triangular shape, slip on a triangular bit of armor around it. Any shape can be mimicked like this, and the flow of the ship profile can be built primarily out of these masking elements instead of their contents.
One problem is precisely that: the flow of the ship is mostly determined by specific masking elements, and is therefore pretty restricted.
Another problem is that the masking elements inherently conflict with the surfaces they mask. If you're turning a straight fuselage into a triangle, then the windows on the fuselage are now, at best, recessed several meters into a concave pit. This is substantially worse if your fuselage modules have significant surface elements, such as bay windows, solar panels, machinery, or inflatable areas. Masking elements constrain what you can put on your core modules and where, meaning that they may look 'unfinished' when not masked.
It is possible to do the opposite. If you have a split body rather than a fuselage, you can slowly move the elements apart or together and fill in the interior gaps. This is a fairly robust approach, but it means you'll have twice as many parts, twice as many halls. From a simplicity standpoint, it makes the most sense to "shim" with a hallway rather than a hull part, making the core hallway widen or narrow or have gathering points to change the flow of the profile. This can work, but care needs to be taken on how the attached rooms actually attach. Otherwise it will still end up looking very linear and dull.
3) Adaptive sizing
It's possible to set up the individual elements with blend shapes or bone animations to slightly change their shape. This is fairly adaptable, since it is per-part, but it does require that the linking areas remain interconnectable. So you can't go too off-the-wall.
This can be used to taper elements, but they would all have to have the same basic taper characteristics in order to connect without big chunky seams. Perhaps more feasibly, it would allow you to raise or lower the exits, which would break up the linearity without feeling too forced and without any complex interconnectivity requirements.
Of course, you could also just make some parts have a rise or fall inherently, which would accomplish the same thing. This would force players to accept specific patterns of shapes, but it's much cheaper.
4) Painted hulls
Another option is to let the players place the rooms/modules, then adaptively generate the flowing hull. This wouldn't be too hard - a convex mesh calculation with some holes cut for the windows and panels you want to expose. However, since I haven't done it, I don't know how good the result would really be. "Shrink-wrapped space ship" seems like it might be a bad look, and you'd need a lot of smart texturing algorithms.
Even with that approach, you'd still need to use offsets to keep the habitable areas from going excessively flat.
A subset might be possible. "Adaptive surfaces" are less difficult that fully generated ones, and it might be possible to create masking elements that "melt" into the existing objects, including making way for elements that need exposing. This is a bit of a challenge, but not as excessive as generating the full hull. Also, it'd allow for a lot more control over what the ship ends up looking like
A super-easy subset would be adaptive surfaces that have shapekeys built in. The various shapekeys align with various shared shapes among the modules, allowing you to adjust the hull to fit properly. This is a big step up from simply allowing the meshes to overlap, but it does mean you'd need to have only a few, very common shared shapes.
...
Anyway, that was my very technical essay on a specific thing I'm doing.
Showing posts with label modeling. Show all posts
Showing posts with label modeling. Show all posts
Wednesday, March 29, 2017
Thursday, June 12, 2014
Clothes are Expensive
Now that I'm seriously considering a fantasy or scifi open-world RPG, even a small one, I need to face the dire truth:
Clothes are reaaaaaaally expensive. They take a reaaaaaally huge amount of modeling effort. I can buy content from the asset store for the houses and the dinnerware and the weapons and stuff, but none of the asset store character model packs hold up to my requirements. So I need to talk clothes.
This essay will be me talking to myself about the technical challenges and possible solutions. Stop reading if you are easily bored by technical details.
Right now, the biggest thing I cannot abide in an open-world game is everyone having the same body type. It was never acceptable to me, and now that Unity handles shapekeys so easily, there's not much technical reason to stop people from having a wide variety of body types based off a single mesh. I have modeled those kinds of bodies, and I'm confident I can create a base mesh or two to support a wide variety of bodies in my game.
The problem is the clothes.
Right now, there are two common methods of doing clothes.
One is mesh overlay: the underlying body mesh (the "naked" mesh) still exists, the mesh of the cloth is physically "on top". This is a somewhat rare approach for "core" clothes like shirts, although it's common for things like capes and hair.A big reason it's not popular is that the clothes tend to clip through the underlying body mesh, giving you 'pop-through'. Even if you increase the amount of empty space between the clothing and the body(giving it a weird, floaty look) you still have to painstakingly massage everything until the weights and positions are absolutely ideal.
The issue is that mesh overlay systems only really work if you have one body type. Every shapekey slider the base body has must be replicated into the overlay mesh, and each must be massaged both independently and in tandem to make sure there's no pop-through. This is an extremely difficult and time-consuming activity. Even if all you do is bone scaling, it will affect the overlay clothes differently and things will go south.
Unsuitable.
The other method is mesh replacement. The base mesh is chopped into pieces, and the pieces are deleted and replaced by costume elements as needed. If you put on a shirt, your torso mesh is deleted and the shirt mesh is put in its place. This is the most common way to do costumes in games.
However, if you have shapekeys, every costume element has to respond to those shapekeys in the right way. While this isn't as strenuous as mesh overlays, it is still time-consuming, and you need to be careful to keep seams intact. This is particularly difficult to do in Blender, since deleting verts makes shapekeys go haywire - you can't simply copy over the seams and keep them properly shapekeying.
If I had to choose one of these methods, obviously I'd choose the mesh replacement method. But neither is suitable for my needs. Here are some much rarer options.
Cloned mesh: Clothes are made out of verts cloned off the main body. This is a common "my first shirt" modeling trick, but it works poorly because the topology of a shirt is not going to be the same as the topology of a chest.
Mesh morphs: Instead of the shapekeys being limited to changing your body type, they also change the clothes you appear to wear: the "short sleeve" morph pops sleeves out of your arms - perhaps they were hidden on the interior of the mesh. Then your "clothes" consist of addons like buttons, collars, belts, and so on - the core shape is embedded into the shape keys.
While it's an interesting idea, it's quite limited and annoying to actually use. It'd be easier to do mesh replacement.
Smart Mesh Replacement: Just like mesh replacement, but minimize the number of meshes you have to build by making the replacement mesh have custom shapekeys to alter its appearance. In this way you can make the exact cut or fit vary, giving you a much wider variety of clothes out of a single, smarter mesh. However, it has all the flaws of the mesh replacement system.
Shrinkwrap Overlay: Model your clothes larger than the beefiest, heaviest version of your character model. When equipped in-game, shrink-wrap the clothes to fit whatever underlying body is in use.
This one's important, so let's talk about it in detail.
The shrinkwrap solution is fun because it allows for arbitrarily layered clothes and will usually adapt pretty easily to completely new meshes. The problem is the same as with all shrinkwrap solutions: pop-through. Say you have a a face on your body mesh's shoulder that is completely horizontal, but the clothes have a seam down that point and two slightly tilted-down faces running out from the seam. The shrink wrap will end up with the edges of the body face popping through the centers of the tilted-down clothes faces.
Normally you'd pad it to avoid this - a few millimeters of spacing. This may be possible, but it's an ugly and weird-looking approach to have the clothes "float". The higher the density of the overlay mesh, the less spacing you need, at least as long as the bone weighting lined up. But, this being an open-world RPG, we don't want absurdly detailed clothes.
A number of shrinkwrapping algorithms exist to minimize pop-through. For example, there's a "vertex locking" shrink wrap which attaches itself to nearby verts when possible. This really minimizes pop-through, and also comes with the advantage of easily allowing you to reweight the bone weights on the overlay.
Well, that sort of thing is possible, but it does lead me to a simpler question: if we're going to snap to verts, why not do that from the beginning?
Affixed-Vert: In this version, you create your new model (whether overlay or replacement) with your default, no-shape-keys-activated model in mind. Then you actually copy in the no-shape-keys-activated model. If you are doing an overlay, delete the faces. If you're doing a replacement, only delete the faces you don't want to show. This requires no shape keys.
In the game engine, someone equips your clothes.
1) A map is created mapping the verts of your clothes mesh to the verts of the base body mesh in the places they are identical.
2) A map is created of all the unmatched verts, linking them to their nearest matched vert.
3) A delta is taken of the in-game character's vert positions as compared to the original base body mesh.
4) All the verts in the clothes mesh are moved by that amount, as the maps indicate.
5) All verts with no faces are deleted (cleanup).
6) The modified mesh is either overlayed or replaces the character's mesh, as indicated by the settings.
While it will probably work, it has a few issues I can see.
The first is that it requires a specific body mesh. This solution does not work with arbitrary body meshes as the shrinkwrap solution would. However, it might not be hard to create variants for new body types.
The second issue is that shape keys frequently distort the normals of a mesh. For example, a fat man's belly distorts a cloth mesh substantially. It creates rolls and folds that don't exist in a skinny man's model. Care would need to be taken to intelligently handle this chaos when mapping the clothes.
The third is that layered clothing might be very tough. Well, it's tough anyway, so I guess we're okay.
It also has a few advantages I can see.
One is that, while it doesn't need to have the body's morphs, it can have its own morphs. This would allow for the clothing to intelligently adjust itself according to whatever parameters you wanted. In addition to a slider for something like sleeve length or neckline, you could have a slider for "too big" or "too small" or "in freefall" or "gravity is forward". This would really only work if you were doing replacement instead of overlay, but it would be pretty neat.
Another is that we could easily introduce super-cheap clothing physics. Since we know what verts on the custom cloth are affixed to what verts on the underlying body, we know how much space there is between them. Using this value, we can introduce physics-like wobble as the character moves. Aggressive movement such as jumping could be done by shrinking the distance on distant ones, and increasing the distance on closer ones... or we could use a shapekey, as mentioned.
The key to this content is making it easy for modders to create custom content for the game. And I can't think of any way to make it easier: copy the part of the base model you need, slap your custom model on top, and you're ready to go. No need for painstaking massages. If you want to allow modders to create new bodies, release your clothes models without the body models mixed in, and they can mix in their body models easy as pie.
There are probably other ways to handle this, but I can't think of anything else that seems more promising. If anyone out there has better ideas, let me know.
Clothes are reaaaaaaally expensive. They take a reaaaaaally huge amount of modeling effort. I can buy content from the asset store for the houses and the dinnerware and the weapons and stuff, but none of the asset store character model packs hold up to my requirements. So I need to talk clothes.
This essay will be me talking to myself about the technical challenges and possible solutions. Stop reading if you are easily bored by technical details.
Right now, the biggest thing I cannot abide in an open-world game is everyone having the same body type. It was never acceptable to me, and now that Unity handles shapekeys so easily, there's not much technical reason to stop people from having a wide variety of body types based off a single mesh. I have modeled those kinds of bodies, and I'm confident I can create a base mesh or two to support a wide variety of bodies in my game.
The problem is the clothes.
Right now, there are two common methods of doing clothes.
One is mesh overlay: the underlying body mesh (the "naked" mesh) still exists, the mesh of the cloth is physically "on top". This is a somewhat rare approach for "core" clothes like shirts, although it's common for things like capes and hair.A big reason it's not popular is that the clothes tend to clip through the underlying body mesh, giving you 'pop-through'. Even if you increase the amount of empty space between the clothing and the body(giving it a weird, floaty look) you still have to painstakingly massage everything until the weights and positions are absolutely ideal.
The issue is that mesh overlay systems only really work if you have one body type. Every shapekey slider the base body has must be replicated into the overlay mesh, and each must be massaged both independently and in tandem to make sure there's no pop-through. This is an extremely difficult and time-consuming activity. Even if all you do is bone scaling, it will affect the overlay clothes differently and things will go south.
Unsuitable.
The other method is mesh replacement. The base mesh is chopped into pieces, and the pieces are deleted and replaced by costume elements as needed. If you put on a shirt, your torso mesh is deleted and the shirt mesh is put in its place. This is the most common way to do costumes in games.
However, if you have shapekeys, every costume element has to respond to those shapekeys in the right way. While this isn't as strenuous as mesh overlays, it is still time-consuming, and you need to be careful to keep seams intact. This is particularly difficult to do in Blender, since deleting verts makes shapekeys go haywire - you can't simply copy over the seams and keep them properly shapekeying.
If I had to choose one of these methods, obviously I'd choose the mesh replacement method. But neither is suitable for my needs. Here are some much rarer options.
Cloned mesh: Clothes are made out of verts cloned off the main body. This is a common "my first shirt" modeling trick, but it works poorly because the topology of a shirt is not going to be the same as the topology of a chest.
Mesh morphs: Instead of the shapekeys being limited to changing your body type, they also change the clothes you appear to wear: the "short sleeve" morph pops sleeves out of your arms - perhaps they were hidden on the interior of the mesh. Then your "clothes" consist of addons like buttons, collars, belts, and so on - the core shape is embedded into the shape keys.
While it's an interesting idea, it's quite limited and annoying to actually use. It'd be easier to do mesh replacement.
Smart Mesh Replacement: Just like mesh replacement, but minimize the number of meshes you have to build by making the replacement mesh have custom shapekeys to alter its appearance. In this way you can make the exact cut or fit vary, giving you a much wider variety of clothes out of a single, smarter mesh. However, it has all the flaws of the mesh replacement system.
Shrinkwrap Overlay: Model your clothes larger than the beefiest, heaviest version of your character model. When equipped in-game, shrink-wrap the clothes to fit whatever underlying body is in use.
This one's important, so let's talk about it in detail.
The shrinkwrap solution is fun because it allows for arbitrarily layered clothes and will usually adapt pretty easily to completely new meshes. The problem is the same as with all shrinkwrap solutions: pop-through. Say you have a a face on your body mesh's shoulder that is completely horizontal, but the clothes have a seam down that point and two slightly tilted-down faces running out from the seam. The shrink wrap will end up with the edges of the body face popping through the centers of the tilted-down clothes faces.
Normally you'd pad it to avoid this - a few millimeters of spacing. This may be possible, but it's an ugly and weird-looking approach to have the clothes "float". The higher the density of the overlay mesh, the less spacing you need, at least as long as the bone weighting lined up. But, this being an open-world RPG, we don't want absurdly detailed clothes.
A number of shrinkwrapping algorithms exist to minimize pop-through. For example, there's a "vertex locking" shrink wrap which attaches itself to nearby verts when possible. This really minimizes pop-through, and also comes with the advantage of easily allowing you to reweight the bone weights on the overlay.
Well, that sort of thing is possible, but it does lead me to a simpler question: if we're going to snap to verts, why not do that from the beginning?
Affixed-Vert: In this version, you create your new model (whether overlay or replacement) with your default, no-shape-keys-activated model in mind. Then you actually copy in the no-shape-keys-activated model. If you are doing an overlay, delete the faces. If you're doing a replacement, only delete the faces you don't want to show. This requires no shape keys.
In the game engine, someone equips your clothes.
1) A map is created mapping the verts of your clothes mesh to the verts of the base body mesh in the places they are identical.
2) A map is created of all the unmatched verts, linking them to their nearest matched vert.
3) A delta is taken of the in-game character's vert positions as compared to the original base body mesh.
4) All the verts in the clothes mesh are moved by that amount, as the maps indicate.
5) All verts with no faces are deleted (cleanup).
6) The modified mesh is either overlayed or replaces the character's mesh, as indicated by the settings.
While it will probably work, it has a few issues I can see.
The first is that it requires a specific body mesh. This solution does not work with arbitrary body meshes as the shrinkwrap solution would. However, it might not be hard to create variants for new body types.
The second issue is that shape keys frequently distort the normals of a mesh. For example, a fat man's belly distorts a cloth mesh substantially. It creates rolls and folds that don't exist in a skinny man's model. Care would need to be taken to intelligently handle this chaos when mapping the clothes.
The third is that layered clothing might be very tough. Well, it's tough anyway, so I guess we're okay.
It also has a few advantages I can see.
One is that, while it doesn't need to have the body's morphs, it can have its own morphs. This would allow for the clothing to intelligently adjust itself according to whatever parameters you wanted. In addition to a slider for something like sleeve length or neckline, you could have a slider for "too big" or "too small" or "in freefall" or "gravity is forward". This would really only work if you were doing replacement instead of overlay, but it would be pretty neat.
Another is that we could easily introduce super-cheap clothing physics. Since we know what verts on the custom cloth are affixed to what verts on the underlying body, we know how much space there is between them. Using this value, we can introduce physics-like wobble as the character moves. Aggressive movement such as jumping could be done by shrinking the distance on distant ones, and increasing the distance on closer ones... or we could use a shapekey, as mentioned.
The key to this content is making it easy for modders to create custom content for the game. And I can't think of any way to make it easier: copy the part of the base model you need, slap your custom model on top, and you're ready to go. No need for painstaking massages. If you want to allow modders to create new bodies, release your clothes models without the body models mixed in, and they can mix in their body models easy as pie.
There are probably other ways to handle this, but I can't think of anything else that seems more promising. If anyone out there has better ideas, let me know.
Monday, April 29, 2013
Avatar Creation Tool: POOFY SLEEVES TIME
TECHNICAL POST
I've made a lot of progress on the avatar creation tool, after two weeks wasted. Right now, you can paint clothes in multiple layers, and then rearrange the layers, move them to different avatars, and so on.
For example, you could paint a shirt. Then you could paint chainmail. The mail would be a specular rather than diffuse material, it'd be bumpmapped properly, and the shirt would show through the holes. You could then switch the order, putting the shirt on over the chainmail. The shirt (assuming it was 100% opacity) would obscure the mail, but the mail's heightmap would make the shirt bumpy in a muted version of the mail's bumps.
Also, you can paint on wrinkles and thickness, and you can paint skin as well if you want tattoos or warts or whatever.
This actually works really well. I am very happy with it. But this is all texture/bumpmap stuff. Meaning that your arm will always be shaped like your arm. This is fine for tight sleeves, but if you have poofy sleeves at all, you'll need to actually modify the mesh.
Originally, the plan was that I would create modified versions of the mesh, and you could just select which one you wanted to use. Your shirt is based on the short sleeve mesh variant, or the poofy sleeve mesh variant, or whatever. It'd be a lot of work, not just because I would need to create a ton of variants, but because every variant would have to be mapped to the half dozen body shape keys/morph targets so that each would look correct on beefy people, fat people, and so on.
But... the success of this in-unity clothes generation means I'm rethinking that. Is there a way to allow the users to create their own mesh?
Sure!
First off, it's easy to actually modify or create meshes. The hard part is determining what to create, how. And UV mapping it.
Let's say that you're building the top half of a Disney princess dress - floofy and pastel. You want the shoulders to floof: right now, they're just that frosting-colored blue painted right on the skin, like a tight shirt. So you switch from texture paint mode to mesh edit mode.
You mouseover the shoulder and scroll-wheel up. The shoulders inflate along their normal. Perfect. Your shoulders are floofy.
That part is easy. It's just another morph target. Morph targets are stored as "Vertex N offset by XYZ", and that's literally what you're doing. Except we would store it in a 4D Vertex, where W would be the normal. By allowing it to be offset by the normal instead of (or as well as) XYZ coordinates, we allow for bodies that are different shapes. This probably isn't a big deal with shoulders, since most people's shoulders are roughly the same shape, but it really matters when you're trying to do armor on a fat guy.
Oh, is it not flounced quite right? Click and drag to move the vertices around with a grab brush. Again, very easy. Now the morph target is offset by a multiple of the normal and a certain XYZ value. Mousewheel down to pull the point inward...
You can use this trick to do mesh digging as well as floofing. Let's say you want to make someone with a robot arm, so you want the arm to have actual indents along metallic tracks. You paint the metal tracks, then you mousewheel down to pull the vertices in along their normal, digging into the mesh.
This stuff is the cake. The hard part starts now:
You want a sleeve. That is, you want a short sleeve that stands slightly away from the arm and the arm is within it. You don't want to simply modify the arm's size. You want to create more mesh around the arm.
Let's start with the UI. It's the same. The user mousewheels up on the sleeve. The algorithm detects the edge of the clothing you've painted, and says "okay, this texture ends between this vertex and the next vertex on the triangle. So I can't just move this vertex, that would affect a region not covered by the texture. I have to tear it."
So it clones the vertex, lifts it along the normal of its parent vertex, and creates tris trying it back to its parent mesh on the shoulder side while leaving it detached on the elbow side. A sleeve. It's got the same bone weights and tracks fine.
Mousewheel down, it retracts towards the parent until it merges and vanishes.
Want your poofy edge to have a poofy shoulder? Mousewheel up on the shoulder. This is all connected space, so it doesn't detach from the parent model. Only the edge points detach, meaning that your model only gains a few vertices instead of cloning vast amounts. Depending on the quality of the model, this may actually go in a few vertices: the point is that the sleeve gives the indication that there is an arm up it, so the detached portion does have to have a certain depth.
Collars or unbuttoned fronts or whatever all have the same method, except that with collars you'd want to drag the new vertices down and out so that they fold over properly. That may actually require a special function, since otherwise they might be attached to the neck bone rather than the chest bone. Still, it's not that bad - a "reparent to closest vertex" would do.
If you did want to create something that is an entirely separate layer, that'd be a slightly different system built on the same principle: instead of editing the base mesh, you'd create a clone of the base mesh containing only the vertices that are covered by the texture, then edit that.
In both cases, these vertices can be stored in the exact same WXYZ from N framework that we used for offsetting parent vertices. Except, instead of moving the parent vertex, they clone it.
However - this is the rough part. They can't clone the UV map location of the parent. Instead, they have to create a new UV map position for their tris, and cut the pixels that were on their parents' UV map, pasting them to their own. This is required because otherwise the arm inside the sleeve would be the same color as the sleeve.
I'm actually... not sure about how to do that. I know there's a way to do it, but I've never tried it out. It may be annoyingly complex. But it's an absolute necessity.
...
Okay, we've discussed sleeves and collars and entirely distinct layers... but what if we want a topology that isn't simply an offset version of the parent?
The obvious example is skirts. What if we want a skirt?
When you mouse up along the inside of the leg, you'll quickly cross over the X axis. If you're in "merge mode", those vertices would impact and merge, causing their triangles to also merge (and average their bone weights). If any vertex only has triangles which are entirely along 0 X, it self-destructs, "hollowing" the skirt out. (Otherwise you would have extremely loose shorts).
This is not so hard, although it has one big downside: the skirt would end up with a very low poly count horizontally. Because of that, we may need an algorithm to add "stripes" to the skirt. This'd be easy if the skirt was just a standalone mesh: we could just do loop cuts. But since it's often going to be integrated into the overall mesh, we need to come up with a method of creating vertical cuts that don't screw up the topology near the waist. that's going to be some work, but it's not nightmarish, just annoying. Alternately, I could just make the legs themselves have a high poly count so that skirts wouldn't suffer.
...
IT ALL SEEMS FEASIBLE LET'S DO IT.
I've made a lot of progress on the avatar creation tool, after two weeks wasted. Right now, you can paint clothes in multiple layers, and then rearrange the layers, move them to different avatars, and so on.
For example, you could paint a shirt. Then you could paint chainmail. The mail would be a specular rather than diffuse material, it'd be bumpmapped properly, and the shirt would show through the holes. You could then switch the order, putting the shirt on over the chainmail. The shirt (assuming it was 100% opacity) would obscure the mail, but the mail's heightmap would make the shirt bumpy in a muted version of the mail's bumps.
Also, you can paint on wrinkles and thickness, and you can paint skin as well if you want tattoos or warts or whatever.
This actually works really well. I am very happy with it. But this is all texture/bumpmap stuff. Meaning that your arm will always be shaped like your arm. This is fine for tight sleeves, but if you have poofy sleeves at all, you'll need to actually modify the mesh.
Originally, the plan was that I would create modified versions of the mesh, and you could just select which one you wanted to use. Your shirt is based on the short sleeve mesh variant, or the poofy sleeve mesh variant, or whatever. It'd be a lot of work, not just because I would need to create a ton of variants, but because every variant would have to be mapped to the half dozen body shape keys/morph targets so that each would look correct on beefy people, fat people, and so on.
But... the success of this in-unity clothes generation means I'm rethinking that. Is there a way to allow the users to create their own mesh?
Sure!
First off, it's easy to actually modify or create meshes. The hard part is determining what to create, how. And UV mapping it.
Let's say that you're building the top half of a Disney princess dress - floofy and pastel. You want the shoulders to floof: right now, they're just that frosting-colored blue painted right on the skin, like a tight shirt. So you switch from texture paint mode to mesh edit mode.
You mouseover the shoulder and scroll-wheel up. The shoulders inflate along their normal. Perfect. Your shoulders are floofy.
That part is easy. It's just another morph target. Morph targets are stored as "Vertex N offset by XYZ", and that's literally what you're doing. Except we would store it in a 4D Vertex, where W would be the normal. By allowing it to be offset by the normal instead of (or as well as) XYZ coordinates, we allow for bodies that are different shapes. This probably isn't a big deal with shoulders, since most people's shoulders are roughly the same shape, but it really matters when you're trying to do armor on a fat guy.
Oh, is it not flounced quite right? Click and drag to move the vertices around with a grab brush. Again, very easy. Now the morph target is offset by a multiple of the normal and a certain XYZ value. Mousewheel down to pull the point inward...
You can use this trick to do mesh digging as well as floofing. Let's say you want to make someone with a robot arm, so you want the arm to have actual indents along metallic tracks. You paint the metal tracks, then you mousewheel down to pull the vertices in along their normal, digging into the mesh.
This stuff is the cake. The hard part starts now:
You want a sleeve. That is, you want a short sleeve that stands slightly away from the arm and the arm is within it. You don't want to simply modify the arm's size. You want to create more mesh around the arm.
Let's start with the UI. It's the same. The user mousewheels up on the sleeve. The algorithm detects the edge of the clothing you've painted, and says "okay, this texture ends between this vertex and the next vertex on the triangle. So I can't just move this vertex, that would affect a region not covered by the texture. I have to tear it."
So it clones the vertex, lifts it along the normal of its parent vertex, and creates tris trying it back to its parent mesh on the shoulder side while leaving it detached on the elbow side. A sleeve. It's got the same bone weights and tracks fine.
Mousewheel down, it retracts towards the parent until it merges and vanishes.
Want your poofy edge to have a poofy shoulder? Mousewheel up on the shoulder. This is all connected space, so it doesn't detach from the parent model. Only the edge points detach, meaning that your model only gains a few vertices instead of cloning vast amounts. Depending on the quality of the model, this may actually go in a few vertices: the point is that the sleeve gives the indication that there is an arm up it, so the detached portion does have to have a certain depth.
Collars or unbuttoned fronts or whatever all have the same method, except that with collars you'd want to drag the new vertices down and out so that they fold over properly. That may actually require a special function, since otherwise they might be attached to the neck bone rather than the chest bone. Still, it's not that bad - a "reparent to closest vertex" would do.
If you did want to create something that is an entirely separate layer, that'd be a slightly different system built on the same principle: instead of editing the base mesh, you'd create a clone of the base mesh containing only the vertices that are covered by the texture, then edit that.
In both cases, these vertices can be stored in the exact same WXYZ from N framework that we used for offsetting parent vertices. Except, instead of moving the parent vertex, they clone it.
However - this is the rough part. They can't clone the UV map location of the parent. Instead, they have to create a new UV map position for their tris, and cut the pixels that were on their parents' UV map, pasting them to their own. This is required because otherwise the arm inside the sleeve would be the same color as the sleeve.
I'm actually... not sure about how to do that. I know there's a way to do it, but I've never tried it out. It may be annoyingly complex. But it's an absolute necessity.
...
Okay, we've discussed sleeves and collars and entirely distinct layers... but what if we want a topology that isn't simply an offset version of the parent?
The obvious example is skirts. What if we want a skirt?
When you mouse up along the inside of the leg, you'll quickly cross over the X axis. If you're in "merge mode", those vertices would impact and merge, causing their triangles to also merge (and average their bone weights). If any vertex only has triangles which are entirely along 0 X, it self-destructs, "hollowing" the skirt out. (Otherwise you would have extremely loose shorts).
This is not so hard, although it has one big downside: the skirt would end up with a very low poly count horizontally. Because of that, we may need an algorithm to add "stripes" to the skirt. This'd be easy if the skirt was just a standalone mesh: we could just do loop cuts. But since it's often going to be integrated into the overall mesh, we need to come up with a method of creating vertical cuts that don't screw up the topology near the waist. that's going to be some work, but it's not nightmarish, just annoying. Alternately, I could just make the legs themselves have a high poly count so that skirts wouldn't suffer.
...
IT ALL SEEMS FEASIBLE LET'S DO IT.
Subscribe to:
Posts (Atom)