Oh crap, my model animation stepped out of my bounding hull [Solved]

What is the best way to get the (current) bounding box of (animatedmodel) ?

Please see my attached issue.

The capsules seem like CollisionShapes. Maybe you could draw a debug box to visualize the model’s bounding box?
Something like:

debugRenderer->AddBoundingBox(animModel->GetBoundingBox(), ...);

That looks like the character demo. If so then those white capsules are the physics capsules for the character in the demo. Like @Modanung said.

The capsule, in those samples, does not account for animation, even in the absence of root motion.
I will make a post soon about my improvements to the Character class, and offer some solutions to dealing with these issues.

My projects work fine. I have my characters animated, and they do not do this.

Yes there is something more happening here.
My application creates a scene, saves it, and reloads it… I have hassles with the latest build of Editor on Linux, and I’m too focused on making code work to worry about downloading the old stable version.

Occasionally, it appears that after loading, some booleans are not being set correctly - Despite being serialized to disk!

EDIT:
OK! It seems that our Factory function is not clearing the memory on new objects, and that serialized variables which have default values at the time of serialization are not serialized at all, and not initialized to default values by the factory. This means that if you have a serialized member, with a default value, and don’t initialize it yourself, it could have any random value at runtime, and not what you expected, given that you declared it as serialized and gave a default value that was never applied. This seems like something I might elect to remedy with a PR.

Yeah, something funky going on, other than my animations having root motions
I consider this thread solved, despite having no clear answer, my issue is purely caused by loading a scene, and the factory not setting default values on my serialized members. I would like to see this resolved but I am lazy, and writing about it at least there is some record of the issue and how to resolve it. Should be fixed in the head of the repo.

I know right, I should be responsible for initializing my own data - but if I went to the trouble of registering my data as serialized class members, I would expect that the defaults I provided would be applied by the factory. Does that sound like a reasonable suggestion?

This case is solved - when deserializing, the Urho3D factory will not automatically apply any default values you defined as serializable, unless you changed the value from what you declared as default prior to serializing - we end up with a situation that is unsafe unless you (eg in constructor) manually apply the same values you already declared to be defaults - you’re expected to initialize your values as WELL as define the default values that will never be applied during deserialization but only used to filter some data during serialization - I would like to hear some talk about this because really, it’s pretty cheap to fix this.