Skip to content

2021.06.10

hearttelemetry

Highlight for this release is telemetry.


Telemetry

Ragdoll is now able to gather usage statistics so that I can strip menu items that aren't used, pay more attention to the ones that are and get an overall understanding of how Ragdoll performs out in the wild.

FAQ

What is telemetry?

It's the term coined for gathering anonymous usage statistics and send it to a product vendor for a greater understanding of how their product is used.

Do I need it?

No, this won't help you. Not directly. But it will help you and others indirectly, in that it allows me to spend more time on features you use, and less time on those you don't.

What does it collect?

Mostly performance numbers, nothing personal. See Data below.

How is it collected?

Mostly through C++, but some of it through Python. You can read about exactly what it does in telemetry.py

What if I'm offline?

Then the file will still be written to your home directory, and you'd be welcome to email it at your own leisure to telemetry@ragdolldynamics.com

Opt-in

It is currently opt-in while I work out the kinks, so if you're interested in helping out put this in your maya.env or type it into your script editor before loading the plug-in.

Maya.env

RAGDOLL_TELEMETRY = Yes

Script Editor

os.environ["RAGDOLL_TELEMETRY"] = "Yes"

Data

Data is gathered and stored in 2 places.

  • Locally at ~/.ragdoll/telemetry_10-06-2021-100402.json
  • Remotely at the Ragdoll database

It is gathered and stored when Maya closes. Or more precisely, when the plug-in is unloaded.

Here's what the complete data currently looks like.

~/.ragdoll/telemetry_10-06-2021-100402

{
    "maya": {
        "crashed": false,
        "version": 20200200,
        "errors": 0,
        "warnings": 0
    },
    "system": {
        "time": "10-06-2021, 10:04:39",
        "memory_cpu": "31010.8 MB",
        "machine": "AMD64",
        "memory_gpu": "24576 MB",
        "gpu": "GeForce RTX 3090/PCIe/SSE2",
        "os": "win32",
        "processor": "AMD64 Family 23 Model 49 Stepping 0, AuthenticAMD",
        "render_api": "OpenGL V.4.6"
    },
    "ragdoll": {
        "simulationTimeMax": 1.2327,
        "computeTimeMax": 1.6763,
        "setupTimeMin": 0.301,
        "computeTimeMin": 0.7595,
        "setupTimeMax": 0.4756,
        "simulationTimeMin": 0.4697,
        "rigidCountMax": 15,
        "constraintCountMax": 16,
        "version": 20210606,
        "computeTimeAvg": 0.949111823737213,
        "simulationTimeAvg": 0.597494786145304,
        "setupTimeAvg": 0.25006875,
        "rigidCountMin": 15,
        "constraintCountMin": 16
    }
}

This was generated from that throbbing heart simulation above.

There are currently 3 categories of data gathered.

"maya"

As you can see, it'll capture how many errors and warnings were emitted from the plug-in whilst the plug-in was loaded. It'll also include whether Maya crashed the last time Ragdoll was loaded. Ragdoll's goal is to keep crashes at 0.

"system"

It'll also include system information such that I know how restrained to keep Ragdoll, both in terms of memory and CPU power. If everyone's running on an integrated Intel chip, then Ragdoll simply wouldn't try to benefit from the GPU that much. These numbers also help put the next category into perspective.

"ragdoll"

The ragdoll category is perhaps the most interesting, as it sheds light on how much you are willing to suffer haha! Ragdoll is a real-time solver and is designed to be operated without waiting. So if I see these numbers climb too high, I'll crank up the number of optimisations to bring them back down again. Simple!

Roadmap

There will be a publicly available website for this information - with graphs and charts - such that we can all witness just how fast Ragdoll is and get some perspective on the kind of workload it typically deals with. From this overview, development can then focus on exactly those.


Fractional Start Time

You wouldn't normally set your start time to 0.8 or 16.351, but it can happen whether you like it or not if e.g. physics was made in one scene and later referenced into another with differing frame rates. Such as 24 fps in one, and 30 fps in another.

If that happened, then best case your simulation flickers on the first frame, worst case you're looking at a fatal crash.

Why?

fractionalframesbefore

In this illustration, you can see how the simulation (blue) progresses alongside time (red). As we reach just beyond a whole frame, such as 1.1, you'll notice how the simulation immediately fills in that whole frame; even though we haven't actually reached the end yet!

The result is a simulation that operates on incomplete information. Your animation at frame 1.1 is not where it is at frame 2.

In this release, here's what happens instead.

fractionalframesafter

Now we're only simulating once we've actually reached a whole frame step. Your animation has reached the full pose at that frame and that's what will be used to compute the simulation. As you would expect.

Does this mean I can playback in fractional frames?

Not yet, simulation happens on whole frames and won't output anything until the next whole frame. At a later date, fractional frames will be automatically interpolated, similar to when you bake a simulation and set keys to linear.

This isn't typically useful for animation, but can help with motion blur during the rendering of fast-moving objects; especially spinning objects like propellers and wheels.

That said, you can achieve some pretty surreal effects with this. :D

image

slowmotion

Stay tuned for real-time interpolation, and do let me know if this is something you're interested in.

Thanks to Amedeo Beretta for spotting this issue!


Suspend on Bake

Baking is fast and light with the default option for disabling the viewport as it runs, but should you also opt to delete physics once baking is complete you would find suspension to have no effect. :(

This was due to deletion of physics also suspending the viewport as it deletes things and - wanting to be helpful - went ahead and resumed rendering of the viewport before baking got a chance to get started.

This has now been fixed.

bakefast

Speed!

0.51 seconds versus 0.13 seconds, a 4x speedup!


More Resilient Constraint Rendering

You are unlikely to end up with zero scaled things, but if you do you could also run into visual flicker like this.

Before

flickerbefore

After

flickerafter

Not only is this gone, it's fast too. It is as fast as though the constraints were never visible to begin with, giving you another option for hiding them. Scaling them down. Hah!