It’s (very) early days, but here’s what I have to show for a couple of weeks on this engine.
Today I gave the zombie 25 attack sounds, and when that felt like not enough, I added pitch variation to adjust the frequency of the sounds with some randomness - I still need to reimport all the animations on this zombie, as for some reason and despite my wishes, they have root motions, and this causes them to walk outside their physics hull - stripping the root motion is necessary, yet I can still learn something from the root motion, such as the velocity of the animation, needed to prevent foot slipping when moving… The attack sounds are loaded into a static array, and remain resident, but they average 200kb in size, and are in PCM wave format - its not a great amount of memory to use up, but this is just one character, anyone have advice about resource management for audio?
Maybe you can get rid of the root motion with
Hey thanks! probably I could skip root motion using your technique, but still have it in the animation in terms of a measurable velocity, it never occurred to me but it sounds feasible
Currently I have two character types, zombie and player, and a switch in the character update method, but I am thinking seriously about deriving subcharacters, I just have a thing about making more classes than needed, I try not to make new classes.
I like having a
Controllable class that characters, mounts and vehicles all inherit from. Control can then be easily switched even for unexpected cases like a mind-control-beam mod.
In your case you could even give characters a zombified state. This would keep it one class where AI could take control or the player could switch teams when zombified.
I tend to think the same way - currently I have a CharacterController that drives the player character (feeds device inputs) but the character class itself, has not been derived - the consequence is that any character can become controlled by the player.
CharacterController holds a reference to a target character, which represents the player character, and the character class currently has switched logic for player and non player characters (zombies, for now) - I am tempted to derive character subclasses, but currently there is not really enough different control code to warrant it. Still early days, but starting to see my undead coming to life. More zombie types coming soon, as well as some human survivor types.
I’m still thinking about foot-slipping issues, and whether it is worth my time to write an IK based solution to the issue. Our current IK sample does not deal with motion of the character, so it is really half-baked, but probably would act as a good point of reference for a better solution. I note that the Ninja model provides animation triggers on its footfalls for its walk animation - I propose analyzing the animation transforms to find the proper frames to tag for that purpose, and using the resulting events to update the IK targets. Anyone who has already done something like this, would love to hear from you.
This reminds me - we still have no sample that shows how to properly apply variable frequency to soundsources - it was not difficult to do, but a tiny example might help those who did not grow up with PCM wave audio and understanding how to modify frequency. Personally, I use a scalar to modify the base frequency of the loaded sound, similar to Unity, it’s pretty simple but quite effective.
My next move is to apply IK to solve ‘foot slipping’ in walk animations, and particularly for non-linear gaits.
If the walk animation gait is linear, we can generally find the right speed to move our model without resorting to IK - at least on a level plane.
But for non-linear gaits, and including inclined planes, the best solution I can think of is applied IK.
I’m using a dynamic character controller - it has dynamic physics, the character is moving, it has some linear velocity - worse still, the linear velocity is subject to change with acceleration - this is not a good fit with the existing IK Sample, so I’m going to adapt that sample to use ‘foot-planting’ based on Animation Trigger events. This basically means that I need to figure out for each footstep, a world position to plant that foot’s IK handle, and some time later when the foot is ready to lift up, release the ik handle. That’s the theory, anyway.
I’d love to hear from anyone who’s already tackled this.
Starting to think that using Animation Triggers is a bad fit with dynamic physics - it’s starting to make more sense to add kinematic rigidbody attachments to the feet, and detect per frame their collision with the ground, both start and end of collision are the points I need to move/disable IK handles on the feet to implement “foot-planting”.
Due to acceleration, and because we’re not analyzing animation in advance, we can only try to ‘guess’ where our next footfall will be - so animation triggers is a bad notion in that context. I’m just sorry I spent a day to make animation triggers work (some issues, raised) and happy to invent some physics foot shapes close to the foot bones
Today I hacked together a solution for foot-slipping without using IK, a cheap form of foot-planting.
I have two animation trigger keys on my Walk animation which represent the frames in my walk cycle where a foot is just starting to touch the ground, ie, being “planted”. It’s worth noting that my walk cycle is not linear - its a staggering zombie, could be a wounded soldier, etc.
In my handler for animation trigger events, I use booleans to note which foot is currently being “planted”, and also note the world position of the planted foot at the time it was planted.
Very late in the scene (SceneDrawableUpdateFinished) I grab the current worldspace position of the planted foot, measure how far it has “slipped” (due to physics) and subtract the resulting “positional error” from the worldspace position of the character’s root node, which results in the character being “teleported” such that the planted foot remains where it was planted.
The results look quite good for my staggering zombie whose linear velocity and animation speed are both increasing over time (he speeds up his “walk”).
Video : The solution was applied to the zombie, but not the player character.
Can you just upload it on youtube ? I can’t watch your video or download it.
is the dropbox link not working? i had to put some spaces in the https at the front of it
i would rather not youtube or facebook except to establish prior art
the dropbox should be alive
To prevent a onebox from being created you can put a link between < >.
Looks pretty nice, btw.
Happy to hear my ideas are well received - though in this case, the idea was not mine, it’s something that 3D artists use in their modelling apps (via scripting) to deal with foot-slipping on animations that contain no root-motion. My implementation for Urho is my original work, but this concept was not mine… just never seen it applied to models being driven by dynamic physics, in a game.
NinjaSnowWar would look a lot better with this added to it - and already has suitable animation triggers on the footfalls. I’d be happy to provide source / explain anything required to see this constraint added to that sample.
Modanung - thanks for the heads up about the < > stuff - it explains to me why xml is such an issue to post here!
Is there a document somewhere that describes these things, or is this just something we learn from being here, and with much thanks to kind people who have been here longer?
Does this text seem familiar somehow?
Type here, Use Markdown, BBCode, or HTML to format. Drag or paste images.
Before the Urho3D forums switched to Discourse I was already familiar with Markdown through sites like Github and Diaspora*.
Markdown is not familiar to me - I come from older stock, such as PHPBB and earlier bulletin boards that predate the current tech. I don’t know the markups. Would make a useful addition to be able to read about them in one place, thanks.
That’s what the second link in this post was for:
A websearch for “Markdown syntax” will get you several other sources. There might be some discrepancies here and there because of different implementations.