Saturday, January 25, 2014

No-Flip Quadruped Hind Leg {

Credit to Morgan Loomis for initial leg rigs (Foreleg, Hind leg)

Link to No-Flip Foreleg post

As before, I'd like to share my No-Flip solution to quadruped legs rig. This time, I'll be doing the hind-leg, as promised. I'll briefly explain the initial leg rigs, but will focus primarily on the No-Flip nature of them. If you want more information on the initial rigs, check out the links above.

The Hind-Leg solution utilizes the same techniques as the Foreleg, but the extra ankle joint gives us some more work to do.




Tutorial {





Start with a joint chain on the XY or ZY plane. This will be the main joint chain. For simplicity, I left out the toe joint, but it shouldn't be difficult to add it if you wish.

Thursday, January 2, 2014

I'm Back!

Hey everyone,

I'm just posting a quick message saying "I'm back"! I'll be moderating comments, replying promptly to comments, and posting more programming and rigging goodies now. My Sincere apologies to all those who wrote comments and requests that were unanswered. Life got a little busy... I'll be sure to check for new comments daily.

Thanks for following,
-K

Sunday, October 14, 2012

Character TD Reel {

Finally, I have finished my Character TD reel! What do you guys think?

Note: I suggest you watch it in HD (720) because pixels.



-K

Sunday, October 7, 2012

Unity RTS Grid (1.1) {

I've made some improvements to my Unity RTS Grid System. For starters, no more brick boxes and spheres! Here's a list of the significant changes since the last post.

Change Log (1.1):
  • Integrated Unity Navigation for unit pathing
  • Modified Grid System to be independent of models/shaders
  • Added fast rectangle marquee selection system (No Ray-tracing)
  • Added temporary artwork (So my eyes stop bleeding)
  • Created R-Tree system (WIP)
And here's a video demonstrating the selection system and Navigation integration:


A note on the Navigation. The building is also a NavMesh, since they will be dynamically added. Currently NavMeshes apparently can push each other around. This is a bug I am going to fix, not a strange design choice.

Selection {

The most accurate way to select an object is to trace rays from the camera's mouse position, into world-space and check for collisions with objects. For rectangular selection, the amount of rays needed increase dramatically. Since I want this system to be able to run on mobile platforms, I needed a faster method.

First thing that came to mind is unprojecting the unit's position from world-space to screen-space. Then simply checking whether the new point was within my rectangle would determine if it is selected. This only works for the single point of the unit's pivot, meaning my rectangle could intersect with most of the model without selecting it. So I simply added a radius and made it a circle. The circle is then tested for intersection with the selection rectangle and more accurate, if still approximate, selection is determined.

There are a few shortcomings with my system, however. Firstly, circles by no means accurately express all models' shapes. Also, my method [currently] doesn't take into account perspective. That is, the circles don't scale with distance from the camera. I have a solution to this but I am unsure if it is necessary or fast enough to be worth it, since my RTS camera may not create much perspective anyways. I'll just save that for another update.

}

R-Tree {

And for those interested in some technical background, here's a video demonstrating the current progress of my R-Tree spacial data structure.


This will be used to sub-group units and items into proximity based bounding rectangles (R for Rectangle). The R-Tree will allow for fast look-up of units based on position. So, for instance, when calculating precise line-of-sight, I only want to check units close to a given unit for efficiency. This allows me to quickly obtain these units.

I am not quite happy with the amount of overlap in the tree at the moment, so I will be working to minimize overlap and area of rectangle groups when I integrate it into the Grid system.

}

I'd be happy to go into more depth in any of the techniques mentioned or unmentioned, so feel free to post a question in the comments below!

-K

Tuesday, September 18, 2012

Unity Grid WIP {

Here's something recent I've been working on for a bit of fun. It's a grid system with fog of war for Unity3D. It is in its early stages at the moment, but it gives you a decent idea how some of the back-end works.

Here it is with a high cell size and a high resolution fog of war texture (for clarity of grid).


Sphere is a Unit, the big cube is a Building, and the other cubes are discoverable objects or set models that respect fog of war.

The grid is scale-able in both size (maintains cell size) and cell size (maintains size). Unity sight range and radii are based on cell sizes so they scale with cell size.

This grid will support any mesh for terrain, not just flat planes. It can also support a very high amount of cells per grid, as it is not instantiating an entire GameObject per cell. The grid lines are a simple projector, scaled to correct size, and with repeating texture.

I don't have pathing done, which will enable the unit to navigate from point A to point B by itself. So for now it just follows the mouse, at the collision point between the mouse ray and the ground.

Fog of war is computed on a per-cell basis, and upscaled to a higher resolution texture to avoid interpolation problems. In the ground shader, I simply multiply in the fog-of-war texture. In each object's shader, I check it's cell's visibility, and multiply by the appropriate tint. Simple.

I could go on and on, but I hope someone else finds this stuff interesting! I'll follow up with progress as I would like to release this for other Unity users.

-K

Friday, September 7, 2012

Soft Feet + {

I did a little more work on the Beast's Soft Feet and thought I'd post the result. The goal was to make the nail extending and retracting more true to a realistic cat paw.

  • The model needed to be changed to adapt to the improved rig. 
  • The nail needed to pivot around the toe joint accurately. 
  • The surrounding skin needed to react to the nail.

This was my reference for the nail pivot:

The nail pivot was a simple matter of adding a bone or 2 to the end of the nail to use to pivot the nail. The trick was getting the skin to wrap around the nail as it extends and retracts. For this I decided nCloth was the best bet to get a realistic effect.


Skin Cinch {

I didn't want to simulate the entire mesh, since I wanted the skin around the nail to have really accurate collision (high settings). So I created a cinch around the nail. The cinch is an nCloth with dynamic constraints for maintaining transforms and attracting toward the nail. The nail is a passive collider for the skin cinch, so it never penetrates the nail itself. I then use the cinch as an influence on the actual mesh. This avoids simulating the entire mesh and focuses the simulation on the area that matters.

Comment below to ask questions or give feedback! Hope this helps!

-K

Wednesday, September 5, 2012

No-Flip Quadruped Foreleg {

Credit to Morgan Loomis for initial leg rigs (Foreleg, Hind leg)

I'd like to share my No-Flip solution to quadruped legs rig. I'll briefly explain the initial leg rigs, but will focus primarily on the No-Flip nature of them. If you want more information on the initial rigs, check out the links above.

As with any IK solver, flipping is a common and troublesome problem. Once the IK handle breaks the IK origin's plane, the knee flips around. This is almost never a desirable effect. So here's my No-Flip solution.




No-Flip Tutorial {






Start with a joint chain on the XY or ZY plane. This will be the main joint chain.


Duplicate the joint chain, rename to "02"s, and remove "wrist_02_jt". Add an IK RP solver from "shoulder_02_jt" to "foot_02_jt" (kneeIK). Create a locator called "knee_PV" and use it as a poleVectorConstraint with "knee_IK". This will be our driver IK.



Add another RP IK from "shoulder_01_jt" to "wrist_01_jt" and name it "ankle_IK". Group it, place the group as a child of "elbow_02_jt", and snap-drag its pivot (hold d+v) to "foot_01_jt". This allows the wrist to pivot by rotating the "pivotAnkle_grp", while keeping it aligned with the forearm!  This is the main genius behind Morgan's rig.

Now let's include the foot and toe. Create a SC IK from "wrist_01_jt" to "foot_01_jt" and name it "foot_IK". Now create another SC IK from "foot_01_jt" to "toe_01_jt" and name it "toe_IK".

Let's make a control handle. Create a NURBSCircle, name it "foot_ctrl", and snap it (hold v) to "foot_01_jt". Place all the other IKs under it ("knee_IK", "foot_IK", "toe_IK").

We have now completed the Foreleg rig by Morgan! Now let's make it No-Flip!

Create a 2-length joint chain and snap-drag (hold v) it to start at "shoulder_01_jt" and extend to "foot_01_jt". Add a RP IK to it and name it "helper_IK". Now move "helper_02_jt" up until it is half-way up the leg. Since we made the IK first, movement of the joint will be constrained by the IK for us! This joint chain will be used to keep our "knee_PV" in line with the knee at all times.

Create a locator named "helper_PV", snap-drag (hold v) it to "helper_02_jt", and translate it in Z (if your joints are on the XY plane like mine). Now poleVector constrain "helper_IK" with it. This will keep our helper joint chain from flipping, and thus our knee. (To see what I mean, disable this constraint after the last step).

We need the "helper_PV" to stay between the shoulder and foot, and always on the same side of them. So to avoid getting rotations, we'll use a pointConstraint. Group "helper_PV", select "shoulder_01_jt", shift-select "foot_01_jt", shift-select "helper_PV_grp", and Constrain->PointConstraint.

Now that our helper joint chain won't flip, we can use it to drive the knee PV. Group "knee_PV", select "helper_01_jt", shift-select "knee_PV_grp", and Constrain->ParentConstraint. The group allows for animation of "knee_PV" after the constraint.


That's it! Give it a trial test to see exactly what this rig gives you in comparison to a normal IK setup. It should not flip in the XY plane at all! This should give your characters much more freedom of movement forwards and backwards. And it automates the PV's, so no need to animate PV's every step!

I hope this helps with your quadruped rigs! Thanks again to Morgan Loomis for allowing me to use his awesome foreleg rig! I will be posting a No-Flip solution to his hindleg quadruped rig soon!

Feel free to comment if anything is unclear! I'd love to hear some feedback!

-K