/agdg/ - Amateur Game Development General

9/30/17: I decided to retopo and half-redo the entire Shinobu human model to apply what I have learned using Blender. I started with the face an head. At this point I will still be tracing the face.

Comparison so far of the head topology from the old model (which was my first ever Blender model from 6 months ago), to the redo.

9/31/17: I realized that topology was very useful for giving shape to a mesh and not just for animation-friendly deformations. I noticed that the lips looked more natural. Comparison again old one on left. New one on right.

10/1/17: I worked on the retopo of the torso. I apply shrinkwrap to the old Shinobu model so I can still use the shape of it but rebuild it with better topology. I realized that topology follows musculature which is the reason it deforms better when animating and rotating bones. Shoulder blades were now a thing on the model.

Comparison old left. New on right.

10/3/17: Redid the front of the torso with better topology. At this point the new Shinobu model was still using the old shape which was not anatomically correct but that was because I was only interested in improving the topology. With the retopo I was able to allocate space on the body for small details like the abdomen.

Comparison old left. New on right.

10/5/17: The original model I applied subdivision in Blender because I was a stupid amateur and was not able to crank it up too high because the bad topology made ugly stretched triangles on some corners. On the new one however with the improved topology, I was able to crank up subdivision more without getting those ugly crunched triangles. It was also easy to see what exactly felt off about the old model. The butt was too low, the torso was too long, and the back was almost as flat as the front. I used the topology from the 3rd and 4th pictures.

Comparison old on left. New on right.

With better topology I was able to get better curves around places that needed smooth curves. Like feet.

10/6/17: Hands benefited largely from a smoother look which I thought would help later on during rigging. I also noticed that the more evenly spaced out vertices are (after sudivision), the better they will look. One of my mistakes with the original Shinobu model was applying subdivision permanently which made tweaking the mesh afterwards never evenly distributed like if it was done with subdivision modifier. Always keep your subdivision modifiers.

Comparison old on right. New on left.

10/9/17: At this point I took off the shrinkwrap modifier and was pulling and pushing vertices around for more accurate anatomy. The better topology helped me find important places of the body that needed detail like the pelvis and shoulder blades. I essentially sculpted bones with the subdivided vertices. This was a mistake I didn't realize at the time but more on that later.

10/12/17: I was knee deep in re-rigging the model and applied my experience with the original model where to place bones for optimal deformations. I saw tremendous improvements with how the body deformed compared to the original. It wasn't just a simple ball join deformation anymore. The topology almost seemed to simulate realistic ligaments and muscles. I am still very nooby at anatomy at this point but it was a great step in the right direction.

10/16/17: Arms also saw an improvement in smoothness and was also easier to rig. Applying subdivision to the original model was probably the biggest mistake. At the time it seemed like a good idea because I thought I would have had more vertices to weight paint and have more specific deformations. But that was a bad move. Reason being is that subdivision smooths out neighbouring vertex weights. This speeds up weight painting and softens neighbouring deformations. So again, don't ever apply subdivision.

Comparison old left. New on right.

10/17/17: I started to animate the new model to test out the new rig. I can't stress this enough: topology is magical. It reduces the time you spend making a mesh look good, makes deformation friendly, and overall gives it natural bends. This new walk animation was not only better animated, it just looked more realistic.

10/18/17: I did some work on textures and added pupils to the new model. The better facial structure, even-spacedness of vertices, and improved topology gave better shading to her in matcap. Also made her look cuter. Original model's face was too cheeky, square, and had weird mouth proportions. All of these 5 images are of the new model.

10-19-17: I took a break from the body and made some clothes. A good trick I came up with to speed up modeling time and keep the same weight painting deformations (so you can just paste the cloth mesh on top of the naked mesh), is to copy the torso portion that you want to cover in clothes, and just solidify it outwards. This keeps the exact same topology over the parts of the body it covers and copies the weight paints which prevents it from clipping with the body. Clothes also looked cuter because it looked like they fit her better.

Still being a noob at anatomy, someone pointed out that the navel was in the wrong abdominis. It is supposed to go on the bottom one not the top one. Left is wrong. Right is right.

10/20/17: Topology also helps you with unwrapping a model because it connects everything nicely together. If you select rings, you see everything flow neatly. This is perfect for marking edges as seams. I added some cheek, body, nips, butt, and torso color details.

10/21/17: Took another break and made a quick cute Halloween costume for upcoming Halloween. For the frilly pantsu I used my trick that just copies and solidifies the mesh on top.

Also made her trademark sun hat.

10/22/17: Made 2 pairs of shoes. Was good practice making shoes because I never made Mary Jane shoes. I used loads of Google images for reference. Very useful.

10/27/17: My first big rigging problem. Spent several days trying to freaking fix weights around the pubis and leg. No matter what I did I had hideous sharp triangle crunching deformations when the legs went up. The topology was there and was helping me but the weight painting was hard. Online modelers recommended weight painting the leg so it clips inwards to the torso sharply and to smooth the weights where it connects to the torso. In the end it was just trial and error until I got it looking good and learning to NOT do the following:

From >>30087 saying that it was a mistake to treat the subdivided vertices like sculptable vertices. It was a terrible mistake. It seemed like a normal thing to do. If I wanted a little bump on the hip to make a pelvic bone, I would move the subdivided vertices together, making a little pinch that looks like a bump. However, doing this disregards the topological position of those vertices that you pinched together. It is essentially sacrificing topology for shape. This royally fucks up deformations. So I had to undo my pelvic bone pinch and smooth out those vertices around there and move them to their correct positions. The pelvic bone was then weight painted in. This helped me get smoother leg deformations. So do NOT treat your subdivided vertices like sculptable vertices. It's okay to do it a little bit, but avoid doing it. Vertex distribution is important! Do not sacrifice it for shape!

10/30/17: Finished her Halloween costume. I copied over the fixed weights and tweaked it to fit the costume mesh. Zero clipping even when layered on top of the nude model!

11/4/17: Started on the first version of her new mouth rig. I read up on basic facial musculature and smiles are very complex with lots of muscles acting at the same time. However, this is for a game rig so stuff needed to be simplified. Mouth rigs should provide simplified groups of muscles so that the animator can just pull and combine different muscles to make different kinds of facial animations. Funnily enough, Garry's Mod was the best fucking reference to use while doing this because Source still has unparalleled non-mocapped facial rigging. To emulate a frown, I pulled the mouth end vertices downwards like the "Depressor anguli oris" muscle that is in charge of making you sad. I also worked on a new tongue rig with basic move horizontal, vertically, in/out, and curl.

11//10/17: Restarted and remade a version 2 of the new facial rig. This included more mouth sliders like the upper lip controls and a pucker. Since this is an anime character the controls didn't need to be too complex.

Left is old facial rig from 6 months ago. Right is new one.

11/12/17: I did a short comparison of my journey since I started before the wedding. First pic is my first model from June 2017. Second pic is from the wedding day September 2017. And third pic is from today December.

>>30103 Meant November in this post.

11/14/17: I reshaped her feet. Feet come in all sorts of shapes and sizes and it is arguably easy to sculpt comfortable looking feet because it is a body part that people aren't very familiar with because it's not looked at in real life as often. Japanese feet tend to be square and that's how originally her feet were. However, sexy looking feet are harder to pull off and are more often longer and curved as opposed to square. After looking at a ton of porn from reputable artists, I gave her feet a more curvy look with sharper toes.

Comparison old left with new moving right.

11/16/17: At this point I got satisfied with the body model. Still was subject to changes but I started animating anyways. Something I came to realize that you should avoid but whatever. I began learning about what makes good animations. Good animations tend to have indication of cause and effect. When something happens, there should be a negative force to indicate its existence.

In the first old.webm, the body smoothly falls on the chair. A comfortable animation but not realistic. It's too floaty. The second new.webm improves upon this by animating what would really happen to your spine when it hits the chair.

12/01/17: I made several animations at this time of the year and really started to grasp what makes a movement believable. For starters, after watching tips from animators, head movement is very important. Most animals have natural shock absorbing and rotation correcting head muscles to keep the head in the same spot. When you move the body, the head is constantly trying to stabilize itself to not make you dizzy and what not. If you look at my animations, the head stabilizes itself to always face forward. This helped me achieve realistic jumping movements. Another good tip for good animation is to make everything organic and not mechanical. Don't sync bone movements. Make some move first and make others follow afterwards. If you are animating a 3-bone spine contracting, make the bottom move last. This will cause a ripple sort of effect on your animations and tremendously make the movement more natural.

That last blog brings this thread up to speed to my current model state. I sometimes spend time fixing small parts of the body. Today I fixed the breast shape. Originally I thought breasts fused somewhat in between each other and I thought it looked fine at the time. But today I realized that's not how boobs work. Boobs are pretty far apart from each other. Of course there are many different shapes and sizes but small loli ones tend to be almost lumpy. They also are very flat in between. The new fix I did today has 1 less ring on the aerola because I realized I didn't actually need it. Now it deforms better around the topology around the breast. I don't think I need nipple vertices.

Deformation webm showing new one first and the old one last. Image showing fixed shape on left. Old one on right.

12/26/17: Some guy on the /agdg/ pointed out that the breast was too low. It was indeed! I must have forgotten about the height when I retopod the mesh. Something I should have noticed. Looks much more firmer. Also fixed front of the head to be rounder.

12/27/17: I added another bone+driver to solve an issue with bones inheriting IK rotation. Sometimes you want bones to inherit IK rotation and sometimes you don't. If you animate a hand moving up and down, you probably want the hand to inherit the changing wrist rotation. But if you are animating moving from cliff ledge to ledge, when the hand grabs onto a ledge and your body passes by, you probably don't want the hand to inherit the changing wrist rotation (because its busy grabbing on). So I figured a way to solve this would be to add another driver bone "heel_rot_lock" that drives the influence of a Child Of bone constraint (with the target set to the IK bone). So when it's set to 0, the heel will have its own free world space rotation. And when set to 1, it will inherit and "attach" its rotation to the moving IK bone. Using this method I was able to apply it to a new animation for when Shinobu stands up from a seated position. Her hands temporarily lock onto her thighs (Child of but set to thighs) when she leans forward and pushes off from her thighs to give her support. I figured this would be a more natural way to animate her getting up. It worked well.

TLDR; I made a slider to parent rotations for IK bones.

First video is driver set to 0. Second video the driver is set to 1 but also shows how I animate all the existing sliders in my rig. Third is the finished animation.

>>30293

Feel free to ask any questions about rigging. Maybe I can learn something too.

12/28/17: Tweaked the collarbone topology because it had a bad curve path that was hard to make a good looking collarbone. The collarbone looks like a bow that goes from the edge of the shoulder to the front of the neck and as it goes to the neck it bends forward. Additionally the chest was still a little bit too low. The chest was also too far forward where the arm joint is. Arm joint is supposed to be in front of the chest where it meets with the chest. I also fixed the back as it was too thick and the shoulder blades were pointing up instead of down. Also made patootie ears.

Videos show old first. New last.

12/30/17: Almost 2018! I learned that you should NOT use "Child of" constraint to temporarily parent rotations. Reason being is that the quaternion rotations sling shot back when the influence is between 0 and 1. So it may look good at frames but when played it twitches. Which is very bad. I wrestled with this problem for a day and realized that my hand setup was wrong. The way I was doing it before was: the hand bone had inherit rotations ticked off so it always had world space rotation and had a Child Of to parent the wrist angles. This twitches between 0 and 1 influences. The new way is: Keep the hand bone with inherit rotation and simply "Copy [world to world] rotation" to the IK end bone which has inherit rotations turned off. A driver can now create a smooth blend between the parented hand and the unparented hand rotations without any twitching and crazy quaternion fuck ups. Currently, the heel bones also have the old twitchy method described here and I did not see any twitching because the legs were already pretty close to the resting position. But it is prone to twitching if the Child of influence has to travel an entire 180 degrees. So I will do the same thing for the heels.

Now my model can properly lock her IK bones in place and smoothly go back to unlocked.

12/31/17: 明けましておめでとうございます！ Happy New Year!

I did the impossible and fixed the spine today. You should NEVER edit the bone positions after animating because it will screw up those animations. However, my spine bones were just in the wrong place and I just had to go in and fix them. Luckily it wasn't that big of a deal because I haven't really animated the spine as much (but I did post-fix the laying down animations). The problem was that they were too far into the body and not distributed how the spine works. There should be 4 parts to your spine bones. The cervical (neck), the thoracic (ribcage), the lumbar (mid back), and the sacral+coccyx (pelvis). These should be represented by your neck, spine3, spine2, and spine1 bones respectively. The thoracic [spine3] should be the longest followed by the lumbar [spine2] then the sacral+coccyx [spine1] and last the cervical [neck]. With the improved distribution I was able to very easily see an improvement when the model bends over. Because this distribution prevents the body from bending halfway down the ribcage or in a weird part of the spine.

Image showing old left new on right. Video showing old first new last. Notice in the video how much smoother the curve of the back is. It's the same pose.

1/1/18: Fixed the ribcage shape and did a couple animations. The model before didn't have much of a ribcage shape to it. It was very smooth. The breasts were also still too dis proportionally large despite having the correct shape and location.

1/3/18: Fixed the armpit area and butt height. The butt glutes were too low in proportion to where the vagina would be. The armpit area was too far inwards. Normally, the back part of the armpits goes out farther than the front part of the armpits. This causes what looks like webbed arms when the arms stretch. The dip in this web is the pit.

Video showing old first new last.

1/6/17: For a few days I've been working on lewd features for my model. It has a shape key for a vagina and anal opening. Also has a shape key for inverted nipples which I had to figure out using circular aerola topology. There is also a bone for the vagina and anal position that can be used to pull/push the genital in a direction. Yes I did model the penis and it was a weird experience. I came up with a good way to rig a penis for intercourse animations:

If you just have the penis with 3 bones (shaft1, shaft2, shaft3), and use those 3 to emulate wigglyness, it is very difficult to animate it going into a hole because you would have to key and make sure each shaft section goes exactly into the hole without clipping into the hole edges. So what I did was I made a smart driver that controls 3 Damped Tracks. Depending on the height of the bone world Z driver; 0-0.33 activates damped track for shaft1, 0.33-0.66 activates damped track for shaft2, and 0.66+ activates damped track for shaft3. Using this method, each shaft section of the penis automatically targets and points to the either vagina/anus bone. And If I undulate the driver position, the penis will look like it is going into a hole section by section (shaft by shaft damped track). This way i was able to get a sexy animation and was very easy to edit and add movement afterwards without messing anything up because the damped track relieved the problem of having to manually frame by frame ensure the penis was sliding into the hole.

My VR game is not primarily going to be sexual. It's supposed to be a virtual companion and this should be a small feature.

1/8/17: FUCK. I realized my relaxed pose was not optimal for the arms. It was not a true A pose. Everything was fine except for the elbows they were not in a relaxed position. The purpose of an A-pose or a T-pose is to provide the model with an average pose so that animation deformations from this average won't be as strong. For example, my old way had the arms rotated with the palms facing the camera (image 1). This was not a relaxed pose but rather at a point where the elbows should no longer rotate forward anymore. So if I needed a pose where the arms were rotated inwards (image 2), this unrelaxed pose would give me, and it did, an ugly twisted arm deformation that not even shape keys would be able to solve. So what I did was rotate the actual mesh arms to the average rotation that they will be at, which was 90 degrees inwards. Result is image 3 now for inward elbow rotations.

The good:

*No more heavy bicep twisting and way better arm deformations

The bad:

*have to go back and fix ALL arm animations. FUCK

The ugly:

*Had to edit the actual bones themselves as well and rotate them 90 degrees to match the new relaxed mesh

I don't know why you haven't gotten any comments on your thread and progress. I am enjoying it and I'm sure other lurkers are as well. keep it up!

1/10/17: Another lewd progress entry. 2 problems solved.

First problem was having to redo her dentistry so her lips were more realistic. It's sort of hard to animate a mouth enveloping an object with the lips because you only have the bottom lips and the jaw to adjust for the size of an object (in this case a penis). The upper teeth and upper lips don't really move farther up when adjusting for an incoming object. All the enveloping and adjustment motion is done by the jaw which also moves the bottom lips. So I had to do lots of manual penis height and head rotation tweaking to get it so the top lips are always above the shaft so it looks like the lips are enveloping it. I remedied it a little bit by also making another bone+driver that makes the head always face a certain direction. So now I was able to change the neck rotation while maintaining the head to face a certain direction. Useful for lots of other animations. I applied it to eyes as well.

The second issue was the shaft clipping through the neck after enough distance. So I did a really cool and simple driver that makes the shaft parts target the neck instead of the mouth after the boneShaft Z position goes past a certain point. Essentially allowing objects to automatically snake their way down her throat. VERY useful and time-saving. Picture related shows the intervals that activates/deactivates the mouth to neck targeting. I also made a shape key that is also dependent of the driver bone position so it looks helluva lot more realistic. But the best part is that it's freaking automated. Drivers are amazing. Video shows me scrubbing back and forth on the result. The only part of the 3-part shaft penis I animated was the forward position and the boneShaft Z position.

>>30425

Thanks.

1/11/17 Messed around with some lewd animations in celebration of my favorite artist Yakumi Benishouga releasing a new Pachimonogatari. But today I ran into a problem with the dependency graph. Basically it was the animation when played, the drivers would update first and then the driver bones would update. This caused the drivers to not have their true position in a frame which caused the damped tracks to activate a frame late. This caused all sorts of throat clipping. This was a problem with Blender but after googling I ran my blender with ---enable-new-depsgraph which launched it with the new beta dependency graph that fixes this issue.

1/16/17: Did some more lewd animations and ran into an interesting problem. Realistic fluid simulations for VR. SEMEN.

VR is very taxing on hardware so things like fluid simulation almost seems impossible to do. However, if we can fake and "bake it till you make it", we can get some pretty good alternative results. The problem was how can we represent a fluid without a million particles. My take consisted of splitting the parts of the fluid into different objects: the trail and the splat. That way we can represent the trail as a 3 bone trail that can be animated and moved around, and a splat that is just a static mesh that grows a bit with a shape key. Originally I tried to use Blender's cloth physics to animate the 2 hanging cum strands from the mouth so they jiggle. It worked but goddamit Blender fucks up and turns into a buggy mess. It worked like this: cloth mesh is parented to rig head, semen strand bones in another rig bind to the cloth mesh vertices result so it can deform the strands according to the physics result. But when a Child Of was added to parent it all it still kind of worked but was very buggy. Probably because it caused a cyclic dependency in how it should update the drivers and stuff. All of this was so the 2 sement strands would jiggle. After wasting 2 hours I said fuck it and just hand animated them. It wasn't that hard really. I should have done that from the start. The last part to represent a fluid was visually. Matcaps to the rescue. By taking a matcap texture (kind of like a cubemap) and UV mapping it to an objects' normal, you can get some good reflective material that is very cheap. This will be used in Unity.

Animation is nowhere near done I didnt even animate the facial rig yet. Just the main face bones.

Hey man, are you using corrective shape keys with drivers? Do they export fine to Unity? Or just shape keys and changing the key value in Unity? Did you follow a specific a tutorial? I am following a few tutorial videos, but the drivers are not working on my model (trying to correct the shoulders)

>>30474

Yes I am using shape keys for the legs. I have not done any exporting into Unity. However, I am familiar with E4 and the process is similar. Your shape keys that are modified by a bone should export properly into the .fbx if you uncheck pic related "Apply Modifiers". This is because you CANNOT apply modifiers (like Subdivision, etc., except Armature) to a mesh that has shape keys!!!. So by unchecking it, you will now be able to export the animation with the bone driven shape keys included. That said, consider the following scenario:

Say you got your face rig animated with a bunch of shape key sliders. Not all of them are driven by drivers so not all of them will be animate-able in the dope sheet. You'll have to animate the rest of the shape keys in the Shape Key Editor and have a separate animation for that. So you've got 2 choices the second one which I much prefer: 1.) Make a driver bone for every freaking shape key that doesn't have a driver bone thereby removing the need to use the Shape Key editor and suffer an animating fate worse than death 2.) Bite the bullet and use the Shape Key editor.

Video related is old but it's for the kneecaps. I'm working on one for my elbows. You will want to use a glute bone to keep the butt nice and round instead of a shape key. However I am currently toying around with the idea for a corrective shape key around the pubis when the legs go really far up. Not sure if you will need something like that but I do because secks.

1/17/18: Starting to shy away from lewd animations for now and focusing on core fun features. I'd like for her to be able to play games with you. Maybe hand games so today I started by fixing and remaking the sitDownFloor animation. This new animation reworks the hand placement so she supports herself by grabbing onto the floor and her knee.

>>30423

I wonder how did that happen.

>>30130

The 4th webm shows your rig already having the arm bones broken into separate bones for bending and twisting, so you should be able to avoid any deformations if you had everything weighted and animated properly.

1/18/18: Repainted the elbow and made 1 animation. In my research for corrective blend shapes, it is normal and sometimes recommended to use a shape key for the elbows. Reason being is that it is impossible to paint perfect elbow weights because of the nature of 180 degree range bones. If you are interested in modeling, read this short article: http://www.3dfiggins.com/writeups/paintingWeights/

It is Maya but the author provides very good insight to general weight painting. Namely:

>Too often people spend so much time trying to get results that are not possible with a default skinCluster. If you are working in games, typically you cannot have blend shapes or too many corrective joints, so you paint weights to maintain as much volume as possible, hence penetration.

So what I had before and have now for elbow deformations is good enough for games. In fact, because it's VR it's probably best as I would save 2 blend shapes for processing. That said, elbows deform nicer with circular topology. I used the knife tool for that.

The new animation is for when she is happy and excited to play some game. I did not animate the facial rig (yet) nor the head rotations. Reason being is that the head will be rotated to face a certain direction when I use this animation so it is pointless to animate it now as the rotation will be overriden later on in real time. This was something I learned to do working on the wedding sim.

>>30497

I'm not a fan of corrective shapes, so if I need to address a particularly weird deformation I generally just add a joint-bone that does half of the join't total bend.

Basically a doll joint.

1/20/18: Made progress on another animation. this one took me a long time because Shinobu is supposed to be ecstatic and move around alot. The timesink was getting the random movement noise as she moves around her spine in a natural fashion (~3 hours because played around with various noises). I tried Googling stuff about generating noise on dopesheets or the graph editor and I couldn't find anything. The solution is probably to write a python script. Meh. I just made random ups and downs in each rotation channels, copied then to other channels, matched them so it was uniform, and scaled it until it was natural. It came out nice but the clapping could use a bit of tweaking down the line. I used this gif as reference as the movements were somewhat complex and hard to visualize in my head.

>>30518

Nice work anon. Im getting inspired. I too is making some lewd models but im still new. Im planning to make lewd games.

Question anon. Do you somehow still got the tutorials you've been watching? since i really need to get a head start. I just started modelling seriously just a few days ago.

Please reply as possible. Thanks. I came from /agdg/ in 4ch

Pic related are my progress. The blend s one is the main menu screen.

>>30525

Other pics of the models.

Mostly the clothing is embedded and inside the uniform is hollow since i dont know how to weight clothes.

>>30525

Hey man. I used this dude's tutorials for learning about shape when I started from the very beginning but it's just not a series I can recommend because it's an awful way to make good looking topology. I wrote a short post bashing Daniel Kreuter here: https://8ch.net/3d/res/824.html#904

I do however, recommend learning the tricks to model from him. He does teach you a neat way to model a nice and round head using extrusion and rotation. The rest of the body and what not, I'd say learn that somewhere else. What you want to do is retopo the anime head you have there and NOT use as many vertices. You've got way too many. You should have about as much or less than these 2 reference images. Once you got a good looking head, when you UV unwrap it, you should get one complete UV island to paint like my Shinobu. If it comes out in pieces you are doing something wrong. Look up Blender uv seam tutorials on youtube.

Some good tips to do when retopoing:

<Bind your "merge" vertices to an easy and fast to access key like Shift+Q

<make your topology follow the structure of your shape. Form follows function

<never make anything but quads no exceptions

<memorize these 3 types of topology poles. I made a quick picture. Each is used for

different types of turning the direction of quads

1/22/18: Upgraded the hands. I remade the hands from scratch. This is my 4th pair of hands I've made. I've really noticed that I can model stuff much faster. Only took me 5 hours this time around.

The reason I remade them was because the hands were so fucked in terms of topology and lacked the amount of vertices to give it good defining detail. I learned to make hands using Daniel Kreuter's videos and this was probably the last time his videos will come back to bite me in the butt. He is a good instructor but goddam he didn't have animation or detail in mind. The fingers were made from 4 point cylinders and that looked fine for me at the time. But the limited amount of vertices didn't leave me with enough vertices to make good looking fingernails. Which was another big reason for me to redo the hands. I went from 4 point to 8 point cylinders. The knuckle topology is much better and so are the palms as well, but it could still use a little bit of work. I went for more child like hands because Shinobu is a cute loli.

>>30534

Yeah i agree hes really kind of good.

>>30532

thanks a lot for some tips in here. Im currently retopoing my model. But i can probably improve my skull structure.

>>30534

Nah I'm just a weeb autist. My background is actually programming for a living. I started Blendering maybe March of last year, watched a lot of Proko, and used to do lots of SFM and Hammer map making. I also can't draw to save my life.

>>30541

Oh i see.

Well im already done with my topology in the face just now.

Do you animate them with subsurf on? (if thats possible) and those models you currently have

are subsurfaced right? Since whenever i disable subsurf 2nd pic related it looks like shit(well ofc it looks like shit)

>>30548

Looks better in ortho.

Perspective looks shit though.

Also im planning to put this on unity. I was hoping to use a nice shader but the free toon shader doesn't support shadows. Which is too bad for me. Thats why i dont see 3d r-18 games with shadows maybe because of the hardware limitations.

1/23/18: Upgraded the feet. Remade from scratch as well and went same technique of going from 4 point cylinders to 8 points for toes. This posed the problem of finding very simplified topology for the feet while maintaining the path for the shape of the foot and not being a clusterfuck. I came up with a good method for quickly fixing topology:

Essentially, when you have a square grid of vertices, you can merge to center opposing corners of 1 square to change the flow of vertices. You can also do the reverse by making a square from 2 other squares. And if you keep on doing it for merging opposing squares, you can really simplify the topology as you go. Video related, I wanted to make the squares I initially highlighted into 1 long path instead of having it be connected at a right angle. [that topology was purely demonstrational, final topo for foot is pic related]

I've noticed that there is a phenomenon when modeling, maybe it's just me, but the more you work on a body part, the less it feels familiar and thus the less you can shape it to be realistic. Like I would work on a finger for several minutes and suddenly I don't know what looks off about it anymore. I remedied this phenomenon by carefully keeping track of my changes. I like to tab out to object mode from edit mode and just Ctrl+Z and Ctrl+Shift+Z to see my changes over time. This makes me realized "Oh yeah that's what was off!".

1/26/17: Rigged the feet and began redoing and fixing a few feet animations because I changed the bone positions. Also Blender royally fucked me because some bones did not have a proper naming scheme which disallowed easy copy paste x-mirroring. Blender recommends your bones to be named like so: bone_l, bone_r, etc. All of my bones except for a few bones were named like that. So I went into my rig and renamed the few properly. Problem solved? No. It did rename the bones and did update the vertex group names as well, but the animation channels in ALL of my fucking animations DID NOT update. Meaning the new named bones are no longer affected by my animations. This is either a bug or Blender being retarded. Either way, now I have to learn to programmatically rename and fix the names with their API and python lest I want to hand rename hundreds of animation channels and for each sub channel like x,y,z. Fuck me.

>>30541

Damn, this is pretty amazing for someone with less than a year of experience.

>>30557

Thanks a lot man. Been following your studies a lot. Really appreciate it.

Ported her in unity and slapped a toon shader. Im really quite having problems in my frame rate though since i have a shit card. Anyways thanks a lot again

HALLELUJAH. I take back what I said about the Blender Stack Overflow community being bad. I guess they can be very timely and excellent. They work better on the weekends I guess. I made a question last night about a script to fix the names, lo and behold when I woke up it was answered and with a complete script. Will definitely save this script for later use. Animations are back in business.

https://blender.stackexchange.com/questions/99504/renaming-animation-channels-with-a-script/99506#99506

>>30599

That's great dude. I would definitely say the problem with the framerate is just the toon shader being trashy in the deferred renderer. I might not have the luxury of having high quality shaders for my game because it will be VR. I'm gonna have to use a forward renderer for maximum performance. Which means I have to optimize the fragment passes and write a fast toon shader. Luckily I'm a professional GLSL shader artists IRL.

1/27/17: Spent some more time fixing old animations because of the new hand and feet bones. I've decided I'm no longer going to fix old animations because if set backs occur that make me need to fix or redo the animations later, it becomes a waste of time. And time is a nodev's arch nemesis. So I will only make or fix animations only when actually implementing them into the game. I need to start formulating exactly how Shinobu's AI will work.

I also fixed some bone rotations for her rig. Her upper thigh bones adhered too strongly to the leg roll which made the weight paint protrude along the side. Rigging legs is pretty difficult because it has a huge range of motion and because the relaxed pose has the legs in standing position, leaving out almost 160 degrees of possible motion upwards and with 90 degree rolls, and ~80 degree yaws. If I really wanted to address these leg problems, I would seriously consider making her relaxed pose something like pic related, star pose. But again what I have now is good enough for me and overkill for an anime model. I compromised with a copy rotation and a damped track to fix roll 50% to favor 2 kinds of poses: standing, and crisscrossed legs. Video shows 3 states of the thigh roll correction. 0%, 50%, and 100%.

I spoke to the head of animation at my work (maya rigging veteran) and asked him what he prefers; A-pose or T-pose. He said it depends entirely on what kind of animations you want the mesh to perform. So in my case, Shinobu might walk, run, and rarely move legs really far up (because of missionary sex). Meaning I should not try to optimize the rigging for ALL possible leg poses. Meaning no splits, touching toes while seated, or stretching legs backward. It's not even something that I would use in the game anyways.

1/28/17: Started working on the new mesh for her hair. The old mesh looked good but it had no animation friendly topology and had very inefficient triangle placement (images 1 and 2). It was also not good for rigging strands of hairs. I also noticed that Shinobu's ears go in front of the little protruding side hairs. Old mesh didn't do this. So the first video is me timelapsing to fix this.

I am remaking the hair using the same method of using nurbes for each long hair. That way I can easily manipulate the volume and cross section of each hair strand all at once. Makes tweaking instantaneous, each strand perfect, and overall much faster to add or remove strands. I've seen lots of anime hair tutorials on Youtube and they look good but they seem to be more geared for animation. Meaning they don't worry about merging all of the hair strands together with good topology and few vertices. Since my game is VR, I need to develop a workflow for combining all of my hair strands into 1 hair mesh with no ugly triangle merges like the old hair mesh. I think what I'm going to do is manually retopo all the hair strands to create the combined mesh once I'm done with the base nurbe mesh.

Also anime hair is sort of hard to pull off because it has such a changing perspective defying shape. Not to mention it changes scene to scene. So this time around I am making it more realistic instead of focusing just on reference shape. It looks much better with this method.

>>30608

Where's the first part?

>>30621

1/29/18: Shit I said 2017 last blog post. But anyways I had minor success with the new workflow for retopoing the new hair mesh. I tried 3 different method all which are relatively painful but I stuck with the fastest:

Given a bunch of individual short hair strand objects that each have subdivision I tried 3 methods for combining the mesh while retopoing:

1.) Join all individual meshes into one big mesh. Make another new object that has subdiv+shrinkwrap applied which targets the big mesh. Retopo by manually creating vertices all around it. I gave up using this method because it was so goddam painful with the highly irregular surfaces of the big mesh. It also had pointy ends which is something shrinkwrap hates.

2.) Take the big mesh, clone it and apply shrinkwrap to that one which targets the big mesh. Then apply the shrinkwrap and add subdiv to manually connect hair strands to each other. I also gave up on this method because although it worked allowed me to retopo surfaces with pointy ends, it was just a pain in the fucking ass and the shrinkwrap made everything too round once I applied it because of the subdiv.

3.) The winner was taking all of the individual hair strands and still making the big mesh, then from here I would just connect each to each other. Similar to method 2 but it was directly with the individual mesh objects. This was the fastest method because it wasn't that hard to delete a few vertices and rebuild the connections with a good flowing topology.

I'm almost done with the new hair mesh I just need to add the side hairs that go under the ear and connect the long hair strands. I am a big believer in using only quads for topology but I noticed that triangles are very good for my specific purposes of separating hair strands. Video shows the new topo with the triangle separators highlighted.

1/30/18: Finally finished the new hair. Topology is beautiful compared to the old model, triangle count is now 8.2k from 3.7k, and now supports for awesome individual long hair rigging.

I realized that if I wanted Shinobu's new hair to have lots of control for individual hairs, then I shouldn't completely cover it with a single topological shape. So I kept each long hair strand separate until the nape of the neck where they connect neatly into the head hair mesh. As shown in the video, I will be able to pull each individual hair really high up while keeping the shape of her long blonde hair. I additionally made it so the bottom long hairs will show when the top long hairs are pulled up so it gives her hair volume. I was worried about overdraw but I made sure to minimize it as much as possible. Also the fact that her hair is symmetrical and asymmetrical in some parts made it a nightmare to get both sides mirrored. The internal connections of the long hair strands were also tricky to get right but taking an organized approach to connecting each hair helped alot.

Now on to rigging.

Extra credit for 1/30/18: optimized the connections for the long hair strands to patch the holes underneath. I'm really digging the deformations. I'm going to have to limit the number of bones for performance reasons. So for the long important hair strands I'll have 2 for each and the bottom hair strands I'll rig tomorrow with only a single bone.

I was able to navigate myself through the crazy clusterfuck of vertices and edges of the nape connection points by editing the mesh as it's being deformed by enabling caged vertices mode for the armature which is off by default.

1/31/18: Finished rigging the hair. Came out very well and I am very proud. A total of 29 deformation bones were used. I thought it seemed a bit high of a bone count but after looking at reference anime hair models this was actually not bad of a number.

To parent it to the actual body mesh, I gave it 2 bones; hairHead, and hairSpine3. They both are identical to the body armature's head and spine3 bones respectively. This would allow me to give them the weight paints of the locations that should be pinned by the body. The spine3 is in charge of parenting the long hair strands while the head is in charge of parenting the main head hair and short hair bangs. And then what I did to animate them alongside the body armature, I added a copy transform to the hairHead [targeting head] and hairSpine3 [targeting spine3]. That way it would just copy location, rotation, and scale whenever.

2/2/18: Made another animation (body_floor_sit_lose)[I forgot to animate one of her hands] and am starting to gear up for the first part of her logic: hand games. Demoday seemed to be a great success for /v/ today. Hopefully I can release a demo next time.

I'm using draw.io which is a good free online charting program that I use to prototype logic. Prototyping greatly speeds up development because you can much easily hammer out logic and don't have to worry about syntax or actually writing down code. Also allows you to see exactly what you need moving forward for an implementation. Right now I am prototyping so I can see what animations I will need.

Shinobu's AI will be logic heavy but I am pretty comfortable writing code. Modeling is not my background afterall, programming is.

2/4/18: Spent the weekend fixing some animations and making some new ones for the chopsticks mini game. I learned a few more very useful tricks for animating in Blender.

First one is using proportional mode (key O) within the graph editor. The video showing this trick demonstrates me wanting to slow down the head shake over time. However, the shake is not just tied to the head, indeed there are frames for the y quaternion for the head, neck, and spine3. So rather than inaccurately and tiresomely reducing the change of y quaternion over time individually, I select all 4 bones and use proportional editing. In order to keep your change consistent for all of these bones, I made sure I was looking at the graph in normalized mode which makes it so it snaps to the min and maxes of each graph respectively, thereby making the min and max for all 4 bones the same.

Second trick is cooler but it is essentially using both FK and IK animations at the same time. Rather than leaving the FK/IK control bone at full 0 or 1, I left it at 0.5 so it has 50% influence from both types of animation. The forward kinematic action was just the hands shaking and the inverse kinematic action was only used to reposition the shake. Without this trick, it would be painful to tweak the position in which either hand shakes at. I used this trick to just slightly make the hands move backward in the final animation. Second video shows the trick.

I did a small tweak to the weight paints in the front. The tummy was caving in too much when bent forward.

Other 2 videos are the new body_floor_agree and body_floor_refuse animations respectively.

>>30675

Thanks man. Gamedev blogs are fun.

2/5/18: made some more chopsticks animations: body_floor_sit_chopsticks_idle_in, body_floor_sit_chopsticks_idle (not shown), and body_floor_chopsticks_react_neutral

One thing I hate about Blender is that whenever I switch animations, I have to manually set the endframe to loop during playback and there is currently no way to tie it to an animation action set. And I can't memorize how long each animation lasts. So in order to remedy this I've been using markers 1 for each action to remind me where the end of that animation is.

I'm starting to perfect my animation workflow in order to animate faster. From my wedding VR sim experience, animating can be very time consuming. My workflow is becoming more organized and faster. I try to follow it as much as I can. Currently it is as follows:

1.) Key the main poses into the dopesheet (stage1.webm)

2.) Desynchronize frames by just shifting frames a few seconds forward or behind (spine1 should animate way before spine 2, etc.)(stage2.webm)

3.) Tweak movements in graph editor for the important channels (stage3.webm)

As a bonus, when in stage1, I sometimes just shift+D keyed channel points in graph editor to make key the important poses which is faster than in the dopesheet for certain kinds of animations.

2/6/18: Made 1 new animation: body_floor_sit_chopsticks_react_worry and did a small temporary topo fix for the thigh.

I will be making several react animations for the chopsticks mini game so she has a more dynamic behavior. This one will play once in a while whenever she is about to lose. I'll make one tomorrow for when she is about to win. Note I have not yet animated the face rig yet. I just slapped on a worried face for show.

The thigh had an ugly caving in deformation whenever the leg moved up. This was caused by a topology pole being right on the edge of 2 deformations. This is why topology is important! This is probably the area I have the most trouble with but I have slowly learned how to handle topology better. The fix is not perfect but by simply shifting the pole 1 ring below I was able to finally connect the thigh ring all the way around and avoid having the pole sit between those 2 deformations. Poles should be in places that don't deform so this might even be okay to leave in although it's not optimal. At least it's better than before.

Also starting to brainstorm ways to send user input and interact with Shinobu. You will have 2 VR compatible controllers like the wedding sim but this is still very limited. I think I will be using a speech to text service so I can give commands to her. Speech to text is not really possible to do entirely on client side because it is not ideal to compute alongside a VR application and for good results requires machine learning. So a service like IBM's Watson or Google API might be necessary. This does not respect my freedumbs but I may have to bite the bullet and deal with it.

x2/7/18: Another productive day. I worked on 3 animations and by being a dumbass I lost 1. I accidentally deleted this animation (react neutral) >>30682 .Which is not so bad considering it wasn't very good for a neutral react animation. It seemed more like an idle animation. Easy to make.

I remade the neutral animation that I lost, improved the worry animation, and made a new confident animation. The neutral animation is much better compared to the old one because it actually looks like she is analyzing the game in a neutral way. The worry animation was not lively enough so I animated her shoulders and her knees so she is cuter. The confident animation will be used for when she makes a move and the user is about to lose, essentially when she is closer to victory.

>>30684

Because overdraw needs to be reduced, clothing will be handled by separating each clothing piece to its own mesh which will also include the body parts that they cover. So for example, a tanktop will have the tanktop mesh but will also include the shoulders and a small portion of the neck and arms. This way I can delete the vertices that are not visible under the clothing and not have to deal with clipping. I did it already for things like pic related, an old jacket (I have to remake it). However there are always exceptions. Some pieces of clothing will be difficult to have vertices deleted underneath because of topology or just the way it was shaped with subdivision, therefore each clothing must have a setting that will tell the game if it is better to just slap it onto the nude model. An example would be a bra or panty, I can't really delete the body vertices that are covered without destroying the subdivided shape or making huge holes. But despite this also alleviating the clipping problem, one downside is that I will have to plan out exactly how to split up dress-up able areas of the body. I think I will do the following:

<head

<torso

<thighs

<legs

<feet

<arms

<hands

If I want to make a cute onesie costume for her, that might cover multiple dress-up area categories using this method. So I will have to split that onesie costume into as many areas that I have. Which isn't too bad. Such is the life of a VR gamedev.

2/9/18: Finished one of the most laborious and difficult animations: standing up from sitting on the floor. Took me about 5 hours (I usually animate for 2~3 hours a day). This one was very complex compared to the standing up to sitting on floor animation because the body is acting against gravity this time. I had to really visualize how the body was moving and balancing itself as it stands up on 2 legs. I took into account the weight of each moving body part: torso is the heaviest, thighs are lighter, feet are lightest. This helped me make a convincing looking animation.

A good rule of thumb is to go for fast controlled movements. Never leave out a body part moving linearly or moving super slow. Make it look like the model is moving preemptively as if it knows what it is doing. The model is supposed to look like it is positioning itself for the next movement.

Also it is very important to be organized. You can save a lot of time organizing your bones into layers because it will reduce the time it takes for you to find a bone in the dopesheet. I always toggle whole layers off/on when working with animations so I only see few bones in the dopesheet.

One issue that I spent a lot of time on is IK/FK popping. Essentially, when you are blending between the 2 for like an arm, the elbow angle will snap from a straight line to a bent angle in a very short amount of time in between frame intervals. This looks like it's snapping or "popping" during playback. It is annoying fixing this because it is a very delicate reoccurring problem with FK/IK blending. The only way I know how to combat this is by making sure the IK targets don't move too fast and that the FK angles move alongside the IK.

2/12/18: Starting to work on the headpat logic for Shinobu. In the wedding sim I used a simple realtime 2-bone IK function to dynamically change the head position of Shinobu as I headpatted her so it felt like I was really dragging her head around with my hand. I will be doing the same thing with this set of animations and additionally include an additive animation. The additive animation will change as I headpat her and depend on her mood. Currently I have thought out happy and angry moods for her logic. The graph tree is the current logic for Shinobu's AI. The blue arrows are animations and if they are outlined green that means they are done. Red ones are yet to be created.

I planned out the exact circumstances in which certain animations will play and also design it in a modular way so I can always add stuff to it with ease. Headpatting can happen in various scenarios (when she is sitting, standing, laying down, etc.). As a result, each scenario will have its own set of headpat animations. This can be tedious but certain things can be reused to speed up development. Namely the face animation that accompanies a certain headpat body animation. The big upside of this is that headpat animations will be very adaptive to whatever her current pose is.

I only finished one of the headpat animations today: body_stand_headpat_angry_start. It looks a little stiff because it will be an additive animation. No point in animating her head if it will be dragged around in real time. Note her new hair has not been textured.

Another good tip for animating that helps a lot with organization is using the 'clean keyframes' functions in Blender. By highlighting the channels AND the frames you want to apply this to, Blender will automagically remove frames that don't change leaving behind only the frames that change. This gets rid of the cluttered look of the Dopesheet. However, this function removes all F-curve tweaks in Graph Editor so you should ONLY use this function during Stage 1 of the creation of an animation (keying only the main poses in dopesheet). Also organizing the order of your shape keys can help speed up the animation process by helping you locate groups of facial shape keys. Every single little thing helps in the long run. Time is my biggest enemy in 3D asset creation. Not that I have a deadline or anything.

>>30702

I don't know who that is. I haven't watched tv in years.

>>30707

Autism is adorable on lolis.

Also tweaked her stand up animation. Her footing was not natural.

2/12/18 I meant 2/11/18 last post

I did 2 new animations: body_angry_headpat_brush_away and body_angry_headpat_angry_to_relaxed

Both are additive animations as well.

I worked a little bit on the head and facial shape keys as well. I realized I couldn't do an angry mouth snare because I lacked bottom lip controls. So I made bottomLip_r and bottomLip_l. Now she can properly show her teeth in a variety of ways including a snare. Before today I had angryEye_l and angryEye_r which made Shinobu's eye lids and eyebrows angrier looking. However, when this angry look was turned on and the model attempted to blink with upperEyelid and lowerEyelid, the eyelashes would clip through because of the angry slant (pic related her right eye). So if I wanted her to blink without this problem I would have had to simply set the angry look to 0 when the eyes are completely closed. However, this meant that my model would not be able to maintain an angry look whenever she blinked and this looked weird and bad. So I split the angry shape keys into the eyes and the eyebrows (pic related her left eye). I also made the new eyebrow shape key go negative (-.3 ~ 1) so the model can reuse that shape key to also show a raising eyebrow expression.

I also tweaked her head shape as the bridge of her nose protruded too far outward. Her jawline was also too far out as well and did not smoothly transition to the back of her head. This has now been fixed. It is totally possible to edit the Basis of a model and for ALL the shape keys in it in one edit. Blender is just stupid about it. You have to tab into the Basis, make your changes, and then while still in edit mode, just click on another shape key to switch to it. If you see your changes applied itself to the other shape key, then it worked for all of them. If your edit didn't carry over, do it again.

>>30710

Yes of course. That animation is reserved for when she goes from happy to angry.

2/13/18: Didn't get much done today because piece of shit train delays from my work commute. I did however improve the 2 animations for body_stand_headpat_angry_start and body_stand_headpat_angry_to_relax. I didn't realize that I accidentally made 2 animations in 1: >>30712 .That old relaxed animation was supposed to be the *_angry_to_relax and the *_relax_to_happy animations. No biggie I just split them into their own respective action sets.

I improved her facial animations by using the graph editor for her face. You can very quickly add random ups and downs by just Shift+D and dragging into random locations. I used this method to make her angry lower eyelid twitch and to add a random jitter to her arms and spine to show that she is furious that you are petting her head when she is angry.

One thing I have always always been fond of in animation is good eye animations. Eye animations can breathe life into a stiff 3D model a 1000x more than a body animation. Most people don't realize this but this is because eyes are the part of the human body that people look at the most. For the wedding sim, I spent an enormous amount of time on her eye logic. I added random jitters, random blinks, constrained her eye angles to her eyesockets, and even added per pupil look-at-object tracking. And it worked so goddam well she felt so much realer when I married her. Eyes are so important. And even in AAA games nobody ever freaking gets eyes right! This is probably because it's not something that can be easily included in a mo-capped studio and the studios that do mo-cap pupil tracking (Hellblade comes to mind), the tech is expensive as fuck and presently cutting edge. So people always skimp on eye animations and sometimes hardly even make them blink. Crysis with it's insane graphic fidelity can't get eyes right either and they end up looking like dolls. You can have the shittiest model and still make it feel alive by just focusing on eye animations.

>>30713

Yes indeed I forgot to mention that my OBS recording is laggy. I play Blender animations and record at 20fps. True fps is 24. I'll record from now on without the body's subdivision to improve performance.

>>30715

Very nice Anon! Make sure you keep on practicing.

2/15/18: Worked on a few more very simple animations for the headpat system: body_angry_headpat_interrupt (used for when the headpat suddenly stops). I didn't finish body_headpat_happy_loop as it is a long animation and has lots of subtle movements. But it will be one of the loops for when you headpat her.

Finger and hand movements are also extremely important to make characters believable. Fingers in particular because it is a very animation dense area of the body (because it has so many bones). So I am making sure to animate her fingers in the way that she would react if she had her soft head rubbed.

2/16/18: Finished body_headpat_happy_loop and body_headpat_happy_start. The *_loop animation was kind of hard to see in textured mode so I recorded in matcap. The *_start one was the type of animation that required me to animate the pupils. All of the animations up to now are to have the pupils animated in real time so they can look at the user. That's why I didn't animate them.

I plan on giving her yet again complex eyeball mechanics when I put it together in Unity. I'll be using the same workflow from the wedding sim: Some animations have eyeball bone angles like for an eye roll. However, some have bone angles AND require to look at a certain object in real time. So animation events will be added to each animation action that will flip switches to blend between "Use animation eyeball bone angles" and "Use real time look at world object angles".

2/19/18: Gonna be busy these few days because I'm in charge of putting together the Valentine's Day Collage for /a/.

Worked on 3 facial animations for existing chopstick behavior animations: worry, neutral, and confident. I like animating faces because not only is it way faster and easier, but also because adding subtle movements makes a huge difference. I try to add blinking at points where a real person would blink (when shifting head, changing head rotation, being surprised). And also added subtle eyelid falloff movements so it's not static. Eyelids are important to display convincing emotions.

2/20/18: Pretty busy with collage so I got very little work done. I fixed her eyeball rotations for looking at things. The problem is that the shape of anime eye sockets are irregular and do not allow me to just place a big eyeball sphere inside because it does not fit inside properly. Anime eyeballs would intersect with each other if they were real. So making the pupils look at things accurately was harder than expected. The eye socket itself has to accommodate a curved plane with a pupil texture that must also not clip with the strange shape of the anime eyesocket rim. If I tried making small spheres for each eyeball, it would not cover the entire eye socket and would give her weird pop out bug eyes. As I've said before, anime anatomy does not make sense and porting it to 3D exactly will give you bad results. I came up with a stupid name for this phenomenon: The Uguu Effect. So a compromise was to make a curved plane rotate around a point close to the back of the head instead of close to the eyesocket. This is so the eye bone that controls the pupil can rotate the pupil and still keep it from clipping outside the head mesh. This worked great for a while. However, since the pivot is not at the "would be eyeball" center, a damped track gave inaccurate results when used to look at stuff (video 1, pupils do not follow look at bone properly). To remedy this, I made 2 new bones, eyeOffset_l and eyeOffset_r. These would be placed at the "would be eyeball" true centers (for x and z) and have the damped track applied to them to face whatever object in the world. The old pupil bones would now instead copy the rotation angles of these offset bones. In short, this changed the points to calculate from for the Damped Tracks. Worked well (video 2, notice how the pupils follow the look at bone better).

One other problem was that since the rotations for the eye bones were constrained and each had a damped track, there were a few situations where the up and down angles of both pupils were not the same. This gave her a lazy eye. Big no no. So I simply made one of the pupil bones copy the up down angle of the other pupil bone. Did not matter which I picked.

>>30752

For body? I use the same 2 images I posted: >>30084

2/22/18: Finished the collage so I can get back on track with this project. I UV-unwrapped her hair today in preparation of texturing it. I know exactly how I want to paint it now. I wish I had the following workflow with the old hair mesh because the old one had bad UV density: UV-unwrapping should not be about producing even UV density on all faces. It should produce UV densities proportional to the importance and necessity of detail for each island.

1.) Mark seams in a way that it divides the important faces and the unimportant faces. Shinobu's hair will have nice faint hair stroke shades on the surface of her hair (important) while the bottom faces of her hair will hardly be seen and consist of almost solid colors (unimportant). A fast way to select current islands outside of the UV editor is to simply hover over your 3D mesh faces and press "L". This automagically fills your selection like paint bucket tool constrained by your seams (image 1: I selected all bottom faces to test my islands).

2.) UV unwrap it with the necessary options. For me I checked unwrap with subdivision modifier for more accurate 2D UV meshes (image 2)

3.) Segregate the unimportant and important islands and combine similar mirrored islands if possible. Bottom unimportant portions of her hair will have symmetrical colors on either side so no point in giving both unique UV space. I just moved them on top of each other, scaled, and rotated to align them together. If there were minor differences, I ignored them and fit their median average (image 3)

4.) Once you got it segregated, scale the important islands a little bit bigger and start putting it together.Follow up and scale down the unimportant islands to fit them back in.

Final result is in the 5th image. The left side shows a simple UV-unwrap. Right side is after taking the above approach. Easily helped me achieve 2x texel real estate with the same texture (which is 1024x1024.

One caveat to this method is that it has overlapping UVs. This breaks baking AO or normals or vertex specific data that requires unique UV space for each face. My 3d anime model is not going to need any of those which is why I am prepared to accept that. However, if in the future I want to have some way to paint her skin or get her wet dynamically on unique parts of her hair, I may want to create a separate UV map which does a simple unoptimized UV-unwrap. Lastly, marking seams should also take into account how you are going to paint it. You don't want to make islands in parts of your model that require 1 contiguous UV space because it might produce detail artifacts as they suddenly cut island to island.

2/23/18: Started to paint her hair. I'm not an artist nor have I ever drawn anime on paper, but I do know my way very well with photoshop and have a good hunch of what makes a good anime style. Shinobu has been drawn in various art styles many which can have craploads of shades of her hair color and really show off artistic merit. However I've noticed that the complexity of such drawings is proportional to how many strands of hairs the artist plays with. In the tv anime series, her hair is simplified a fair bit with giant clusters of her hair being drawn throughout. As a result it does not have more than a couple shades of color with little detail. My mesh really only has like 20 strands of hairs so I wanted to keep it on the low number of shade counts as well but also put in some detail.

So for the first pass I gave her a basic shading near the edges of her hair strands. Just to separate and highlight different strands of hairs. Low frequency detail.

Then I gave volume to her hair with shadow details in the second pass. I made little "fangs" groove in and out of her first shade pass so the hair looks hairier. Medium to high frequency detail.

Then I added some gradients on the flat parts of her long hair strands and a nice white circular light rim to make her hair shinier. I think gradients are powerful to giving meshes volume. I've noticed that 3D anime models make use of gradients heavily and a common trend that I have seen is making the hair strands close to the face look transparent by adding a pinkish glow. It looks pretty good so far.

2/24/18: Finished her hair. Or at least I feel satisfied with how it turned out. First image is old hair. Second image is new hair.

I made use of photoshop's masking to work faster and quickly edit parts of her head. I used the refine edge to create more artsy curves for her head shine (images 3 and 4).

I'm also toying with a squished sphere to permanently fix her eyeball rotations. The rotations are fine but they are not uniform which is still a big problem. This method looks promising but seems like it can be a bitch to get it working because after poking around forums and youtube videos, this method was broken. Pretty sure I can still get it working though.

2/25/18: Fucking finally fixed the eyeballs. Was annoying because the solution was to snake through Blender's limitations. The method was shown above where the eyeball texture will rotate around a flattened sphere to accomodate the non spherical eyeball shape (because Uguu Effect). The rotating eye bone "eyeball_l/r" has a parent bone named "eyeballScale_l/r" which is in charge of positioning and scaling the sphere of the eyeball. It is scaled smaller on some dimensions to make the rotating oval shaped eyeball. The hard part is rigging it properly because by introducing scaling, Blender derps out when using a Damped Track or Inverse Kinematics (to make the eyeball point towards some target bone) in such nested bone structures. Oddly enough those modifiers would ignore the scaling and make the eye pop out entirely (image 1). However, rotating the eyeball bone in place worked just fine and did not pop out and properly constrained itself within the oval shaped sphere. So the problem was the modifiers themselves. The solution was to make another bone that was not nested in the eyeScale and simply was in charge of pointing towards the target look at bone. Then, I used a Copy Rotation on the real eyeball bone to copy that dummy bone's angles. That worked fine (video 1). From there I just added a Limit Rotation and everything went smooth as butter. Method is compatible with game engines as well since the flattened sphere is just a scale deformation. I also added a pupil shrink to give more life to her surprised expression. (video 2).

2/28/18: Back to making animations to complete assets for her logic graph. I finished body_headpat_happy_ask_for_more which will be used when she is enjoying your headpat and suddenly you stop.

Also fixed and edited her mesh since I noticed that some vertices not visible in her front and side silhouettes were not round. This caused a sort of gaunt dimple ridden look on her hips. I wanted to keep her skinny look but also highlight her womanly girly thighs and hips. The videos may look like I just made her thicc but I actually kept her silhouette intact meaning I only rounded out some vertices [had to turn off hair subdivision for recording performance]. She does not actually look as thicc in any other view. These edits merely helped her model look more uniform and round.

2/28/18: Meant 2/27/28 yesterday.

Only finished one animation today. body_stand_headpat_happy_receive_more which will be used if the player headpats her after she asks for more. A follow up to yesterday's animation. It is very similar to: >>30731 happy_start but it's a lot softer and smoother because she is slowly recovering from the brief sadness.

>>30095

>tfw you will never skin your waifu alive

>>30443

>tfw you will never deep throat her skinless body

>>30803

Good

3/1/18: Sold my soul to Tewi since it's a new month and finished a new animation: body_headpat_happy_satisfaction which is an animation asset that will be used when you stop headpatting her and she is satisfied.

Additionally tweaked her dentistry because I realized the inside of her mouth was too small which caused her teeth to not cover enough of the mouth color. This made it look like she had small spaced out dentures. So I scaled up her mouth and teeth while maintaining her lips and shape keys in tact.

>>30803

Yeah I'm not sure that's what that is.

>>30815

Additionally I'd like to say that if you want to be more loyal to the actual official character art, keep the eyes the same but maybe change the outlining of the eyes to a "browner" black (pic related) and maybe change the shape of the eyelash-line a bit

>>30815

>>30816

Hey thanks for the feedback but the official color of her eyes is black according to Watanabe Akio her designer. I've got official posters, dakimakura, figurines, and loads of random images that tell me that black is indeed the de facto color. That said, there is always inconsistency especially in the tv show sometimes going as far as changing her pupil color in some scenes. Which is just the nature of anime. Close up perspective recordings do make her look weird but I'm fairly certain once I slap on a nice toon shader with outlines she will look much more 2D.

I am not trying to match her exact tv anime style anymore as evident by the slightly different shading of her hair (which is nowhere near consistent at all in the tv show). My first Shinobu model from the wedding sim was a lot more conservative and matched her 2D anime style exactly. And I don't think it looks good anymore in comparison. At some point going from 2D to 3D, you are much better off putting in your own slight improvisation. 2D just doesn't work in 3D.

your waifu looks really cute OP

looking forward to seeing your game and cute animations

3/3/18: Got a lot done today. Finished body_stand_headpat_annoyed, body_stand_climax_to_cancel, and fixed a couple mesh problems that were plaguing me for a while.

The first animation will be used to warn you when you headpat her too many times or in a way that is very annoying (shaking or swaying harshly). Second animation is when she is fed up with you and brushes away your arm. Similar to the brush away animation but this is used to turn her angry. I'm picking up more methods to animate faster. Some of them are subtle but work well. One new one is when tweaking an animation in graph editor. I've found that it is faster and better to exaggerate your changes by a little bit (like 15% more) and deleting curve vertices that would make a subtle smooth steps. This way I've found myself less prone to needing to go back and make certain tweaks.

Then I fixed my shoulder deformation since it had a bump that looked like her pectoralis was popping out. It was mostly a weight painting issue. Video related.

I spent about 3 hours today fixing her butt including her anus lol. The topology for her butt crack formed an ugly peak from the glute deformations which looked awful in spread eagle pose. The problem was that there was not enough separation between both butt cheeks. Subdivision was affecting both cheeks from the same middle vertex and with the armature deformations it got worse. I added one more row of vertices going up her butt crack to address this problem. I also repainted certain parts of her glute bones to achieve a rounder look for her booty when she bends over. Video shows how square it was before. It's a subtle fix but combined with the improved buttcrack topology, you can now see a smooth straight line going towards her spine. Image shows cross section of butt with the new line of vertices along her butt crack (old left, new right). Lastly I moved her anus because I realized it was too far away from her vagina which made it look weird. You can see how I moved it down in the image as well. So now she looks a lot more delicious in lewd poses. Rounder booty deformations and better genital placement.

3/4/18:

All animations are ready for implementation into Unity but I probably won't be doing that for another 2 weeks because reasons. So I decided to start working on her new body texture and some logic. Since I added new hands, new feet, and a bagina and angus I need to unwrap the new whole body mesh again (head is separated) and repaint it. The seam placement is not complete yet as I need to figure out the optimal marked seam setup for my painting. I'm simply trying to mark edges where I don't need a continuous island. I find separating certain body parts easier to unwrap like the hands and genitals.

The next behaviour module for her logic will be interacting with her when you get your face close to hers. So things like kissing or teasing. Trying to make it as simple as possible to lower animation count. Pic related. Modules inside green boxes are ready for implementation.

>>30844

>there probably is some crazy geometry stuff you could do

Rendering in orthographic for just her model and then rendering the rest in normal perspective indeed sounds like an ideal solution to make her look more 2D. However that is a super silly idea. The problem is that rendering with different perspectives in a single pass fucks up your sense of depth and perspective. It would also not make any visual sense. She would be a flat plane without any way to reach out towards me in 3D. Let alone use this for VR.

>Have you considered using some esoteric camera setup and scanning the models/figurines you have youself?

I've used photogrammetry at work before and using it to make rigged game models would be pants on head retarded. The biggest offending reason is that the scanned output produces a triangle salad with zero topology. Far from ideal for rigging and UV-unwrapping. And the workflow would not make sense. How the hell would I "unpose" the figurine's pose to a T-pose? The second offending reason is that photogrammetry spits out only what is visible by the camera. Meaning you would not be able to scan and extract just the body of the figurine if it has clothes or objects blocking the body. So that's why it's a good thing that I'm learning to make my own models the way they are meant to be made for games.

>maybe you could even record animations

This was something I did think about a few months ago and a good thing that you brought it up. I was thinking about making my own Kinect to Blender mocap studio to save time with the animations. However, I realized that it would not work best because the types of animations that I need are very specific for her logic that would not look good with super realistic human recorded motion. Also I didn't want to record myself pretending to be fucked on the floor.And then fuck myself in VR

>have you heard of the Leap Motion?

Yes I have! And I would love to build for something like that, but I want to make something that is way more accessible for everyone. VR on 8chan or even the internet is pretty goddam niche already and adding a Leap Motion entry hurdle would make me the only person capable of appropriately running this VR sim. So I'm just going to target the HTC Vive controllers and definitely upgrade once the Vive Knuckles controllers come out.

3/7/18: Did a couple more animations for the face proximity behavior module. Also started to brainstorm ways to get a good looking shader for her.

body_face_prox_angry_surprise will be used when you suddenly approach her really fast. This animation will then transition to the next animation body_face_prox_angry_loop which is a long looping animation that just shows Shinobu being very weary of you. It's kind of hard to see her angry eyebrows but she is pouting in this animation.

The anime shader will probably be something similar to the one I made in UE4 but for Unity. UE4 has dogshit awful shader documentation and you pretty much have to use their node system. Which is great for making some deferred render shaders but it can be an enormous pain in the ass to make a node for every single calculation. Unity has something similar but a lot more friendlier support for writing shaders in a text editor. The shader will use a matcap texture with lots of clamped color ranges and will have the sample coord shifted by the shadow sample. That way the shadow should affect the final matcap lookup calculation and thereby making the shader support shadows properly with an anime matcap. UE4 shader didn't do this. And then I'll throw in a nice vertex extrusion for the outline.

3/8/18: Finished another animation bod_face_prox_kissed_to_angry for when you kiss her while in angry mood. The next animation will split off either into the _to_happy or _back_to_angry. So kissing has a chance to change her mood back to happy. Also this is only for the right cheek. I can very easily mirror this animation and have one for the left cheek.

Something that I've noticed that is annoying is Blender's lack of having some kind of additive animation for the graph editor (or maybe I just don't know how to). As in, sometimes after finishing an animation I want to go back and add a breathing animation on top of the movements. So I usually go into the x quaternion for all the spine bones and make an unsynchronized wave. However if the x quaternion graph part is occupied and full of specifically placed points, I can't just make the wave breathing pattern. So I've found that the easiest way to go around this is to first animate all the simple would-be additive animations first, and then make your actual animation afterwards. And to save time, I've made a temporary helper animation that has my breathing animation. Now all I have to do is clone this animation to make a new one and layer on top new movements. Bam. 10 minutes saved.

Also currently looking at fixing the wrist deformation.

8/9/18: Fucking bit the bullet and rolled back to Blender v 2.77 from 2.79 because a certain feature is broken. Oh well. Seemed like the file versioning was compatible and everything else works. I may need to switch versions now for very specific things. Get your shit together Blender.

>>30867

What? That's just in blender viewport. In game won't look anything like that.

Holy shit I fucking got it. This is how to apply all modifiers and maintain shape keys and without addons (video 1). I Googled for hours trying out several addons but none worked for some reason. They either transferred some shape keys but left out others. This method works with ALL and I found out why it wasn't working sometimes. The problem is that the mirror sometimes merges vertices thus changing vertex count and derping blender when joining shapes (video 2). So you must make sure that each shape key does not destroy or create any vertices! This means that it must not touch the middle of the mirror middle when applied but it can go over it to the other side. As long as it maintains the vertex count. My test breast shape key transfer was not working and it was because one of the middle chest vertices was disconnecting itself from the middle (video 3), thus creating a new vertex and fucking everything up. To fix this I simply merged it back and the shape join worked wonderfully. It can be tricky to tell where a shape key is screwing with the mirror modifier but by ticking on and off the "Merge" option in mirror, you can visualize where it is creating or destroying vertices. Additionally when you convert it to mesh, you can check how many vertices it has compared to the base model. The breast shape key had 4 more vertices than the basis mesh. That means that it was creating a net total of 1 vertices.

Now I have a great workflow for exporting my Shinobu model into Unity all the while being able to work on my mesh with all the modifiers that I want. I tested it with my current model and it worked fantastically. Hail hydra.

3/14/18: In process of moving to new apartment so very busy this week. Finished body_face_prox_kissed_angry_to_happy for after the previous animation branches off to a successful happy action. The goddam sigh took me 3 hours because I was being stupid with the approach. I didn't know what kind of action I wanted her to perform and I was kind of just messing around until it looked good. The sigh was also a little hard because there is lots of gravity and timing acting on her spine and arms. I need to plan out better my animations to save time. Although sometimes it is hard to visualize.

>>30877

>using it for reference

Yeah that's totally doable. Would work fine. I think I used it a while back for understanding her hair.

>Not to start an argument

Arguments are good. Talk me out of something to improve. The whole point of this is that it is in desktop level VR like my wedding. Google cardboard is just shitty mobile VR with too many hardware limitations. I wouldn't be able to make it look good. Phone hardware for VR is trash. I write shaders for phones at work.

3/15/18: Doing final touches before finalizing model for Unity. Added 2 more IK controls for her right index and middle finger. And tweaked her shoulder topology. I wanted to see how a different topology would look like for her shoulder deformations. I went from right angle to smooth curve topology and overall I like the change. I saw an improvement in less need for weight painting penetration which made her shoulders have less pinching. I also saw an improvement in her armpit area. The sides of the breast now neatly connect to the underside of her armpit which looks much better in action. I looked at lots of armpit bone placement for reference and saw that the shoulder bones should be at straight angles in A pose. So I went in and fixed the shoulder bones placement. I noticed that the shoulders now move less outward and more realistically.

I moved the breasts up a bit as they were STILL a little bit low. Lastly, I fixed the collarbones by giving it a rounder shape. Worked well.

Holy shit raid bump.

3/20/18: Did a few things here and there. Fixed the topology of her soles and started doing shader work in Unity.

Feet topology is hard. Sexy feet topology is impossible. I spent a good 4 hours on the feet trying out various paths to give them a more natural sexier feet shape. The problem is that feet have so many curves and shapes that it is difficult to plan out where to start the topology. I finally hit something decent by first starting out with the big topological areas. The ball off the bottom of the heel is round and so I made that the starting point of my new topology. From there I moved outwards towards to toes while maintaining that footprint curve. Then I smoothed out some stuff.

Shaders are fun. I write shaders at work all the time and thus I am very comfortable writing optimized code for certain platforms. VR is needy on the fragment shader so I had to design it in a way that is fast but also looks good. My first attempt was with a matcap but I realized that Shinobu's skin only has 3 colors so it would have been overkill to use this method. It also required a nasty amount of normalized interpolated vectors to the frag. I realized that a nice bright directional rim would give her the nice white skin highlight, and is cheap. Shadows occlude this rim. The outline varies by distance to the camera and the color depends on the color from where it is being extruded out of.My last concern is that anime faces themselves tend to ignore the lighting around them. So when ported to 3D, you see too much lighting going on the face. In the video you can see her right side of the face being completely lit up. If this was to be more anime ish, only a small portion of that would be highlighted. I will work a solution using the alpha channel of her body texture.

I will be going on a hiatus for maybe a month or 2 as I have finally received music for my other 2D platformer game. See you later

>>30777

hey shinobro do you mind if i use your hair texture as base/reference to make the hair of my Sasha?

>>31194

>I will be going on a hiatus for maybe a month or 2 as I have finally received music for my other 2D platformer game. See you later

Good luck, have fun, and come back to us. Don't leave me hanging, Shinobro.

>>31234

It sucks I know but it's my college project that I've been working on for a long time. It's practically complete just need to add music and finish boss fight. That said there is no reason for me to never come back to this project. I'm at a very stable point in my life. I like this project. I WANT to work on this project more than my college project but a husbando has his priorities. I will come back full force.

4/22/18 I've returned. Although music is still coming in for my other project. Worked on preparing assets for Unity and finished her shader.

I spent the day unwrapping and splitting the mesh as follows: head, torso, hands, legs, and feet (head texture image 1). Also completely retextured these parts to accommodate new UV maps. I added better detail this time around including some nice ribs on the side of her chest. One thing I did to improve the UV unwraps was create a new shape key called UV_REST which is used exclusively for unwrapping. This shape key is a rest pose for the mesh itself which will allow it to have better UV density (image 2). For example, it contains the vagina shape key at 0.5 as I did not want to unwrap the model with the labia closed because it would cause stretching in the final texture. Same for other similar body parts.

The shader was reworked as it looked off and gave no indication of light direction. I also fixed the face receiving too many effects from the shader (video 1). One problem I've noticed with toon shaders in general is that the bad ones do not properly give perspective or volume to the model. Even if an anime character has flat shading in general, you lose a ton of visual information by simply slapping a shader that does just that. 2D again does not work in 3D. So in order to alleviate this I added a rim that darkens her skin as it wraps around her body. A neat trick I've found out is that using a lerp from this dark rim color to an oversaturated fixed3 creates a pretty inbetween color. This is similar to how subsurface scattering works as it appears as if at the right camera angle under light, the light bleeds into the skin momentarily. Of course I did not want to make her shader look too realistic but just a little bit worked wonders and maintains a cartoony look. For performance I tried to reduce my lerps to only 2. I'm going to experiment bringing stuff to the vertex shader instead of interpolating some stuff in the frag shader.

I've noticed that many AAA Japanese developers also make use of effects that give their anime models volume. Gradients come to mind. Never flat shading. Even the beautiful Guilty Gear/DragonBall Fighter Z shaders use normal maps to achieve realtime pixel-art lighting with several shades of color.

>>31397

Video only flashed last frame saying "Result*Alpha". It's the last step in the shader to prevent the face from being lit by all effects besides the shadow (image 1 is wrong. Image 2 is fixed).

4/23/18 Did model export cleanup and made the first cloth pieces.

One problem with dividing mesh pieces is that you also destroy the vertex normal data on those points of division. meaning you see clear cuts of different normals in game along where you divided your meshes. To fix this one needs to use Blender's Data Transfer tool which is a very easy way to copy the master non-divided complete mesh's normals to the divided mesh pieces. Thereby maintaining vertex normals even after being divided into pieces (video 1)

The new dressy shirt top is not textured yet but I already have the texture ready for it. It was built using the same topology-reusing trick which simply copies the topology it rests on and then solidifies outward (video 2). This prevents deformations causing clipping with the skin mesh it goes on top of. This works because it reuses the exact same deformation weights and topology. That said, this torso cloth piece deletes skin vertices that are not visible (image 3). This helps in reducing overdraw and clipping. All I need to worry about is selecting which vertices to delete. Keeping subdivision this entire time makes it MILES easier. However because it uses subdivision, I have to delete 1 farther away than the visible vertices because subdivision affects vertices within a radius of 2 from 1. The cleanup was very simple too. After I've deleted the non-visible vertices, I applied all modifiers and used Data Transfer to copy the UVs of the previously unwrapped nude models. Came out well (images 4 and 5). The skirt will not delete vertices underneath because it will be a physics cloth simulation. Tomorrow hopefully I get to getting the dam thing animating.

4/25/18 Worked a bit more on understanding export process and got my mesh combiner script working.

Worst part about using a new engine is when you are starting to learn it. I was drowning in shitty documentation about how the engine worked. I refused to watch 30 minute super nooby tutorials to explain basic things. It really is true that Unity attracts nothing but the most braindead amateur developers. So much handholding to the point where you can just build a game with premade scripts and assets with hardly any effort. I hate using that sort of stuff. I like to know internally how stuff works. Too much handholding and you end up with a mess of bloated unoptimized crap.

My mesh combiner was built after reading and looking at another mesh combiner script for reference. It is used to combine skinned mesh renderers with different materials to reduce the draw calls. When I was using Unreal, all I used was a blueprint node that did this for me. But that blueprint increased the draw calls because it kept each mesh separate and simply threw them together in series when rendering. This one combines the triangle indices, uvs, bone weights, and vertices into 1 model as if it was imported on its own. The difference is that it is done at runtime with whatever combination of clothe pieces I throw at it (video 1, changing torso with nude torso).

Unity documentation is much better than Unreal overall so far and it does feel like it has an easier learning curve. C# is okay.

I've got down the export process for when I need to import just a body part mesh. In Blender, I select the rig it's on, the mesh itself, and made a custom preset for my .fbx export options. I basically only export MESH and ARMATURE. Animations are exported by just highlighting the rig itself and baking the timeline animation. That way I can export each individual animation and import to Unity as an asset. Workflow works with blend shapes and maintaining subdivision until the last step.

>>31402

Thanks man It was really bothering me not working on this.

4/27/18 Did more documentation research and started implementing some logic.

I made a script for basic debug fly controls and organized my logic so I can start implementing her animation states. Partial classes are super helpful.

I've noticed that Unity really REALLY tries to hold your hand for freaking every single mathematic computation. It is a grueling process trying to do any sort of calculations with Vector3 or Vector2. However I also found that it comes with very powerful functions that can in combination do everything you ever need to do. Learning about this gives me flashbacks when I was using Unreal. Except this is better documentation.

One thing that is super important in animations is head movement. The subtle ways you move a head can very easily spell the line between real and fake looking. As I was starting to work on the look at logic, I had to come up with a formula for smoothly interpolating between 2 quaternions for her head. Unity comes with a Quaternion.Slerp which is sort of a sin ease-in-out (video 1). It looks bad on her head because the function itself is too smooth which leaves no smooth endpoints and gives her a very robotic feel. So instead I picked out something a lot more realistic, ease in out cubic (video 2). The changes are subtle and it does not require too much autism to tell them apart. But it looks much better on her head movements. So instead I fed my eased parameter value into Quaternion.UnclampedLerp. Remember, the devil is in the details.

4/28/18 Got a lot of work done with the first version of her look at logic.

Again I spent a lot of time making sure her head and eye movements felt natural. The current logic is the result of fiddling with nice ease functions and adding appropriate angular clamps. There are 4 bones being affected by her lookAt logic, spine2, head, and both eyes. There are still some issues with her eyes. Namely the texture is flipped upside down because of how Quaternions are calculated internally (image 2). The challenge is fixing this roll angle on the eye bone which is nested on another bone that is scaled. My eyeballs are not spherical (image 3). This introduces and breaks certain Quaternion functions in Unity because of scaled transformations (e.g. Quaternion.RotateTowards). It's the same reason why Inverse Kinematics didn't work in Blender with these same eyeball bones. For the eye clamping I just manually clamped each euler angle relative to the head euler angles. This clamping method has a square range instead of a circular range which limit's her realistic eyeball rotations a little. しょうがない. I think I'm just going to instead flip the UVs vertically in the eye pupil shader.

4/30/18 Finished tweaking her look at logic and fixed the eyeballs. Also finished the first pass of adding physics hair strands.

Clamping the eyeballs was an ugly task because of the non spherical eyeball shapes. It turns out that LookAt does work with them I just didn't know you could specify an up axis. That fixed getting the right look at quaternion. The next hard part was how to clamp it within an eye socket's field of view. The problem is that because the eyeball is stretched, using a simple max angle constrain creates an oval shaped constrain (because the eyeball is, again, stretched), instead of a normal circular shape. The fix was very tricky but it involved reading the distance between a dummy bone and the center of the eyeball: since the eyeball was stretched, as it rotated, the radius changes. This allowed me to know when the radius should become shorter. Then creating a small function that approximates the distance change to the radius change. This fixed and "unstretched" the oval shaped max angle.

Adding physics to the hair strands was a lot easier than I thought. The tricky part about this is that EVERYTHING I do to the Shinobu model must be done at runtime because the customizable combined skinned mesh and rig do not exist until I build it in run time. This is not as bad as it sounds. I can always test stuff first by adding components to her during runtime. Another tricky part was understanding the physics values of some of the variables in Configurable Joints. Physics is a cruel mistress but Unity has been very tame so far. I wanted to make her hair poofy and soft looking so I raised the springiness up and lowered the dampness. However, I realized that some hair strands would look better if they had different springiness. So I built the functions in a way that allows me to easily customize each hair strand. Then I added really simple spherical colliders to the ends of the bone strands as those are the points that would interact the most with the world. Too many colliders and I fear for VR it would be bad. Stress testing later.

>>31432

That's not a bad idea. I'll keep that in mind when I start playing with blend shapes.

5/2/18: Finished implementing cloth physics to her combine mesh functions and started working on blend shapes.

It is now very easy to attach cloth sim meshes to whatever combined mesh outfit she wears. Will make it easy down the line to create and add new outfits to the game.

Blendshapes is going to be tough because of the combined mesh system. The easy part was just exporting the stuff from Blender: breaking down the modifiers and Joining as Shapes. I've got a test animation working that animates her skeleton and her face's blendshapes on a separate mesh. However this animation does not work on the combined body mesh and skeleton because the combined mesh does not carry over blend shapes. So maybe this breaks the binding like if it was a different avatar. I'm gonna have to implement blend shape combining myself during the combination process.

>>31446

I've found mouth to be more expressive than eyes. People look at the eyes far more than they look at the mouth.

5/5/18 Finished implementing combining blend shapes, finalized animation export workflow, and started on pass 2 of her eyes.

The blend shapes work wonderfully. Video 1 shows me testing 2 layers of animation: the body and the face animations on the same rig. Both random. One annoying thing is that apparently Unity clamps blend shape values from 0~100. This is counter intuitive coming from Blender because I have some blend shapes that can go from -1~1. After some research it appears that Unity is going to roll out an update that will allow negative values in the future. The work around would be to split the blendshapes into 2 (ugly).

The animation export workflow took some trial and error to get right with my mesh combiner. But for my purposes it works like so:

>select rig and head mesh

>set settings from image 2

>import and use on my in game rig

One problem that I noticed is that when exporting an animation from Blender, the bone hierarchy that must match the target rig in Unity is parented by the actual Blender rig object name. So my Unity game rig must include the Blender named "ShinobuArmature" as the parent for the rig like in Blender. It can't just export the root/ bone. It exports ShinobuArmature/root/. The kicker is that Blender animated blendshapes are also encapsulated under the name of the actual mesh object. So my Unity SkinnedMeshRenderer must have the Blender named parent called "headMesh" or else my blendshapes won't be animated. This is not usually a problem but because I am using combined meshes, if I ever run into an Blender animation that has 2 mesh objects that have shape keys animated, I won't be able to animate both on the 1 combined mesh object because of the mentioned encapsulation. It would be looking for the blendshapes in 2 different objects as opposed to 1. Haven't worked out a fix for this but I'm sure there are workarounds.

I thought of a way to improve and simplify the logic for her eyes. Instead of messing with non spherical eye radii and whatnot, I can constrain the actual look at position within a cone in front of the head. This would make it very easy to add dynamic and better looking eyesocket rotation clamps. Video 2 shows me playing around with this method and also attempting to constrain the pupils below the upper eyelid which may be affected by whatever random animation is playing.

5/8/18 Finished pass 2 of her eyes. Huge improvement.

I needed to rewrite this because my old way of simply constraining the eyeball quaternion did not scale well at all for other logic that needed to be implemented down the line. It was also very inaccurate. This new method instead lets the eyeball quaternion be free and then restricts the actual target look at position. In this case the shape that the look at position is restricted to is a cone that expands outwards. Video 1 shows this. However, it was not just that easy. The problem where her eyeball rolled back upwards when looking up persisted because of non spherical eyeballs. To fix this I changed the cone shape to an oval shape that flattened as the look at position went higher. The restriction was done with simple 2d math with the intersection of a changing oval and line.

Additional logic after this rework was a breeze. Her pupils are now restricted to the visible white sclera only. This is good for preventing her pupils to not be visible when she squints and looks up. Also allows for far more realistic tracking of objects when animating her eyelids. Video 2 shows the new eyelid clamps.

The next addition was this >>31432 .It was simply logic on top of the previous logic. However, despite it working properly, individual look down eyelid logic made her look confused (video 3 shows this). So to fix this I averaged the 2 look down eyelids and she looks fine now when looking down (video 4).

Lastly, I am starting to work on the random eye movements and blinking. The blinking was interesting because it needed to be compatible with the currently playing animation because I want to be able to add random blinks to any currently playing face animation. This meant that it has to disable pupil clamping from before and smoothly transition between the current animation's current eyelids. I think it came out well. Video 5 shows this.

5/10/18 Import issues, polishing model look, and began free-look logic.

I had to mess with Blender export settings to make sure that I was modeling with the appropriate units. Shinobu is going to be 4"6" or 1.4m. I was also looking at her model because the 3D was making her loose her anime esthetic. The camera FOV combined was starting to make her look more like a dopey 3D doll than an anime girl. Focal distance on lenses is very important like in photography and can make people look different (and ugly). Image 1 shows the distortion effects. Fairly certain this will be fixed later once the user uses a VR headset. I am still tossing the idea of disabling dynamic shadows for her look. I may have to do more shader work later on.

The look at logic comes from again, the important of eyes and head movements on a character. One thing I hate about game is that many of the characters are ignorant of the surroundings when they walk around and typically only face one direction when walking. I'd like to make Shinobu curious so today I was implementing ways to teach her to look around as she moves to places. In conjunction with the look at logic it was very easy to implement. Since Unity does not provide colliders for cones, I had to approximate it using 3 boxes (image 2). From there just pick out an object and enable the look at logic. Eventually this might trigger some "ooh" logic and interrupt her tasks. The walking animations is very stiff because there is only 1 animation being used for the blend tree. Next step is to sort the objects in terms of performance and to start animating for movement cycles.

Also I found that turning down the interations for the skirt fixed a lot of the erratic movement. However my hair sphere colliders all of a sudden started to freak out once I added the test blue sphere colliders. Will look into it next.

>>31489

Thanks man I'm shooting for 8/8/18 demo day.

>>31492

Good question. Despite the project going to be released for free, I am protective of the source code. That said I don't mind showing how I did certain things (that's the whole purpose of this thread anyways).

>>31493

>sort the objects in terms of performance

<sort the objects in terms of importance

>start animating for movement cycles

<start animating more movement cycles

>interations

<iterations

Shit I should have proof-read my post. Was tired.

5/14/18 Been busy working on the house. Halfway done.

Was looking at lots of reference images to make my sort of dream ranch home. I didn't want to make it too big because then it would become a daunting task to furnish with more models but it's big enough for everything I'll ever want to do. I was fortunate enough to be raised in a ranch in Mexico when I was young and I remember a lot of things about the family ranch that made the architecture different compared to standard western ranches. Doors were thinner, ceilings would be much taller, squares everywhere in terms of design, cozy rooms.

I was also figuring out a good workflow for making this house. I first built it with blocks without any regard to seams. Just throw all the blocks intersecting with one another. After I finished the base mesh I went back and retopod it to have optimal triangle space. Still have plenty of detail to make especially on the roof and interior. Will hopefully finish next blog entry.

5/17/18 Finalizing house mesh and figuring out the workflow for texturing the house. Have a looong way to finish the texturing of the house.

I've decided that I will be disabling dynamic shadows and lighting. I will be baking out 2048x2048 renders to slap onto the environment.

Pros

<Allows for the best performance shaders for VR (can still have reflections with a combination of cubemaps and specularity map)

<Stupid-good realistic lighting and ambient occlusion

<Shinobu will look more anime-esque because no more dynamic shadows

<Model uv-unwrapping is easy and can be done quick and dirty because the bake will use a separate second UV map

Cons

<No to limited dynamic lighting (cheap tricks can still be achieved)

<No dynamic shadows

Blender's cycles is really easy so far to setup. The workflow however for testing and tweaking was annoying to get right at first but I think I almost got it down. The process for baking textures goes as follows: Finish the entire house mesh (almost done), segregate into equal surface area pieces (Blender has the 3D Print Tools addon for this)[100m²/2048² texels], combine each finished bake group into one object, create a 2nd UV map for that mesh, unwrap that entire bake group equally, create 1 blank 2048x2048 texture for each object, setup materials in node editor for each material, select the 2nd uv map, select the texture node, tweak the crap out of cycles to find the perfect trade of for quality over render time (mine is about 5 minute render times per room).

I will still have dynamic moving physics objects that won't need to use the scene bake lighting. I have a few ideas on how to fake dynamic sun light on static objects. Similar to Source engine, models will sample the nearest texels and average them out. This can then be used to colorize the prop. So when it's under a bright texture it will light up (like under the sun), and darken when in a shadowy part of a texture. In combination with point lights and custom glossy shaders, you can achieve great looking dynamic-static lighting. I work on a game at work that uses similar methods. Working with professional render artists teaches you a lot.

5/20/18 Finally started getting in assets from the bakes into Unity. Also did more props for the bedroom.

The process was a lot more involved than I thought. I barely dipped my toe into the world of real time ray tracing renders and learned a shit ton about rendering errors; fireflies, noise, performance settings, etc. I've managed to almost get the right settings for my bakes. Problem is that for the really big textures such as the bedroom (2048x2048), it takes roughly 20 minutes to render out with still some noise leftover. Small static props are given either 512x512 or 1024x1024. Never lower.

I'm going to continue working on her logic so she feels more natural. I'll work on the livingroom later. I'd really like to start the first pass on some more look at logic. Namely logic to smoothly transfer look at targets from one to another. I also fixed some physics bugs with her hair. Something else I'd like to work on is her movement with the nav system. Unity's standard Nav Agent movement sucks donkey balls. So I might just implement my own basic functions for moving towards a waypoint.

>>30078

Any chance that we can see her dressed as pic related?

5/21/18 Did some more work on switching between look at targets.

My switching is now done smoothly with a variable that can have a value between 0 and 1. It simply calculates the position of the lookAtTargetPos Vector3 that is between 2 target lookAt objects. The way it translates between both is not linear because that would cause snapping during a transition. Reason being is that linear interpolation creates angles that are not equal as an object travels in between (image 1). This would look like snapping because the bigger angles would make it look like the in between object is moving faster in the middle. So instead the interpolation is between 2 spheres (image 2). This worked well as shown in video 1. The current logic of her target switching is video 2 which shows the target going from me to null to painting. One thing I now have to work on is a way to switch targets during a transition. Yet to figure it out. For now she can only change targets after finishing a transition. I also may tweak her head speed variables to accommodate this new logic piece. Also going to add some blinking whenever she changes look at targets.

>>31533

All memes and outfits are going to be put on hold for later. At some point I'm going to just be modeling outfits.

5/23/18 Working on the headpat logic so I can start and finish the headpat module.

it's great already having all the animations done. It's just a matter of figuring out the logic. For now I implemented 2D to 3D pull logic but eventually I will substitute it with VR hand controls like the original. Animations make her look very cute.

>>31199

>to avoid getting a Jimmy Neutron hairdo.

>implying that's a bad thing

plebeian, pls

>>31535

>All memes and outfits are going to be put on hold for later. At some point I'm going to just be modeling outfits.

Oki doki.

I am a bit new on this board and I need to say that I love the work that you are doing. But why you are doing all this? all the stuff that I am looking in this thread it looks like that kind of stuff that video games companies do for a economic profit.

I mean, I can undestand your love for this satanic vampire loli, but c'mon, this is a lot work for that.

5/26/18 Worked on more headpat logic.

As I showed in the logic graph before, her headpat logic has happy and angry mood branches. This is so she can have happy/angry moods to make her more dynamic. I'd love to add more moods but it is an insane amount of work to add just 1 mood because it would add another row of animations on the matrix of animations that I need to make. That said, Unity's animation graph editor is trash. The nodes and transition system that it has is worse than Unreal's animation graph. Both suffer from the problem that it is easy to quickly make a spaghetti mess of states nad transitions. This is something I want to avoid because Shinobu's logic requires dynamic animation branching with many conditions. So what I did was make my own Animation system that handles transitions entirely in code. All I had to do was keep track of the states in the Animator and do the cross fading myself. It was a lot more work than I thought because of how Unity handles transitions with normalized animation times. But it worked very well and is very easy to add new state animations (image 1)

The headpat logic now has almost the angry branch implemented. Also needs some polishing. You can now bully her or treat her well. If you make her angry it will switch her mood and change all of her future animations.

>>31566

>But why are you doing all this?

Because it's fun. No other reason needed. I intend to release this for free later. But I do work as Senior Technical Artist for a big company IRL.

Yeah this is a nice project. Godspeed Shinbro

I appreciate everyone's support.

5/28/18: Bugfixing, finishing headpat logic, began body states, and began IK module.

I spent a couple hours refactoring some code now that I have a good sense of the type of code management and error catching my Animation system needs. The important part was accepting and requesting events to and from my animation system. This is crucial for reducing errors because I don't want her logic to freeze if I were to spam HEADPAT_START or similar events. She now handles requests properly with minimal condition checks.

The headpat module is done for now and I think it came out very cute. You can tease her or make her happy which will switch her between her happy and angry moods. Video 1 shows most of it (Forgot to record >>30727 angry interrupt). This behavior has a total of 11 separate animations. When I move forward with body states like sitting on floor, chair, etc., this behavior will require me to make specific animations for those body states so you can headpat her in any pose she is in (Meaning it's a 11x multiplier for amount of animations but thankfully most can be copy pasted). Body states shown in video 2. Playing games with her on the floor is next on the list.

For when I play games with her, her hands are going to need real time inverse kinematics. Unfortunately Unity only provides IK logic for Mecanim rigs and my Shinobu model is not Mecanim. So I spent some time today rolling out my own 2 bone IK class (video 3). It has 2 bones and a pole for controlling IK direction. Just like in Blender. Done by satisfying 2 intersecting spheres.

>>31577

Awesome stuff Shinbro!

Tbh I'd consider adding more procedural animation. It's something that's very underutilized and I think even if you put like a dozen or so man-hours into it, you could create something that works in general use and is within the scale of the project. Obviously this would be a hard task, but it doesn't require some advanced artificial intelligence/machine learning setup, you could have it based on a set of simple rules that create emergent behavior.

Also, in long-term, I would implore you to research the idea of emergent systems - the interaction of simple "actors" or rules to create unique scenarios within games and simulations. This is an idea present in almost all games really every game except CYOAs/strict text adventures although usually it is used to a very shallow extent.

I hope this post doesn't sound too naive, these are just some concepts I thought you might find interesting.

5/30/18: Started implementing the "play chopsticks" module.

I finished the IK for now. The easy part was just the basic math for finding points for the 2 bones. The tricky part was lerping between 0 and 1 the bones with respect to proper roll angles. It works well at 0 or full 1 if the pole is not near the bounding sphere of motion for the arm and forearm. There seems to be some subtle interpolation snapping possibly related to how I'm calculating roll angles. Video 1 is fixing quaternion offsets for bones. Video 2 shows lerp tests with the subtle snapping that annoys me. Her torso has debug blocks so it was easier to visualize her current bone orientations.

If you are not familiar with the game Chopsticks, it's a very simple finger game you play with another person. By itself it's kind of boring but I'm thinking of some way to spice it up. Video 3 shows IK tests on Shinobu to see how it's going to work. Next up is making her IK movements more natural which will include moving the shoulder bones up depending on how high her arm raises. Maybe her spine bones as well.

>>31587

Yeah I'm doing IK for more procedural animation. As for emergent systems, that's something for the distant future. I do have lots of plans for her to do stuff by herself when she walks around the house but right now I need to implement 3 modules before I go nuts: headpats, chopsticks, and kisses. Third one I've barely made any animations for. There's a couple on this thread.

>>31588

Why she is so perfect?

6/2/18 Almost done with IK.

IK is great for realtime deformations but one problem is that straight modifications to the bones won't match the deformations of the highly specialized animation rig from Blender. That is unless you re-rig your bones in Unity in C#, which is what I did today. All I did was re-create Blender's bone constraints with some Quaternion logic (image 1). Quaternions can be very tricky and an absolute headache for math. Thankfully Unity provides very powerful Quaternion functions for everything you need to do.

The realtime IK now deforms the shoulders forwards and upwards rotations depending on the bicep bones (video 1). Then the wrists have their roll corrected (video 2). I also fixed the IK lerp snapping mentioned in my previous post so it works wonderfully now. Last on the list is mirroring the logic to the left arm which should be easy since I just have to tweak some variables. Video 3 shows what it is right now.

6/3/18 Finished IK, code overhaul, new technical hurdles, and began chopsticks.

IK is good to go and is bug free and fixes shoulder deformations. Video 1 shows off the IK. It now also has a target hand quaternion so you can specify the hand's orientation.

The underlying class I used for managing logic modules has been rewritten to better accommodate future tasks and actions. Was not too difficult. I also migrated the codebase from GitHub to GitLab.

A new technical problem relates to normals. Unity in it's infinite wisdom decided to duplicate vertices along UV seams which effectively makes a visible normal cut when using RecalculateNormals(). Images 1 and 2 show this with a normal visualizer. This makes her anime skin shader have sharp ugly color transitions on a few parts of her body. Normally you wouldn't have to worry about this because imported (not combined in realtime) models have a more robust angle based normal calculation performed. The workaround will be to average overlapping vertex normals along the seams. However this isn't as easy because this is dealing with many vertices (~35k+) and a naive O(n^2) test fix showed a framerate hiccup. So the solution needs to be more performant. I'll work on a solution much later as this is a minor issue but it will involve taking into account the fact that the seam vertex indices never change. Another issue I noticed is that blend shapes do not update normals. Which is fucking retarded. Luckily I haven't had a problem with this but I am now weary.

I started working on the chopsticks game logic. First thing was making a little logic module with the new code and popping in a function to move her hand to my finger. Video 2 shows what I got so far. I need to improve the animation and will do so soon with some finger action.

>>31548

>headpat module

You're a godsend, Shinobro.

6/6/18: New bugs and progress on Chopsticks.

A new bug which was found was a bug during the transition from animation to IK. I thought this was an unavoidable part of IK but really it was just me having the wrong order of execution for setting rotations. Video 1 shows the bug. Video 2 shows the fix.

I've been working on the chopsticks and there was a lot to do. Because Chopsticks needs fingers to have "on" and "off" animation states, I had to figure out a way to control all 60 quaternions (me and Shinobu's finger bones ). Avatar masks would not work because you can't change the mask at runtime so I instead hardcoded an array of Quaternions that contains 1 all-fingers out rest state animation to lerp to and from. Now she can have any combination of "on" and "off" fingers extended or retracted for playing chopsticks. Video 3 shows this along with a funny bug I was not expecting when I found it.

6/9/18: Chopsticks logic.

Getting into the meat and bones of the module finally. Chopsticks has very easy rules to it. It's also a Japanese game. The objective of the game is to get rid of the opponent's fingers. Everytime you tap the opponent's hand, you add your sticks to his hand. If they have more than 4, they lose that hand for the rest of the game. There is another rule which allows the player to redistribute their total number of sticks to bring back their dead hand. This will be implemented soon. There are a couple of animations not shown on this video. Sometimes Shinobu will fire an animation that makes her stare at her fingers in a pensive mood right before performing her turn. Just to add some variety. I also added another animation that blends in when she reaches out to tap my hand. This is so it looks like her whole body is being affected by the tapping motion.

This video is just to demonstrated how it's going to look. The game logic is actually buggy and you can see Shinobu trying to tap one of my dead hands. Will be fixed as I go along.

6/10/18: Got through a lot but was not as productive.

I polished animation events and timed them better so the transitions between certain animations and the procedural look at logic is smoother and less snappier. They feel more seamless now.

Accidentally entered the lion's mouth by going back to my model and tweaking the neck rig. Reason I changed the neck bone position was because the neck appeared too long during hyper-extension (video 1 shows before and after). This made her look like a giraffe. So I looked at some model reference and realized it was off anyways. Apparently neck bones don't have to line up along the neck anatomically. It can diverge a little to help deformations. Additionally, the shape was not very anatomically correct. It had too smooth of a transition (video 2). After I finished my neck tweak, I realized I fucked myself by now forcing myself to re-export all 30 animations since all neck animations now had old neck transforms which produced the abomination on video 3. I can still just change easy weight paints or mesh shape tweaks but editing the rig causes this mess. So I now had to re-export all animations from blender, re-apply all animation specific events to each in Unity, and re-add them all to the animator tree. I said fuck this and wrote a tool in Unity to help me sort this mess. My new AnimationEventCopier (image) now allows me to drag and drop my full target imported .fbx to an array, drag and drop all of my presently working source animations, and then press a button which automatically matches animations by name, copies over settings, and copies over animation events. Saving me an hour of headaches. I still need to do the grueling process of individual animation export in Blender, but this saves me one pain in the ass. Maybe I can write a script for the Blender portion later and get a real nice gamedev workflow pipeline.

Chopsticks logic without the redistribution rule is done. She now gets all happy when she wins (video 4). Under her neck above her throat is an ugly sharp normal seam you can see in video 4 which is caused by the previously mentioned normal problem. Will be fixed later.

6/14/18: Small neck tweak, finished new mouth rig, and finished chopsticks module.

Neck weight painting was revised because it was caving in too much when the neck bone was being rotated (video 1).

Reason why I wanted to redo her mouth rig was because it was showing too much interior red mouth color when smiling and looking at her through the side. This made her teeth look really distant and small. I reshaped the interior of her mouth and redid her dentistry so her teeth line up in a more realistic way to prevent her lips from clipping into the teeth. Before it was a rounded square shape teeth alignment. Now it's the natural sharp U shape.

I also took this opportunity to improve the shape keys for controlling her expressions. I looked at myself in the mirror quiet a bit and realized that my old frown shape key had the plastysma included which made it not possible for me to make a sad face and a startled sad face without doing both. So I separated the plastysma into its own shape key. Another similar thing I noticed is smiling. When you smile with your lips closed you use a different combination of muscles than if you were to smile with your mouth open. This makes smiles difficult to segregate by muscle groups and I wanted to keep the smile and smile mouth open possibilities separate. So what I did was compromise by making my smile shape keys do a little bit of both and then make a new shape for centerLip which brings the mouth the rest of the way to smile mouth open. I saw improvements in her smiles as they now no longer have strange mouth and lip stretching. (video 1 smile lips closed before and after). (video 2 smile mouth open before and after).

Chopsticks module is now completed and I can now start working on the last demo day module, kissing. Before I jump in I need to fix her win animation because it looks awkward.

6/17/17: Got a decent amount done today. Small fixes, began first part of the kissing module, separated leg and torso animations.

I fixed her hair from spazzing out every so often. It was caused by the hair bone strand ends constantly colliding with the view frustum collision boxes. Physics profiler is very useful (image 1). Also made another round at fixing the winning animation. It's much better but I did not spend enough time fixing her hands and thus that bit still looks off (video 1). Will revisit the hand motion later.

First part of the kissing module is now in the works, which is just when you approach her cheek. If you approach her too fast, she will recoil a bit in surprise but if you approach slowly she will simply look at you in disgust (video 2). This behavior is only for angry and will be different for when she is happy as that mood will have different sets of animations. Reason she is bending her legs in the video is because I recently separated the legs and torso animations.

The legs and torso animations now live on their own respective layers so I can play different locomotion animations. This is so interacting with Shinobu can be a lot more dynamic as in being able to carry out kissing or headpats while walking or moving. Headpatting really hard will push her in the direction of the headpat. This will also allow me to change her foot placement so she faces objects that speed up towards her. People usually face objects moving towards them. Currently there are only forward and backward animations but I will make sideways movement animations next.

>>31681

I have not but I checked it out. Very useful thank you. I do think however that all of what I'm doing for facial animations is overkill for anime models. You won't ever actually be able to see the detail on the facial animations because her face has unlit lighting, uguu effect, etc.

6/21/18: Overhauled animation system, finished first pass of locomotion, and improved headpat interaction.

The animation system had to be restructured to allow me to make changes to the legs without affecting the head. I used avatar masks to achieve this and also took this opportunity to make a face layer for when she speaks as it should override her current face blendshapes when that happens (Image 1).

I finally got right the locomotion blends. I am making my own walk animations and thus I had to figure out how to properly blend forward, backward, left, and right. One issue I had was that the feet animations did not sync up causing her to look like her feet was flying all over the place when side and forward was blended. This was fixed by exporting the right side feet animations 50% offset into the animations and looping that. Current result is (video 1). Sideways animation is verily subject to change and feels off right now (video 2). Sideways walk is harder than forward walk for animating. I think I have to smooth out the spine movements and improve the footing. Maybe it is too stompy.

Lastly, the headpat movements were improved by adding locomotion, adding a spine to neck IK, and changing the head rotation. So this logic module doubles up as a way to push her around. She can still get pissed though (video 3).

>>31718

>dem hips

6/23/18: Fixed mesh combiner normals, anatomy upgrades, new walk animation workflow, and kiss module proximity finished.

I fixed the previously mentioned normal seams caused by my mesh combiner. The fix was not to come up with an algorithm to recalculate, I just copied over the normals from the .fbx mesh instead. Image 1 shows neck seam normals visualized without a hard seam on the neck, arms, torso, and legs.

I spent some time fixing the anatomy of the torso on Shinobu because it bothered me for a long time. I am slowly memorizing more patterns in the human body. I am looking at reference and was able to point out several wrong things with my model. For the back, there was not enough bulk or muscle along the back of her ribcage along the spine. This made her look very thin and strange. Her bottom back above the rear was also too long. The side profile of a standing woman reveals the shoulder blades protrude and line up with the back of the skull and the butt. The curve of the spine goes down along the back and right where the curve turns towards the butt, that curve forms a continuous S with the front curve of the thighs. These changes were applied and I saw good improvements for Shinobu (video 2). For the front, a woman's standing profile has ribs 10 (the last bottom ones) protruding outwards the most which then dips along the belly and then back out with the pubis. Meaning on a flat chest, the breasts should not protrude outwards the most in profile view. The abdominis also have dips on its sides because of the stomach cavity. These changes were also applied to the model and it made her ribcage look a lot better but also made me realize the breasts were too perpendicular withe the front, still too big, and not wrapping smoothly around the spine. Before and after on (video 3).

I improved my animation workflow for when I animate walking cycles. First I make a circle on the floor and make its radius the size of the walk range. Then I just work on 1 foot and perfect it. Then I copy it over to the other foot and offset it. From there I offset the second foot backwards. Lastly I work on the spine. Originally I worked on the spine first then the feet and then tweaked the spine. But that was stupid because form follows function. Feet first, then spine. This saves me from having to go back and do larger spine fixes. Now it's just tweaks (video 4).

I also finished the face proximity part of the kissing module. I tied it together with the new locomotion and also made some new logic for making her blend and face towards a certain direction in a specified amount of time. This allowed me to do what I wanted which was make her startle backwards and face me at the same time (video 4). Additionally I had to come up with logic to manually sync the torso and legs layers only when specified.