This is where I monologue about video game design. Comments are invited and encouraged. Please. Say something. It's so lonely in here.
I can feel it, Dave.
Re: Video Game Design Blog
So, here we are. It's been seemingly forever since I started talking to myself on interactive Skype, but finally, due to popular demand, and a shiny new board, I'm posting my bloggage and progress here, for your viewing...not. Some of these pictures are NSFW, hence the tag I'm adding to this thread. Screw you and your workplace.
I started this endeavor about 9-10 months ago, and have educated myself about various elements of game composition and design since then so some degree of understanding. Until a finished game comes out of me, my actual comprehension is untested.
One of the biggest hurdles in building a 3D game is 3D assets. There are places that will sell shitty ones to you. Those are expensive and shitty. The actual licenses offered are not always clear up front either, which sucks. DAZ 3D was what I planned to use to get my human model for the Strays demo, because it says that it can be used commercially for free. However, what it means is that you can render stills using it for any purpose for free. In the fine print, any use in a game of any kind has to be licensed. For $500. For their shitty model. I digress. Here's a look at what I've learned in the last 9 months.
This is basically where I was on day when I first started learning about how to start a modeling project. "Blocking in" is the formal name of the phase of making a model in which you make a very rough outline of your model and start refining it further and further. It should still very closely resemble the figure you desire, and should be based on reference art.
Fantastic, right? That's supposed to resemble a dog. A month later I had refined my skills enough to produce Rowdy! The iconic stray. He still had a long way to go at this point (when I uploaded this he had yet to be rigged, skinned, and animated, tasks that took another 4 months.)
That was then. I worked for a while on the cartoon project, during which time I learned a LOT. I would say that getting it to the point that it came to set me back a few months of development in appearances only, as I plan to demonstrate next.
Part of the reason that I was so willing to take on another project, and then take a hiatus for a month or so, was that learning so shortly after I had Rowdy seemingly ready to start his debut demo video that I would have to make my human models from scratch really disheartened me. There have been more setbacks since then. The fur shaders we acquired to use in unity appear to look like shit, and the nice pretty hair in blender doesn't travel to unity.
About a week ago now I started work on the human female model after a false start on the human male. Good references are almost impossible to find for this kind of thing. Everything is either pornography or someone else's 3d models. "Right Now" I'm about halfway through modeling the hand. Since making Rowdy, I don't seem to Block In, Sculpt, Retopo, and then finalize the model. The books I've worked out of have described these steps as phases for the purposes of education, but emphasized that as you work on them your process will change to become a blend of them over time. I found myself uncomfortable looking at a bald head, empty eye sockets, or matte grey skin. Today, when I decided to do this entry, I had done a "quick render" of the thumbnail to see how it looked and caught an interesting shot of the hand, which inspired me to share. So, here's a series of renders I've made of the current model as she is now. The skin has a "doll-like" quality in some shots due to this being a rough draft. Note that in a couple of the close ups I demonstrate the shape key that can cause her pupils to dilate and contract. If you notice what appear to be minor imperfections in her skin, that is intentional. There is a Perlin Noise based "cloud" texture subtracted from the alpha channel of her skin texture. This means that when rendered, a slight bumpiness is detected much like grain or stretching. I added this for realism, but plan to add further realism touches when actually going through the materials and textures, rather than doing rough drafts.
Enjoy, and please share your thoughts in the comments.
I started this endeavor about 9-10 months ago, and have educated myself about various elements of game composition and design since then so some degree of understanding. Until a finished game comes out of me, my actual comprehension is untested.
One of the biggest hurdles in building a 3D game is 3D assets. There are places that will sell shitty ones to you. Those are expensive and shitty. The actual licenses offered are not always clear up front either, which sucks. DAZ 3D was what I planned to use to get my human model for the Strays demo, because it says that it can be used commercially for free. However, what it means is that you can render stills using it for any purpose for free. In the fine print, any use in a game of any kind has to be licensed. For $500. For their shitty model. I digress. Here's a look at what I've learned in the last 9 months.
This is basically where I was on day when I first started learning about how to start a modeling project. "Blocking in" is the formal name of the phase of making a model in which you make a very rough outline of your model and start refining it further and further. It should still very closely resemble the figure you desire, and should be based on reference art.
Fantastic, right? That's supposed to resemble a dog. A month later I had refined my skills enough to produce Rowdy! The iconic stray. He still had a long way to go at this point (when I uploaded this he had yet to be rigged, skinned, and animated, tasks that took another 4 months.)
That was then. I worked for a while on the cartoon project, during which time I learned a LOT. I would say that getting it to the point that it came to set me back a few months of development in appearances only, as I plan to demonstrate next.
Part of the reason that I was so willing to take on another project, and then take a hiatus for a month or so, was that learning so shortly after I had Rowdy seemingly ready to start his debut demo video that I would have to make my human models from scratch really disheartened me. There have been more setbacks since then. The fur shaders we acquired to use in unity appear to look like shit, and the nice pretty hair in blender doesn't travel to unity.
About a week ago now I started work on the human female model after a false start on the human male. Good references are almost impossible to find for this kind of thing. Everything is either pornography or someone else's 3d models. "Right Now" I'm about halfway through modeling the hand. Since making Rowdy, I don't seem to Block In, Sculpt, Retopo, and then finalize the model. The books I've worked out of have described these steps as phases for the purposes of education, but emphasized that as you work on them your process will change to become a blend of them over time. I found myself uncomfortable looking at a bald head, empty eye sockets, or matte grey skin. Today, when I decided to do this entry, I had done a "quick render" of the thumbnail to see how it looked and caught an interesting shot of the hand, which inspired me to share. So, here's a series of renders I've made of the current model as she is now. The skin has a "doll-like" quality in some shots due to this being a rough draft. Note that in a couple of the close ups I demonstrate the shape key that can cause her pupils to dilate and contract. If you notice what appear to be minor imperfections in her skin, that is intentional. There is a Perlin Noise based "cloud" texture subtracted from the alpha channel of her skin texture. This means that when rendered, a slight bumpiness is detected much like grain or stretching. I added this for realism, but plan to add further realism touches when actually going through the materials and textures, rather than doing rough drafts.
Enjoy, and please share your thoughts in the comments.
Re: [NSFW] Video Game Design Blog
Due to the phenomenal response to some of this models phenomenal...attributes, I prepared to make another image demonstrating them. And discovered the root of another problem I was having.
You may, or may not, have noticed that her hair cut was kind of...flat? I had this bizarre issue where her hair was tangling itself on her ears, which popped up kind of suddenly and I couldn't figure it out. Well, when I started rendering from the side, it showed up. The ears were inside out.
Which is to say, the normals of the ears were inside out, so they appeared pitch black. This meant that her hair particles had been attempting to deflect from the "inside" of her ear models. I quickly rectified this, reset her hair, and set about a new haircut, hopefully more pleasing, and a totally gratuitous fan service shot in thanks for the help finding my problem.
While I appreciate comments via text, I frequently miss them. The boards are a much more reliable way for me to get those comments, however short and overwhelmingly....short...they are.
For your...appreciating...pleasure. I feel dirty.
G
You may, or may not, have noticed that her hair cut was kind of...flat? I had this bizarre issue where her hair was tangling itself on her ears, which popped up kind of suddenly and I couldn't figure it out. Well, when I started rendering from the side, it showed up. The ears were inside out.
Which is to say, the normals of the ears were inside out, so they appeared pitch black. This meant that her hair particles had been attempting to deflect from the "inside" of her ear models. I quickly rectified this, reset her hair, and set about a new haircut, hopefully more pleasing, and a totally gratuitous fan service shot in thanks for the help finding my problem.
While I appreciate comments via text, I frequently miss them. The boards are a much more reliable way for me to get those comments, however short and overwhelmingly....short...they are.
For your...appreciating...pleasure. I feel dirty.
G
Re: [NSFW] Video Game Design Blog
I was expecting a woman in a red dress for some reason.
psn: aretepolitic
Steam: aretepolitic
Steam: aretepolitic
Re: [NSFW] Video Game Design Blog
Don't let my current project hear me say this, but I don't actually know how to make clothing yet. She's just going to have to stand around naked for a while. Oh well. When I finish her hands and feet I'm going to work on her...rest.
I didn't like the yellow tint some of the above photos had. This was actually due to the lighting. If "anyone" with a photography background is reading this, a few pointers about choosing good colors for lighting fill and angles would be helpful. Right now I'm only using one light source, in order to cast dramatic shadows and to emphasize subsurface scattering. She's not rigged at all yet, the only "rigging" she has is the pupil reflex, since her eyes are actually basically done, aside from some drivers to change eye color, until they get rigged for movement. I might put in some features later to do veins or blood shot effects, and parent them so they stay in place better, but they're really not part of the same object as the rest, so putting in shape keys doesn't hurt anything. What I'm saying is that I can't really pose her yet, since rigging requires the model to basically be finished, because if I add things after the model is rigged, those things fly off into wherever the model was before it was rigged. I can sculpt after the model is rigged, and I'm considering doing a simple rig before the sculpt in order to make certain areas more accessible, such as between fingers and under arms and things, but I can't do any dramatic posing yet.
Soon though.
One of the features I plan to add to this model is variable attributes. Once I've finished the rough draft, which is what this phase is actually, I'm going to try to make her highly pliable to modification via shape keys, so she can become taller, thinner, fatter, shorter, more/less buxom, darker, lighter, and modify her facial and physical features along certain guidelines so as to make a wide variety of characters from the same asset.
It's a decent chunk of work. There are ways to make it easier in the long run, and for strays, I really don't need it. There are two human characters in the demo video, a male and a female. Getting her props ready and animating her is more important, to be honest. However, making the model right the first time means that I don't have to come back to it later for actual production work on strays, and I can use her for other projects. That said, if the strays kickstarter is successful, I would have more time on my hands to work on it. Grr.
I plan to use the same assets in the future for later projects, which is why I'm building in features to this model that won't be used in Strays. This same character asset will have parts and features that will come into play when she's seen again in The Children of Tiamat, and in Fear and Loathing in Neo-Tokyo, the latter of which is likely to actually happen shortly after Strays, since it will share a lot of the same assets. Planning in this way is "green" in that it saves production time and recycles assets, and therefore money.
She's still naked.
I didn't like the yellow tint some of the above photos had. This was actually due to the lighting. If "anyone" with a photography background is reading this, a few pointers about choosing good colors for lighting fill and angles would be helpful. Right now I'm only using one light source, in order to cast dramatic shadows and to emphasize subsurface scattering. She's not rigged at all yet, the only "rigging" she has is the pupil reflex, since her eyes are actually basically done, aside from some drivers to change eye color, until they get rigged for movement. I might put in some features later to do veins or blood shot effects, and parent them so they stay in place better, but they're really not part of the same object as the rest, so putting in shape keys doesn't hurt anything. What I'm saying is that I can't really pose her yet, since rigging requires the model to basically be finished, because if I add things after the model is rigged, those things fly off into wherever the model was before it was rigged. I can sculpt after the model is rigged, and I'm considering doing a simple rig before the sculpt in order to make certain areas more accessible, such as between fingers and under arms and things, but I can't do any dramatic posing yet.
Soon though.
One of the features I plan to add to this model is variable attributes. Once I've finished the rough draft, which is what this phase is actually, I'm going to try to make her highly pliable to modification via shape keys, so she can become taller, thinner, fatter, shorter, more/less buxom, darker, lighter, and modify her facial and physical features along certain guidelines so as to make a wide variety of characters from the same asset.
It's a decent chunk of work. There are ways to make it easier in the long run, and for strays, I really don't need it. There are two human characters in the demo video, a male and a female. Getting her props ready and animating her is more important, to be honest. However, making the model right the first time means that I don't have to come back to it later for actual production work on strays, and I can use her for other projects. That said, if the strays kickstarter is successful, I would have more time on my hands to work on it. Grr.
I plan to use the same assets in the future for later projects, which is why I'm building in features to this model that won't be used in Strays. This same character asset will have parts and features that will come into play when she's seen again in The Children of Tiamat, and in Fear and Loathing in Neo-Tokyo, the latter of which is likely to actually happen shortly after Strays, since it will share a lot of the same assets. Planning in this way is "green" in that it saves production time and recycles assets, and therefore money.
She's still naked.
Re: [NSFW] Video Game Design Blog
I'm not sure whether this will be hard as hell or quick fix, so I thought I'd mention it. If you could add tearducts, and the slightly raised ridge surrounding her eyes where the lids meet when she blinks, it would do a lot to reduce that doll like quality that you're noticing.
also depending on how much detailed accuracy once on the breasts, they could use a little bit more connective tissue / ligament development as the breast connects to the arm. Specifically, the spot where when a woman lifts her arm up to the side, the ligmants tense to create the front ridge of the "arm pit" hollow. ( Also raising up the breast with the same motion.)
areolas look great btw. at least for cold weather mode. If you decide to pursue that hentai goal, you might consider a larger warm weather / puffy mode.
also depending on how much detailed accuracy once on the breasts, they could use a little bit more connective tissue / ligament development as the breast connects to the arm. Specifically, the spot where when a woman lifts her arm up to the side, the ligmants tense to create the front ridge of the "arm pit" hollow. ( Also raising up the breast with the same motion.)
areolas look great btw. at least for cold weather mode. If you decide to pursue that hentai goal, you might consider a larger warm weather / puffy mode.
<a href="http://www.wizards.com/magic/playmagic/ ... areyou.asp">Take the Magic: The Gathering 'What Color Are You?' Quiz.</a>
Re: [NSFW] Video Game Design Blog
So, I've been learning about Cycles.
Everything I've ever produced with Blender so far has been made using the "Blender Internal" render engine. Blender comes packaged with a more advanced and professional set of tools called Cycles that is comparable to the external render engines people use when making those fantastic images you see on the internet produced from 3DS Max and Maya that are almost indistinguishable from real life. Aside from countless hours of modeling and using real high definition photographs as textures, those are made by using node based rendering tools.
Unity has a plugin we intend to get our hands on called Shader Forge, which uses node based shader building, basically the industry standard for AAA graphics, and which would allow me to bring my handmade assets in line with the high quality ones I've spent money obtaining, namely the relief mapped terrain. How silly would it look to have a shitty model running around a well made landscape? Admit it, the first time you started Final Fantasy 7 you said "wtf? You did all that work on the set but like...almost none on the characters?" Those were yet the early days of polygons, and they ran around hand painted landscapes for lack of greener, polygonal pastures. Not so anymore.
In order to introduce myself to Cycles and avoid having a full blown hysterical episode (attempting the switch without preparation on my human model nearly accomplished this) I've been working with some primitives and experimenting with different shaders and materials.
Part of what makes Cycles special is the way it considers light sources. In Blender Internal (BI for short) a light source is only reflected off of a surface if that surface is a mirror. Even in a totally enclosed environment, a single point of light only illuminates objects within the radius specified in it's properties, and only in a straight line from it's point of origin. In Cycles, light only comes from objects, such as panels, or globes, or what have you, and even in a functional vacuum, such as with the default cube in a void, a light source always illuminates a subject from multiple angles, just as in real life.
When attempting to get the lighting right with Blender Internal, artists consult books about lighting in Blender. When attempting to get the lighting right in Cycles, artists consult sources about lighting in Photography and Film, because it works so much like how lighting works in real life.
However, "materials," the series of settings applied to surfaces to define how they are colored, shaded, illuminated, textured, and so on, are built completely differently in Cycles than they are in BI, hence the need for experimentation.
Most of the new progress in new editions of Blender is in the power and speed of Cycles, so making this transition would be beneficial. How the materials are imported into Unity is still not something I'm totally familiar with, but Cycles appears to work enough like Shaderforge that getting familiar with this interface now seems to be the best bet.
For my first experiment, I made a Christmas themed crystalline hanging image thingy. It's below. I know it's not Christmas. Next I'm going to work on a Valentine's Day themed one (in order to try to work with these shaders a little closer, and to try to some specific modeling techniques) which I'll post when complete. This image is the final revision after Hien asked for some adjustments to her taste. Enjoy. If it suffers from compression artifacts, I have a 1080p version I can send if someone wants it as a desktop wallpaper.
Everything I've ever produced with Blender so far has been made using the "Blender Internal" render engine. Blender comes packaged with a more advanced and professional set of tools called Cycles that is comparable to the external render engines people use when making those fantastic images you see on the internet produced from 3DS Max and Maya that are almost indistinguishable from real life. Aside from countless hours of modeling and using real high definition photographs as textures, those are made by using node based rendering tools.
Unity has a plugin we intend to get our hands on called Shader Forge, which uses node based shader building, basically the industry standard for AAA graphics, and which would allow me to bring my handmade assets in line with the high quality ones I've spent money obtaining, namely the relief mapped terrain. How silly would it look to have a shitty model running around a well made landscape? Admit it, the first time you started Final Fantasy 7 you said "wtf? You did all that work on the set but like...almost none on the characters?" Those were yet the early days of polygons, and they ran around hand painted landscapes for lack of greener, polygonal pastures. Not so anymore.
In order to introduce myself to Cycles and avoid having a full blown hysterical episode (attempting the switch without preparation on my human model nearly accomplished this) I've been working with some primitives and experimenting with different shaders and materials.
Part of what makes Cycles special is the way it considers light sources. In Blender Internal (BI for short) a light source is only reflected off of a surface if that surface is a mirror. Even in a totally enclosed environment, a single point of light only illuminates objects within the radius specified in it's properties, and only in a straight line from it's point of origin. In Cycles, light only comes from objects, such as panels, or globes, or what have you, and even in a functional vacuum, such as with the default cube in a void, a light source always illuminates a subject from multiple angles, just as in real life.
When attempting to get the lighting right with Blender Internal, artists consult books about lighting in Blender. When attempting to get the lighting right in Cycles, artists consult sources about lighting in Photography and Film, because it works so much like how lighting works in real life.
However, "materials," the series of settings applied to surfaces to define how they are colored, shaded, illuminated, textured, and so on, are built completely differently in Cycles than they are in BI, hence the need for experimentation.
Most of the new progress in new editions of Blender is in the power and speed of Cycles, so making this transition would be beneficial. How the materials are imported into Unity is still not something I'm totally familiar with, but Cycles appears to work enough like Shaderforge that getting familiar with this interface now seems to be the best bet.
For my first experiment, I made a Christmas themed crystalline hanging image thingy. It's below. I know it's not Christmas. Next I'm going to work on a Valentine's Day themed one (in order to try to work with these shaders a little closer, and to try to some specific modeling techniques) which I'll post when complete. This image is the final revision after Hien asked for some adjustments to her taste. Enjoy. If it suffers from compression artifacts, I have a 1080p version I can send if someone wants it as a desktop wallpaper.
Re: [NSFW] Video Game Design Blog
So, I'm sure you were all horribly disappointed by the lack of T and A in my last post, and the time elapsed since your last...dose. Well, I've made some improvements to the model and I've been working on skin tone, shape, and a lot of behind the scenes stuff. I appreciate the comments from before. One of the things I fixed was the actual breast shape. I used the guidelines for breast implant and reshaping for the ideal "teardrop" shape and did an inordinant amount of research to learn about the different elements that go into it. It's complicated. Guys have it easy. Anyway, renders are below. Enjoy.
Yeah, the hair still looks like crap, I know.
Yeah, the hair still looks like crap, I know.
Re: [NSFW] Video Game Design Blog
So, here we are, coding, at last.
Some of you might be under the impression that I've been writing code or programming this entire time, or that I was going to be writing a lot of code at some point. That was never the case. It could have been, I'm capable of it, but It is perhaps the least efficient course of action I can take. I will only be writing scripts, programs, and plugins when absolutely necessary. It happens to be necessary at this time.
I've been working diligently to find an easier way to do this, but there doesn't seem to be one. I need to expose the "blendshapes" of my test object to Hutong Playmaker as variables that it can manipulate, and though they are visible in the inspector in Unity, Playmaker is blind to them because they are functions there, rather than variables. I'm writing a script to Get (at start) and then Set (per frame) their values to those provided by floating variables. These should then become available to Playmaker to allow me to set Finite State Machines to control their behavior based on events in a much easier and organic way.
In order to do this once and correctly, what I want to do is to make the script detect all the valid BlendShapes on the mesh and create variables for each one. This way I don't have to go and write a script for each object, I can just add this component to any game object I import that has Shape Keys ("blend shapes" in Unity) and then create the right relationships with Finite State Machines as needed. Once the FSMs are built, they are actually components as well, so when multiple instances of the object are in use, they will all potentially have their own behavior and vertex animations working properly.
The reason I think I can do this is the Serialization support that Unity offers. What I understand so far is that, aside from a range of forbidden items, I can add the [Serializable] attribute to a script, and Unity will automagically serialize it. In this case, I need to give it a reference to the Mesh.BlendShapeCount property in such a way that it knows that I want to SetBlendShape(Int) to be equal to a new variable for each integer in the array Mesh.BlendShapeCount for the attached object. By using the attribute and keeping it from being a public class, I'm trying to avoid having all the blendshapes in the game synchronized to the same variables. However fun it might be to have a sea of breasts bouncing in perfect synchronization, if that bouncing is actually synchronized with the wind blowing through your hair, it might be just...weird. And it all defeats the point anyway. The point is realism and convincing character animation, not preposterous titilation. That's for later.
Here is your obligatory nudity, thanks for reading.
Some of you might be under the impression that I've been writing code or programming this entire time, or that I was going to be writing a lot of code at some point. That was never the case. It could have been, I'm capable of it, but It is perhaps the least efficient course of action I can take. I will only be writing scripts, programs, and plugins when absolutely necessary. It happens to be necessary at this time.
I've been working diligently to find an easier way to do this, but there doesn't seem to be one. I need to expose the "blendshapes" of my test object to Hutong Playmaker as variables that it can manipulate, and though they are visible in the inspector in Unity, Playmaker is blind to them because they are functions there, rather than variables. I'm writing a script to Get (at start) and then Set (per frame) their values to those provided by floating variables. These should then become available to Playmaker to allow me to set Finite State Machines to control their behavior based on events in a much easier and organic way.
In order to do this once and correctly, what I want to do is to make the script detect all the valid BlendShapes on the mesh and create variables for each one. This way I don't have to go and write a script for each object, I can just add this component to any game object I import that has Shape Keys ("blend shapes" in Unity) and then create the right relationships with Finite State Machines as needed. Once the FSMs are built, they are actually components as well, so when multiple instances of the object are in use, they will all potentially have their own behavior and vertex animations working properly.
The reason I think I can do this is the Serialization support that Unity offers. What I understand so far is that, aside from a range of forbidden items, I can add the [Serializable] attribute to a script, and Unity will automagically serialize it. In this case, I need to give it a reference to the Mesh.BlendShapeCount property in such a way that it knows that I want to SetBlendShape(Int) to be equal to a new variable for each integer in the array Mesh.BlendShapeCount for the attached object. By using the attribute and keeping it from being a public class, I'm trying to avoid having all the blendshapes in the game synchronized to the same variables. However fun it might be to have a sea of breasts bouncing in perfect synchronization, if that bouncing is actually synchronized with the wind blowing through your hair, it might be just...weird. And it all defeats the point anyway. The point is realism and convincing character animation, not preposterous titilation. That's for later.
Here is your obligatory nudity, thanks for reading.
Re: [NSFW] Video Game Design Blog
Ok, so, here's the deal.
The first step in getting my script to work was to try to get just a basic "my variable controls the desired property and is accessible in the inspector and is visible to Playmaker" script running, before moving on to serializing it and making automagic happen. This appears to be impossible, for now.
The SkinnedMeshRenderer object already has control of the Blendshapes and their weights, and though I was able to write and debug the desired script, it did not actually take over the blend shapes because the SMR already has control.
Ok, so I tried moving my script up the priority chain so that it's values would be used first and maybe...nope.
Grr. Ok, what if I....modify the Skinned Mesh Renderer so that it ONLY does what it actually needs to do, make the object appear in the game world, and stop it from fucking with my toys?
Well, it's part of the actual unity game engine, so I can't modify it's code. But I can see it's code.
Ok. So I'll copy it. And then comment out the part at the end getting in my way. And then deactivate the original and activate my modified version which doesn't interact with Blendshapes and.....
Nope. Theoretically, that would work. But in order to make things that interact with dll files, I need Unity Pro, because I think it thinks I'm making a plugin, which is Pro territory (1500 bucks a seat, and part of the point of the kickstarter.) Basically, even then, I'm not sure if what I did would work. My skinned mesh renderer work around produced an error log full of things like "you don't have permission" and "directive missing" even though all I actually removed was some method declarations pertaining to blendshapes, which should not have shit-canned the whole thing.
So. Now that I have a better understanding of the nuts and bolts of where the Blendshapes are governed, my last ditch effort is going to be to try access the value declarations directly with Playmaker, the hard way. Since a script can't override them. Guh.
This picture is from behind, looking up, and is substantially more explicit than usual, which is intended to "reward" people for wading through this technogarble. Or punish them further. Fuck you. Porn addicts. She's not even real. Though she has a uterus and ovaries, which is more than any other video game character can say.
The first step in getting my script to work was to try to get just a basic "my variable controls the desired property and is accessible in the inspector and is visible to Playmaker" script running, before moving on to serializing it and making automagic happen. This appears to be impossible, for now.
The SkinnedMeshRenderer object already has control of the Blendshapes and their weights, and though I was able to write and debug the desired script, it did not actually take over the blend shapes because the SMR already has control.
Ok, so I tried moving my script up the priority chain so that it's values would be used first and maybe...nope.
Grr. Ok, what if I....modify the Skinned Mesh Renderer so that it ONLY does what it actually needs to do, make the object appear in the game world, and stop it from fucking with my toys?
Well, it's part of the actual unity game engine, so I can't modify it's code. But I can see it's code.
Ok. So I'll copy it. And then comment out the part at the end getting in my way. And then deactivate the original and activate my modified version which doesn't interact with Blendshapes and.....
Nope. Theoretically, that would work. But in order to make things that interact with dll files, I need Unity Pro, because I think it thinks I'm making a plugin, which is Pro territory (1500 bucks a seat, and part of the point of the kickstarter.) Basically, even then, I'm not sure if what I did would work. My skinned mesh renderer work around produced an error log full of things like "you don't have permission" and "directive missing" even though all I actually removed was some method declarations pertaining to blendshapes, which should not have shit-canned the whole thing.
So. Now that I have a better understanding of the nuts and bolts of where the Blendshapes are governed, my last ditch effort is going to be to try access the value declarations directly with Playmaker, the hard way. Since a script can't override them. Guh.
This picture is from behind, looking up, and is substantially more explicit than usual, which is intended to "reward" people for wading through this technogarble. Or punish them further. Fuck you. Porn addicts. She's not even real. Though she has a uterus and ovaries, which is more than any other video game character can say.
Re: [NSFW] Video Game Design Blog
So, having reviewed some various advice threads on the internet, I think I'm going to continue whacking away at the BlendShape issue until I get it right, because it's worth it.
Let's be clear about something, this isn't about breasts.
Well, it's not about breasts for me. It may be about breasts for you. And that's...well, that's whatever.
Shape Keys are what I'm trying to use to undermine the need for TONS of other things. They are my secret NOT SECRET AT ALL weapon, they are my favorite tool, they are my fire.
The Shape Key is one of two fundamental forms of animation, the other being Armature animation, which is probably exactly what you think of when you think of computer animation. These two tools meet together with the "bone driven shape key" which is a little more involved. Let me explain.
An armature is a set of bone-like objects that deform a 'mesh' or a 3d model as they move, and which obey a series of joints, very much like bones could be considered to do in real life, the main difference with real life being that they do not support the model as they do in real life, so they have more freedom and can be used to control things that bones don't control in real life. An important bone in most character models is the "gaze bone," which is basically a target which both eye bones orient towards that sets the gaze of the character, the point at which their eyes intersect. In real creatures, this is an extremely complicated operation coordinating dozens of muscles and complex neural pathways. In 3d modeling, it's setting an IK target of 1 bone depth and detaching it, then repeating the process on the other eye bone. Eye bones are another thing we don't have in real life.
So when you move a head bone, an eye bone, or a finger bone, the corresponding mesh deforms as it's been told to, usually to a pattern of weight painting, so that more than one bone can deform a given section of a mesh. If I tilt my head back my neck deforms to conform to this, but if I raise my shoulder, it deforms my neck as well. This is done by giving both my shoulder bone and head bone some weight control over the neck mesh.
A shape key is in some ways the opposite of an armature. A shape key is a specific configuration of the mesh or model, and is then given an influence (typically thought of like a percent of 0 to 100, but you can usually force it negative or over 100 and let the machine calculate what that means) to determine to what degree the mesh is in that configuration. This is most often done for facial animation. Take the smile for instance. Using armatures for facial animation is usually not great, shape keys are usually what is desired there. So, the Basis, the default shape, is a neutral mouth pose. Then we set a shape key in which the face is smiling. At 0 the face is still in the default shape, but at 100 it's exactly like the smile we designed. At 50 it is not like either the basis we made, nor is it like the smile we made, it is between the two, which is interesting to say the least.
Shape keys work with other shape keys, and (unless bugs or other weirdnesses crop up) deform with bones. So if you smile halfway, and then use a shape key to open the mouth halfway (50% of the open shape key) and then turn the head with the head armature bone, everything is being calculated by the machine. You've really only made three things (aside from your model) but your'e now seeing something new that you didn't make.
These are the fundamentals of computer animation that everyone learning this stuff gets indoctrinated to, and everyone learns to use armatures and shape keys when making cg animation.
Now we're going to talk a little about what I'm doing differently. Since they seem to be popular with this crowd, we'll talk about breasts.
Soft bodies are usually the go to solution for bouncing breast physics. I've experimented with this, and what you wind up with is up and down motion only, jello-like consistency for the most part, and if the model takes an orientation other than standing, the breast jiggles and then returns to the same orientation as it had when the model was standing. This is...not how breasts behave.
The reason that I am dedicated to getting them right is not, as I've mentioned before, to titillate and...spray come everywhere, but to portray women realistically. And also, other reasons, which I'll expand on momentarily.
Soft body physics calculations could theoretically be expanded or refined to produce the desired results. They are, however, time consuming. My machine is, as previously mentioned, a beast, and it cannot do them in real time. This means that any reasonable end user market cannot be expected to do them in real time either. So another solution is required. I have another solution. Shape keys and the already robust and real-time rigid body physics.
Rigid Bodies are what you usually think of when you talk about physics simulations in video games and computers. Cars smashing into walls, bullets bouncing off of armor, ragdoll physics, that kind of thing. Computers are good at this because they are far more friendly as far as calculations are concerned. For example, an object that is a rigid body is usually considered to be all one thing, so the computer needs to know it's speed and location and collisions, and that's most of it, mass, bounciness, friction, and so on. Throw in aerodynamics for good measure. In Soft Bodies, each vertex (most models in high quality video games have between 5000 and 10000 vertices) is calculated as a separate particle with it's own speed, location, collisions, and spring tensions between it and it's neighbors, in addition to the same rigid body dynamics.
So here's my model for breasts. On a separate (and un-rendered) layer, behind each breast is a sphere. Within that sphere is a much smaller sphere, which is a free falling rigid body. The smaller sphere has a bounciness and mass with variables determined by the attributes of the breasts. The larger sphere has friction determined by the same. In the center of the larger sphere is a cone that originates from the center and always points at the smaller sphere. The large sphere has a mesh collider (meaning that rigid bodies know when they hit it and react accordingly, with great precision) and it's collision iterations cranked up by script (making sure the smaller sphere doesn't fall out.) Additional scripts protect the spheres from bugs, so if the smaller sphere falls out or glitches and gets stuck, it is destroyed and re-spawns.
Instead of processor heavy physics calculations about bouncing breasts, we make shape keys for the breasts in the up, down, left, right, laying back, leaning forward, and neutral positions. The influence of these shape keys is then governed by the rotational angle of the cone in the middle of the sphere. Clothing, such as a bra or a corset, controls a shape key on the larger sphere, arresting most of the motion of the smaller sphere but not all of it. (Most clothing usually functions as paint against shape keys anyway, so this can help against bouncing dress syndrome.)
Other forces encountering the character, such as pressing against walls or other characters, strike a series of colliders that are attached to the smaller sphere itself, exerting force to change the shape anyway.
This same concept can apply to other aspects as well. Large breasts are notoriously bouncy, and small breasts are not. The size of the breast can determine the size of the outer sphere, the weight or bounciness of the smaller sphere, the friction of the larger sphere, and so on.
Enough about breasts.
At the last Kingmaker game, I got some amazing feedback. I know that a lot of horny teenage men out there crave for moving breasts. I know that a lot of moms wish the moving breasts were more realistic and less like jello. But what was interesting to me was that the women in the room were more interested in hair than breasts and butts. I heard you.
I've been studying my options for hair and how it could work. I've come up with what could be a solution. Using the particle hair system in Blender, which is quite pretty but demands a great deal of processing time when dealing with things like wind and physics, even more so than soft body dynamics, we set up extremes and styles and conditions, such as hair being blown in given directions, several hair styles, (or a lot of hair styles), wet hair, frizzy hair, hair laying against a variety of curved objects, hair laying against a flat object, and so on, much like we're doing for breasts and other soft parts of the body. Then we convert each of these hair configurations into a mesh, and then convert those meshes into shape keys for a single hair object. This is where things get tricky. A realistic hair design is a LOT of verts. I have this going on right now (it's rendering) and the model is at 6 million triangles. A normal AAA quality CG model for a high end video game might have ten thousand. Now, this includes geometry she doesn't need, like detailed curvature of her ovaries and other highly sculpted things that will go away later, but a lot of that is hair, when it wasn't before.
I think a balance could be found between using mesh geometry and particles/shaders. Fewer strands of hair, or hair with less geometry, could be made more realistic by duplicating it as particle strands, or making copies of it or blurring it with a special shader, like the FurFX people did.
All that said, I think it could be done pretty well with just geometry if we can keep the face count low. Right now it's most of the model and it doesn't look very good, because I hurried it out. Since it's not using particle rules any more, it'll need to have the material and textures re-designed, but that's not that big of a deal. Her hair might look thinner because it is. Well, because the particle effects aren't making the hair look thicker.
So, the point of all this? The reasoning beyond beautiful hair and bountiful heaving breasts that I'm doing all this?
I keep saying "this game won't make itself! gotta get back to it!" Well, that's not technically correct. The game will make itself, once I teach it how. That's where the Shape Keys come in. Beyond the useful physics workarounds, the male and female and canine character models will have shape keys expanding their appearances into a huge diversity, and once I can expose those shape keys to the parts of the game engine I can prepare AI behavior in, then the game itself can produce millions of characters as needed, and as long as I make those rules reasonable, and link the shape keys together so that unreasonable forms don't come into being, then the game will make the characters we need in abundance, a greater abundance than available in other games.
It's not just living characters either. I can make a single "proto-car" asset, and then give it shape keys that make it a truck, a van, and a sedan, and then let the game randomize different cars having those attributes in different values. A given vehicle might be truck-like or van-like or both. An NPC could do a ray-cast over a parkinglot (a process determining what he can see) returning the truck-like values of the shape keys of all the cars he can see. If your car has the most, he can approach you and complement you.
"Greetings Character. I detect that your vehicle is the most truck-like vehicle in this vicinity. I favor truck-like vehicles. My affinity towards you is therefore increased. Goodbye."
In a game like Grand Theft Auto, Saint's Row, Watch Dogs, Sleeping Dogs, or what have you, there could be 40 to 50 different cars. In a game like Asseto Corsa, or Gran Turismo, there might be 1000 or more. What I just described above would take an amount of time equal to that required to make basically four different cars (counting the proto-car) and would result in 800 distinct vehicles, calculated assuming increments of 5% to make sure they are distinct from one another. (Technically an infinite number, as the shape keys can be driven above 100%, but nobody wants mega-van.)
This same process is planned for all the assets in the game. Even minor assets like food items should get a couple shape keys so they can be randomized and then the game world is suddenly populated with non-identical things. Instead of one steak object, I make a steak object and then give it a couple shape keys, and then when it's instanced it has those keys randomized, and is oblong, or thick, or whatever.
So I drive on, and hope to ultimately succeed in exposing BlendShapes (as Shape Keys are called in Unity) to the AI tools I'm using. In the mean time, I have a short video rendering that I'll try to host somewhere. I'll post some shots of our favorite model getting her hair messed up by a blast of air, demonstrating shape keys in action as they might apply to hair.
As an aside, the most important thing we could take from using shape keys in hair is the use of extreme styles and then finding in-between points for them. That would be good. Most games with lots of hair variety have several dozen hairstyles. We could go beyond that.
G
Let's be clear about something, this isn't about breasts.
Well, it's not about breasts for me. It may be about breasts for you. And that's...well, that's whatever.
Shape Keys are what I'm trying to use to undermine the need for TONS of other things. They are my secret NOT SECRET AT ALL weapon, they are my favorite tool, they are my fire.
The Shape Key is one of two fundamental forms of animation, the other being Armature animation, which is probably exactly what you think of when you think of computer animation. These two tools meet together with the "bone driven shape key" which is a little more involved. Let me explain.
An armature is a set of bone-like objects that deform a 'mesh' or a 3d model as they move, and which obey a series of joints, very much like bones could be considered to do in real life, the main difference with real life being that they do not support the model as they do in real life, so they have more freedom and can be used to control things that bones don't control in real life. An important bone in most character models is the "gaze bone," which is basically a target which both eye bones orient towards that sets the gaze of the character, the point at which their eyes intersect. In real creatures, this is an extremely complicated operation coordinating dozens of muscles and complex neural pathways. In 3d modeling, it's setting an IK target of 1 bone depth and detaching it, then repeating the process on the other eye bone. Eye bones are another thing we don't have in real life.
So when you move a head bone, an eye bone, or a finger bone, the corresponding mesh deforms as it's been told to, usually to a pattern of weight painting, so that more than one bone can deform a given section of a mesh. If I tilt my head back my neck deforms to conform to this, but if I raise my shoulder, it deforms my neck as well. This is done by giving both my shoulder bone and head bone some weight control over the neck mesh.
A shape key is in some ways the opposite of an armature. A shape key is a specific configuration of the mesh or model, and is then given an influence (typically thought of like a percent of 0 to 100, but you can usually force it negative or over 100 and let the machine calculate what that means) to determine to what degree the mesh is in that configuration. This is most often done for facial animation. Take the smile for instance. Using armatures for facial animation is usually not great, shape keys are usually what is desired there. So, the Basis, the default shape, is a neutral mouth pose. Then we set a shape key in which the face is smiling. At 0 the face is still in the default shape, but at 100 it's exactly like the smile we designed. At 50 it is not like either the basis we made, nor is it like the smile we made, it is between the two, which is interesting to say the least.
Shape keys work with other shape keys, and (unless bugs or other weirdnesses crop up) deform with bones. So if you smile halfway, and then use a shape key to open the mouth halfway (50% of the open shape key) and then turn the head with the head armature bone, everything is being calculated by the machine. You've really only made three things (aside from your model) but your'e now seeing something new that you didn't make.
These are the fundamentals of computer animation that everyone learning this stuff gets indoctrinated to, and everyone learns to use armatures and shape keys when making cg animation.
Now we're going to talk a little about what I'm doing differently. Since they seem to be popular with this crowd, we'll talk about breasts.
Soft bodies are usually the go to solution for bouncing breast physics. I've experimented with this, and what you wind up with is up and down motion only, jello-like consistency for the most part, and if the model takes an orientation other than standing, the breast jiggles and then returns to the same orientation as it had when the model was standing. This is...not how breasts behave.
The reason that I am dedicated to getting them right is not, as I've mentioned before, to titillate and...spray come everywhere, but to portray women realistically. And also, other reasons, which I'll expand on momentarily.
Soft body physics calculations could theoretically be expanded or refined to produce the desired results. They are, however, time consuming. My machine is, as previously mentioned, a beast, and it cannot do them in real time. This means that any reasonable end user market cannot be expected to do them in real time either. So another solution is required. I have another solution. Shape keys and the already robust and real-time rigid body physics.
Rigid Bodies are what you usually think of when you talk about physics simulations in video games and computers. Cars smashing into walls, bullets bouncing off of armor, ragdoll physics, that kind of thing. Computers are good at this because they are far more friendly as far as calculations are concerned. For example, an object that is a rigid body is usually considered to be all one thing, so the computer needs to know it's speed and location and collisions, and that's most of it, mass, bounciness, friction, and so on. Throw in aerodynamics for good measure. In Soft Bodies, each vertex (most models in high quality video games have between 5000 and 10000 vertices) is calculated as a separate particle with it's own speed, location, collisions, and spring tensions between it and it's neighbors, in addition to the same rigid body dynamics.
So here's my model for breasts. On a separate (and un-rendered) layer, behind each breast is a sphere. Within that sphere is a much smaller sphere, which is a free falling rigid body. The smaller sphere has a bounciness and mass with variables determined by the attributes of the breasts. The larger sphere has friction determined by the same. In the center of the larger sphere is a cone that originates from the center and always points at the smaller sphere. The large sphere has a mesh collider (meaning that rigid bodies know when they hit it and react accordingly, with great precision) and it's collision iterations cranked up by script (making sure the smaller sphere doesn't fall out.) Additional scripts protect the spheres from bugs, so if the smaller sphere falls out or glitches and gets stuck, it is destroyed and re-spawns.
Instead of processor heavy physics calculations about bouncing breasts, we make shape keys for the breasts in the up, down, left, right, laying back, leaning forward, and neutral positions. The influence of these shape keys is then governed by the rotational angle of the cone in the middle of the sphere. Clothing, such as a bra or a corset, controls a shape key on the larger sphere, arresting most of the motion of the smaller sphere but not all of it. (Most clothing usually functions as paint against shape keys anyway, so this can help against bouncing dress syndrome.)
Other forces encountering the character, such as pressing against walls or other characters, strike a series of colliders that are attached to the smaller sphere itself, exerting force to change the shape anyway.
This same concept can apply to other aspects as well. Large breasts are notoriously bouncy, and small breasts are not. The size of the breast can determine the size of the outer sphere, the weight or bounciness of the smaller sphere, the friction of the larger sphere, and so on.
Enough about breasts.
At the last Kingmaker game, I got some amazing feedback. I know that a lot of horny teenage men out there crave for moving breasts. I know that a lot of moms wish the moving breasts were more realistic and less like jello. But what was interesting to me was that the women in the room were more interested in hair than breasts and butts. I heard you.
I've been studying my options for hair and how it could work. I've come up with what could be a solution. Using the particle hair system in Blender, which is quite pretty but demands a great deal of processing time when dealing with things like wind and physics, even more so than soft body dynamics, we set up extremes and styles and conditions, such as hair being blown in given directions, several hair styles, (or a lot of hair styles), wet hair, frizzy hair, hair laying against a variety of curved objects, hair laying against a flat object, and so on, much like we're doing for breasts and other soft parts of the body. Then we convert each of these hair configurations into a mesh, and then convert those meshes into shape keys for a single hair object. This is where things get tricky. A realistic hair design is a LOT of verts. I have this going on right now (it's rendering) and the model is at 6 million triangles. A normal AAA quality CG model for a high end video game might have ten thousand. Now, this includes geometry she doesn't need, like detailed curvature of her ovaries and other highly sculpted things that will go away later, but a lot of that is hair, when it wasn't before.
I think a balance could be found between using mesh geometry and particles/shaders. Fewer strands of hair, or hair with less geometry, could be made more realistic by duplicating it as particle strands, or making copies of it or blurring it with a special shader, like the FurFX people did.
All that said, I think it could be done pretty well with just geometry if we can keep the face count low. Right now it's most of the model and it doesn't look very good, because I hurried it out. Since it's not using particle rules any more, it'll need to have the material and textures re-designed, but that's not that big of a deal. Her hair might look thinner because it is. Well, because the particle effects aren't making the hair look thicker.
So, the point of all this? The reasoning beyond beautiful hair and bountiful heaving breasts that I'm doing all this?
I keep saying "this game won't make itself! gotta get back to it!" Well, that's not technically correct. The game will make itself, once I teach it how. That's where the Shape Keys come in. Beyond the useful physics workarounds, the male and female and canine character models will have shape keys expanding their appearances into a huge diversity, and once I can expose those shape keys to the parts of the game engine I can prepare AI behavior in, then the game itself can produce millions of characters as needed, and as long as I make those rules reasonable, and link the shape keys together so that unreasonable forms don't come into being, then the game will make the characters we need in abundance, a greater abundance than available in other games.
It's not just living characters either. I can make a single "proto-car" asset, and then give it shape keys that make it a truck, a van, and a sedan, and then let the game randomize different cars having those attributes in different values. A given vehicle might be truck-like or van-like or both. An NPC could do a ray-cast over a parkinglot (a process determining what he can see) returning the truck-like values of the shape keys of all the cars he can see. If your car has the most, he can approach you and complement you.
"Greetings Character. I detect that your vehicle is the most truck-like vehicle in this vicinity. I favor truck-like vehicles. My affinity towards you is therefore increased. Goodbye."
In a game like Grand Theft Auto, Saint's Row, Watch Dogs, Sleeping Dogs, or what have you, there could be 40 to 50 different cars. In a game like Asseto Corsa, or Gran Turismo, there might be 1000 or more. What I just described above would take an amount of time equal to that required to make basically four different cars (counting the proto-car) and would result in 800 distinct vehicles, calculated assuming increments of 5% to make sure they are distinct from one another. (Technically an infinite number, as the shape keys can be driven above 100%, but nobody wants mega-van.)
This same process is planned for all the assets in the game. Even minor assets like food items should get a couple shape keys so they can be randomized and then the game world is suddenly populated with non-identical things. Instead of one steak object, I make a steak object and then give it a couple shape keys, and then when it's instanced it has those keys randomized, and is oblong, or thick, or whatever.
So I drive on, and hope to ultimately succeed in exposing BlendShapes (as Shape Keys are called in Unity) to the AI tools I'm using. In the mean time, I have a short video rendering that I'll try to host somewhere. I'll post some shots of our favorite model getting her hair messed up by a blast of air, demonstrating shape keys in action as they might apply to hair.
As an aside, the most important thing we could take from using shape keys in hair is the use of extreme styles and then finding in-between points for them. That would be good. Most games with lots of hair variety have several dozen hairstyles. We could go beyond that.
G
Re: [NSFW] Video Game Design Blog
OK, so, the shape keys didn't look that great in hair the way I did them, which was extremely quickly because I was mostly concerned about getting them to work at all, which took a really long time to get them to be visible as strands of hair and then to also transfer onto the same mesh. The video looks like crap. It's on Youtube as Private, so please don't share the URL. Here it is if you care:
http://youtu.be/vON8QpwNPrg
The hair just kinda morphs from one position to another. This is because the keyframes I put in are equidistant, unlike how they should be. If I do this like I suggested we should, by having a controlling object that is responsive to wind and behaves like a single strand of hair, using, for example, the same rules that govern blades of grass in Unity, all the hair should behave pretty close to correct, within the confines of the shape keys. We can go from a "made" hairstyle, to "blowing in a given direction" or "wet" to "messed up" and then let the player take a "fix my hair" action, or have the character do that as part of an idle automatically, and restore the hair to the "made" style.
In other news, I have succeeded in writing a simple script in C# that exposes control of BlendShapes to Playmaker during runtime, which will allow me, potentially, to do all of the above and more. It's just a matter of writing the rest of it now.
With this hurdle cleared, I can finish modeling the female.
I am about ready to select a branch point from which I will actually convert the female into the male. Far too much detail has already been done well to bother doing it over. I can remake the "bits" that don't belong. Worst case, his chest winds up with more verts than one would expect. I can actually pluck them out if need be. Once I'm ready to start putting in the shape keys that define female parts moving around or things like that, the branch point will have been reached.
http://youtu.be/vON8QpwNPrg
The hair just kinda morphs from one position to another. This is because the keyframes I put in are equidistant, unlike how they should be. If I do this like I suggested we should, by having a controlling object that is responsive to wind and behaves like a single strand of hair, using, for example, the same rules that govern blades of grass in Unity, all the hair should behave pretty close to correct, within the confines of the shape keys. We can go from a "made" hairstyle, to "blowing in a given direction" or "wet" to "messed up" and then let the player take a "fix my hair" action, or have the character do that as part of an idle automatically, and restore the hair to the "made" style.
In other news, I have succeeded in writing a simple script in C# that exposes control of BlendShapes to Playmaker during runtime, which will allow me, potentially, to do all of the above and more. It's just a matter of writing the rest of it now.
With this hurdle cleared, I can finish modeling the female.
I am about ready to select a branch point from which I will actually convert the female into the male. Far too much detail has already been done well to bother doing it over. I can remake the "bits" that don't belong. Worst case, his chest winds up with more verts than one would expect. I can actually pluck them out if need be. Once I'm ready to start putting in the shape keys that define female parts moving around or things like that, the branch point will have been reached.
Re: [NSFW] Video Game Design Blog
The main thing that's been weird is that the mechanisms that work in Blender, such as the rolling sphere within a sphere, don't automatically translate into Unity. They need to be re-wired in order to work there.
I took a break after my last post to play Armello, a game featured on the Unity home page which is in Alpha right now on Steam. It's interesting, kind of a board game/card game/dice game/tactical RPG hybrid. It feels like it could be played out on the tabletop without losing anything.
Anyway, getting blendshapes to work in playmaker was a MAJOR victory today. I'm super happy. We can move ahead with that hurdle cleared. The next major issue is getting colliders to behave in a predictable and reasonable way. I think the problem I had was that Unity felt like the sphere was meant to be solid. I can model it to be very much NOT solid to see if that is the case, and can put little holes in it so that the interior communicates with the exterior. I'll also keep it on the outside of the mesh it's meant to effect, so that it's not in a solid block of that either. These things are important.
I took a break after my last post to play Armello, a game featured on the Unity home page which is in Alpha right now on Steam. It's interesting, kind of a board game/card game/dice game/tactical RPG hybrid. It feels like it could be played out on the tabletop without losing anything.
Anyway, getting blendshapes to work in playmaker was a MAJOR victory today. I'm super happy. We can move ahead with that hurdle cleared. The next major issue is getting colliders to behave in a predictable and reasonable way. I think the problem I had was that Unity felt like the sphere was meant to be solid. I can model it to be very much NOT solid to see if that is the case, and can put little holes in it so that the interior communicates with the exterior. I'll also keep it on the outside of the mesh it's meant to effect, so that it's not in a solid block of that either. These things are important.
