[Aardwolf]

Progress!

Holding the gun with both hands

I got the soldier to hold the gun with both hands. The physics of it is working ok, but I haven't got the character pose/animation right yet. More on that in the last section of this post. Also the gun jitters a bit more visibly than I'd like, but I can fix that later.



Shadow maps the "correct" way

I got my shadow mapping to use the built-in depth buffer, instead of what I had been doing before (manually encoding the depth info as a color, then decoding it again). Surprisingly enough, it's actually slower According to Australian doofus who doesn't like FreeSpace, the ability to read depth values directly from a depth texture (presumably instead of using comparison operations) is a relatively new feature and some older graphics cards may not support it... so maybe it's also the case that the graphics cards that support it may not support it as well as they supported the shenanigans I was doing previously.

But it just makes more sense to use the depth buffer that's already being written to, rather than having a redundant color buffer to store the same data. So I'm going to keep it, even if it's somewhat slower than the color buffers thing. And anyway I was able to get it going faster again by simply decreasing the resolution of the shadow map from 4096² to 2048².

Maybe it would be better to use the depth comparison stuff for the shadow maps, where instead of reading floats from the depth texture, I can only compare the floats to other values. Idunno, I might go back and change it later. I think I will still need to get actual floats from the main depth buffer, even if the shadow map depth buffers can use depth comparison.



Cascaded shadow mapping

After I got shadows working the "correct" way, I made it so it renders 3 different shadow maps, all with the same resolution, but each one covering a larger area centered further from the camera. Then I procrastinated for a day. Then I made it so the deferred lighting (or is it shading?) fragment shader actually uses all 3 of the shadow maps I rendered.

I actually had to reduce the resolution again once I had 3 shadow maps going at once, so now it's down to 1024². It still looks decent, so I'm content to leave it as it is for now.



Enough of this graphics stuff, let's get back to C/PHFT

Character/Physics Happy Fun Time, that is.

Part of my problem, I think, is that I need more animations for my doods. As it is now, my soldier has animations for walking forward and backward, left and right, and turning left and right. But it doesn't account for the normal vectors of the terrain it's stepping on, and it doesn't account for differences in terrain elevation either. I might be able to resolve the normal vectors thing entirely with articulation of the ankle joint, I'm not sure. But to deal with walking up or along a slope I need animations for those things.

But my attempts to make poses or animations where more than one of the Dood's bones would be constrained (e.g. holding a gun with both hands, or standing with two feet on the ground) have all been failures. The way I have things set up, I tell each joint what orientation it should be in, and it will try to do that. But if there's two or more external constraints, I'm specifying more degrees of freedom than I have. Also I have to worry about whether the joint orientations I'm specifying are within the joints' rotation limits. Both of those issues can cause the Dood to tense up and contort himself in strange ways, making the actual bone orientations not match what the pose is telling it to do... which in turn makes editing the pose that much more difficult.

What I need is a tool to create and edit Dood poses and animations. So far I've made a program which displays a Dood, and that's about it. I spent a fair amount of time yesterday trying to plan in advance how the data would be stored for various purposes:

• Designing the file format for animations
• Maybe having two such formats: one for the editor and one for use by the actual game (like how PCS2 has both .PMF and .POF)
• Designing the struct/class for animations loaded in the editor
• Designing the struct/class for animations for use by the actual game

But ultimately it was too much and I didn't end up settling on anything. Maybe I will just make it possible to edit the pose of the Dood, and worry about I/O and formats and stuff once I get that working.



@z64555: Ehhh... dynamic lighting for particles is a low priority.

[Aardwolf]

It's not programming, per se, but it pertains to the development of this game, so I reckon I'll post it here anyway: progress shots of the soldier model! I redid the jetpack so it has downward-pointing nozzles instead of backward-pointing grills, and I've done some work trying to fill in a lot of the big holes in the model while at the same time trying to keep it looking reasonably flexible.

I'll be doing some more detail-work over time, and eventually I'll try to bake the high-poly mesh onto a normal map for a lower-poly mesh for actual in-game use... as it is now, the poly count is 11640 triangles just for the upper body.







< it's a perspective shot, his hand isn't actually that big



< no, the in-game version won't be hollow on the inside


On the programming front, I've gotten a little done on the "DoodAnimTool" program, but there's a long way to go with that. It displays a Dood now, and I can select bones using the mouse. Earlier I had it so I could rotate individual joints, but that got broken when I implemented multi-bone selections recently. Next I'm planning to get rotation working again (but with multi-bone selections), and figure out how to impose external constraints (e.g. locking the xform between the two hands gripping a gun, or 2+ feet planted on the ground).

[Aardwolf]

Progress!

I've gotten the "DoodPoseyTool" aspect of "DoodAnimTool" effectively completed now! I can pose the soldier dood's bones, enable or disable external constraints (e.g. hands gripping the gun, feet locked to the ground, head forward vector matching gun forward vector), and load/save from/to a file of the user's choosing.

Also I've converted an updated version of the soldier mesh (skinning is shoddy and the hands are unposed, but whatever; I can improve that later).



Now what?

I still don't know quite how I'm going to proceed. I think it would make sense to split the soldier dood into two parts: upper and lower. The upper part would handle getting the head's and gun's forward vectors to point in the correct direction, while the lower part would handle connecting the chain of bones from one foot to the other. What I haven't worked out is how to split them ... or how to integrate them.



The derpy approach

Probably the simplest solution would be to just pick a pose for "torso 2" (the bone the shoulders and head attach to), the arms, and the head, and use that for everything, aiming by bending the joints between "pelvis", "torso 1", and "torso 2". I've attempted to do this in the FPS engine already, but it's pretty crummy. For some reason the gun forward vector doesn't match the head forward vector, even though in DoodAnimTool it said the total error squared for the whole dood was in the 10^-11 range... meaning the angle difference between the directions could have at most been in the 10^-6 radians range. So that will need investigating.

Even once the gun/head alignment issue is resolved, the above solution is pretty crummy. I've noticed from studying my own movements that when I "aim" left and right my entire body turns, not just my spine or arms.



The 3x3 grid idea

An idea I've been thinking about doing for a while is to have a 3x3 grid of poses for everything "pelvis" and up, and lerping between them to control the direction the head & gun aim. However, as I just mentioned, IRL your pelvis doesn't stay in one pos/ori when you sweep your aim left/right. Maybe I could do something where it comes up with the pelvis xform first (logic for this will be non-trivial), then transforms the "forward" vector (computed from pitch/yaw values) into the pelvis' local coords and looks up that value in the 3x3 grid? I don't know.

[z64555]

The 3x3 grid idea

An idea I've been thinking about doing for a while is to have a 3x3 grid of poses for everything "pelvis" and up, and lerping between them to control the direction the head & gun aim. However, as I just mentioned, IRL your pelvis doesn't stay in one pos/ori when you sweep your aim left/right. Maybe I could do something where it comes up with the pelvis xform first (logic for this will be non-trivial), then transforms the "forward" vector (computed from pitch/yaw values) into the pelvis' local coords and looks up that value in the 3x3 grid? I don't know.

This is where a control system comes in handy, You'd essentially feed the horizontal angles into the system, and it'll determine if it needs to reposition the legs to get a 'comfortable' delta between the pelvis and the shoulders. For a simple discrete system, you'd define a range of angles where the pelivs won't reorient towards the forward vector, and outside of this range it'll lerp towards the correct pose in the 3x3 grid. For left and right strafing, another range of angles can be set to keep the forward vector 90 degrees to the direction your strafing. In a situation like this, a dual-input, three-curve, single-output fuzzy logic type setup might be helpful.

[Aardwolf]

Just to clarify, the idea of the 3x3 grid was that I specify the aim direction relative to the pelvis, and it uses that to look up what orientations to use for all the joints above the pelvis.



The algorithm would be something like this:

Code: [Select]

Upper body imposes limits on possible pelvis xform, based on aim direction
For each leg:
    Leg imposes limits on possible pelvis xform, based on PlacedFootConstraint/anticipated collision with ground
Select pelvis xform

Look up upper body joint orientations based on pelvis xform and aim direction
For each leg:
    Look up leg joint orientations based on pelvis xform and PlacedFootConstraint/anticipated collision with ground

Obviously I have very little idea how I would actually implement everything up to and including "Select pelvis xform"



From my IRL observations, at least when standing still, it seems that any change in the gun/head yaw will involve a change in the pelvis orientation. I think as far as the condition for "aim direction is too far to one side; pick up a foot and turn in place" goes, I might as well compare the aim direction to something like the average forward direction of the feet, rather than the pelvis. I'm not sure where in the above algorithm decisions of that nature would go; I'm thinking either before everything, after everything, or in the second "for each leg" block.



Edit for minor update: I've patched/fixed the issue where the head and gun forward vectors matched in DoodPoseyTool but not in the actual FPS. Turns out it's using the joint positions from the UberModel instead of the ModelPhysics. For now I've copied over the more up-to-date joint position data over from the ModelPhysics. In the long term, I will probably make it so that any joint which is in both uses the ModelPhysics's position.


Edit for slightly bigger update: I got that 3x3 grid thing working I ended up triangulating the grid quads because it's a heckuva lot easier that way. The range of motion is quite limited, so the pelvis is going to need to do a lot of the work of orienting to face different directions (especially up/down). Still, progress!

[Aardwolf]

I'm completely stumped. Help me, Internet!

[Cobra]

Smoke weed, get inspiration?

[Aardwolf]

Haha... no.



Minor update, no real progress:

I'm considering ditching my custom PlacedFootConstraint foot/ground interactions and going back to plain old ContactPoint. The reason I originally decided to make a custom Constraint subclass was because I wanted stable contact between the feet and the ground, and none of the fiddling I was doing with the physics could get ContactPoint contact to actually be stable.

But PFCs have their own problems I've been unable to figure out how to resolve: they need conditions for when to break, both as demanded by the animation system, and in reaction to the physics (e.g. if something really big hits the player and they ought to go flying, the PFC can't stay active). And I haven't been able to come up with reasonable conditions for that. So I've got a Dood whose feet weld themselves to the ground every time he lands, and if he steps on something light-weight like the leg of a bug it's bad news.

Also occasionally I get crashes when disposing the PhysicsWorld, but that's probably because I've done something stupid, so I don't feel it's fair to hold it against PFCs in a PFC-vs-ContactPoint discussion.



Possible strategy

I've got a little bit of an idea for how I might implement the lower body stuff for the Soldier Dood. It occurred to me today that if the xform of the pelvis and the foot are both constrained and moving the pelvis makes it impossible to solve the pose, then it is time to separate the foot from the ground. So I put together a little bit of pseudocode based on this.

Code: [Select]

have a "desired velocity"
x,z components are based on forward and sidestep controls
y component is based on terrain slope? and jump control
constrain pelvis pos/ori:
pelvis moves by a velocity somewhere between the desired velocity and the current average velocity of the dood
pelvis yaws a little to help the aim yaw
pelvis moves forward/backward to balance the aim pitch (and maybe pitch the pelvis up/down a little as well?)
for both feet:
if the foot is grounded:
try to solve the knee IK to keep it grounded
if the foot is not grounded, or if the knee IK fails:
find a landing place for the foot
if landing place found:
move foot toward the landing place (but also up)
foot moves at about 2x the dood's average velocity
else if override (e.g. sprint or jump):
move foot forward anyway?

I reckon it has the best chance of working using the PlacedFootConstraint setup and with the cheaty no-angular-momentum stuff enabled. I'd like to disable that if possible, and I'd prefer a ContactPoint solution over the somewhat hackish PFC system, but I don't know if that will be possible.

Does this seem like a reasonable approach? Any oversights or complications I should worry about?

[Cobra]

I still suggest weed.

[Nuke]

I still suggest weed.

weed is good, but i cant say ive written many lines of code in a stoned state.

instead may i suggest crystal meth.

[Aardwolf]

Quit it guys

[z64555]

So, you've got two analog control inputs for the feet control, the x and z desired velocity, and a couple of digital controls for the y - posture and jump.

Final velocity of the feet depend on the x and z slope of the terrain, and the y velocity is simply a product of the desired velocities and the terrain slope angles. If you set up your cheaty system to directly set the x and z final velocities to what is desired, then you'll get the hackish behavior of basically ignoring the terrain beneath it (worse-case: climbing a sheer wall with a y velocity of infinity).

Everything else seems like a good hypothesis for now. 

[Aardwolf]

Not sure what you mean by analog and digital here. My control state has floats ranging [-1, 1] named "forward" and "sidestep", but for now these are always { -1, 0, 1 }. My Dood has floats "pitch" and "yaw". Pitch ranges from -π/2 to π/2. Yaw is periodic every 2π... although I'm not 100% sure it's properly symmetric for +/- 2π. Jumping is currently a boolean but I plan to change it to some sort of timer, so that if when you press it it starts crouching and then when you release it it starts moving upward... and have special behavior for long presses, or particularly short ones.

I'm not using a simple heightfield here, so determining "terrain slope" is nontrivial.



Beginning to plan additions to existing classes, etc. ...

Code: [Select]

per-foot/leg stuff:

end effector info?
position
required normal vector (or just "down"?) (optional)

out-of-contact timer

cached proposed footfall
bone position (and orientation?)
object to step on?
ETA?
required ground clearance?

virtual methods:
solve leg IK
find suitable footfall
pose ungrounded leg (with or without a planned footfall)


Code: [Select]

dood stuff:

virtual methods:
compute desired velocity
set root bone xform

new "jump timer" behavior


[Aardwolf]

Bad Chemistry

Welp, progress has stalled due to bad brain chemistry.

Specifically, me being afraid to start yet another thing that won't pan out. Also, cycling between "This is too hard, maybe I should just do it the cheaty way", "I still don't know how to proceed", and "It would be so much cooler if I could do it without cheating".



Hmm

I did some experimentation with the posey tool to see what range of pelvis xforms I can have given a constrained xform between the feet. Unfortunately all I really learned is that the Soldier's rest pose is not the best point to start from. The rest pose has the knees almost straight, and the feet fairly close together. I think a pose with the knees slightly bent and the feet spaced and angled a little further apart would make for a better "default" pose. I say "default" rather than "rest" because at this point I really don't want to bother having to change the model, joints, and collision shapes. So the "rest" pose will continue to be the pose in which the mesh, joints, and collision shapes are defined, and the "default" pose (assuming I act on these observations) will be something other than "all joint orientations are the identity quaternion".

Maybe I will try the experiment again starting from a better pose.

I also noticed that I can actually get the gun's forward vector a lot closer to the upper torso's forward vector (instead of always having to aim left, like a right-handed archer); I just have to put the gun right at the hip, not half-way between hip and shoulder. The revised version of the gun model with the cut-off stock will also help with that, since there's less "the gun is intersecting the player mesh" to worry about.

[Aardwolf]

Video bumpage! Because maybe generating more interest in the project will get someone to help me with ideas!

[Flipside]

That is simultaneously awesome and hilarious...

Makes me think of Space Harrier for some reason...

[Aardwolf]

Joint-torque-based movement progress!

I made some very simple control logic to orient the head the way I want it. This was probably the simplest task of all the joint torque stuff I'm going to have to do, because there's only one joint that affects the head's orientation, and I can compute the solution analytically. This setup seems to work fine as long as the desired head orientation is actually reachable.



Arm control partially working!

Here's what I came up with:

Each bone has a desired orientation. I compare that with the current orientation to get the angular velocity necessary to get it to that orientation by the next tick, then compare that with the current angular velocity to get the angular acceleration necessary to get it to that velocity by the next tick, and then finally multiply by the moment of inertia to get the net torque I need. It's math I already know how to do, but it still took several tries to get the signs right, and the order of the quaternion ops.

So I know what net torque I want on each bone, but the thing I have control over is the torque applied at each joint. It's a 3-component vector which has to be within a certain OBB, the bounds of which I'm still tweaking. Each joint applies a positive torque to the "parent" bone and the opposite torque to the "child" bone, e.g.: the wrist applies the positive torque to the lower arm, and the opposite torque to the hand. By picking the right values for the joint torques, I can set the net applied torque on each bone, which determines the angular velocity of the bones prior to going through the constraint solver. But when the solver runs, it changes the linear and angular velocity of everything, and the thing I'm interested in controlling is the angular velocity after the solver runs.

There's no simple formula I can use to go from the actual net torque I want to the net applied torque necessary to produce it. Running the constraint solver to test a proposed solution is too expensive to be feasible. Also it may not even be 100% deterministic, because I'm using pointers as hash values. For now I've approximated and said "net applied torque = actual net torque", and it seems to work, sometimes.



So what's left?

I've got to make a few improvements to the posey system I'm using to come up with bone orientations—the 3x3 grid of poses I mentioned a while ago. For one thing, it can't aim straight up (or even reasonably close). I've also noticed some odd behavior as it switches between different triads of poses to interpolate between. That and the orientation it's suggesting for the gun is sometimes noticeably off from the direction it's supposed to be aiming. It needs some work.

I don't yet know what will make good values for the joint torque limits, but I'm fairly certain they won't be the same for all axes of all joints, so I'm going to want to make them configurable. Maybe I'll add that as an optional field for my ModelPhysics-builder utility function.

[bobbtmann]

I enjoy seeing the updates you post of your engine, though I'm not a very good programmer so I can't offer any advice. It's looking really good, though. Are you planning to build any games with it?

[Aardwolf]

@bobbtmann: Maybe calling it an "engine" in the thread title was misleading. Although I am trying to develop things in a way that will let me reuse a lot of the code, there's only one active project using the engine, and that's the FPS where you fly around with a jetpack and shoot giant space bugs.



Minor Progress Update!

The Dood can now aim straight up and straight down! Also I've now got the spine joints' torques working properly, and the Dood is now anchored by its pelvis instead of the upper torso. It could probably use a few tweaks, but it's mostly working.

There's only one major task left before I can say C/PHFT is working (for the Soldier, at least). Unfortunately it's the hardest part: the legs, and the foot/ground interaction.

[Aardwolf]

Bleh. I'm stumped again/still.

Somehow I've gotta make a function that takes the Dood's state and some parameters specifying some "goals" for it, and from that selects torques to exert for each lower-body joint to exert. The goals will probably be expressed as a desired linear and angular velocity for the pelvis and for each foot.

I could assign a score to a state, or to a transition between states, scoring based on factors like...

• How well linear & angular velocities of the pelvis and of each foot match the desired values for each of those bones
• How much total torque was applied (maybe useful to minimize?)

Problem. In some situations a series of "bad decisions"¹ could cause the Dood to "back itself into a corner", where no possible output would let it satisfy the requests. Minimizing joint torque might help a little with this, since more torque applied amounts to more torque that might potentially need undoing later. Idunno.

Hypothetically for any input state I could do a lot of iterations to try to find the set of output torques with the best score². So I could call that the "correct" solution, and feed that to something like a neural network as training data. I reckon that would take too long to train, might be too slow at runtime, and would probably need to be redone any time I change some tiny aspect of the problem (e.g. modifying the Soldier's collision shape).

Also neural nets hate me.




¹Bad for the reason stated, but presumably good enough at the time, or good enough according to a poorly designed scoring function
²This is complicated somewhat by the fact that the constraint graph solver is not 100% deterministic, because I use objects' pointers as the hash function for those objects. The per-tick differences are tiny, but the cumulative effect can be significant. Understatement.