Angular velocity was good now not so good


#1

I am remaking my entity clock, I have had a working clock face on Australia (old Adriania) for literally years now and I am ready to put one on Earth. But the system has broken down.

A clock should be fairly simple, you just put in the specific angular velocity and away it goes, but its not happening.
Seconds are good, and thats it. But minutes and hours are non-existent.

Angular velocity refuses to accept a value smaller than 0.01 degrees either by directly typing numbers or via script.

It feels like we are at mercy of Hifi’s inbuilt fudge factor that thinks zero is actually 0.0017 and thats where the inconsistency and inaccuracy that almost drove me out of Hifi, lives.
Now I believe that same inaccuracy thinks 0.01 deg/sec is actually zero. (I could be wrong)

I have been here long enough to accept that we cant have everything all at once, there are a lot of corners that have to be cut and perfection is something for the future, It is more important to get features up and running than it is to polish what we have. Thats ok I have learned to live with this.
Hifi is a difficult balance between stuff that works and stuff that goes boom so some things have to be sacrificed for the overall stability of the beast. But 0.01 is not a scary number, if we cant get down to 2 decimal points then we have severely limited ourselves. and I have to ask this…

Why are we given 4 decimal points on the GUI if we cant work with 4 decimal points?

It wont even let me put the value in now, where once it did.
Yes I had a working clockface for some time but now it seems impossible to do.

But I have to ask, am I doing something wrong, is there a way to dial in and angular velocity of 0.0083 degrees/second?


#2

Yeah noticed something similar when looking around the Physics Actions and bumping into similar issues with that abit while ago, but this should probably need a revisit. Basically any lower than 5 degrees is currently skipped, if the object is not in motion.


#3

Since when did the put that change in ?
That could maby explain why my doors have problems at times to. Especially witwo at the same time. I still think there’s something else wrong. but i gave up n the door, for now.

And in high fidelity more is stilll not working correct then that it get useable. Thw are or where to busy with the not so important HMD stuff and the result is that creating things is still a hell.

One reason why am hiding in blender. Because placing entity and look at it is just whst you can do without to much bad words at times. Godh what is edit.js a monster.


#4

That one has been there for about a year now according to git


#5

Right, interesting.
Anyway, keeping in blender for now. But skip everything below 5 is pretty bad.


#6

Those velocity thresholds were tuned for dynamic objects, not necessarily kinematic ones (I assume your clock hand is actually a kinematic object rather than dynamic). They are used by Bullet to decide when an object should be changed from “active” to “inactive” – if both velocities are lower than the thresholds for longer than two seconds (this time period is hard-coded into Bullet) then it will try to deactivate them. Whether it succeeds or not depends on whether the other nearby objects in the same “simulation island” are also ready for deactivation.

Deactivation is used to make moving piles of objects to finally settle down. There are different but similar thresholds for kinematic objects, but those must also have some finite threshold else they’ll remain active forever in the physics engine.

Bullet allows, on a per-object basis, for objects to set to never deactivate. It might be possible to expose that feature someday so that content creators could make very slow objects. I wonder what kinds of physics performance problems that would enable…


#7

Thanks for the reply.
Doesnt the damping factor decide when things settle down? if we choose zero damping then we want the movement to continue forever. And when we have selected non dynamic then there are no physical hulls to track.

Ok analogue clocks probably arent very important in the greater scheme of things, possibly slightly less important than say tetherball, this is of course debatable.
But what about the revolution of a planet, or the sun or moon in the sky? I imagine lots of disappointed users when they realize the system doesn’t extend to one rev per 24 hours.

If the capability is there already in Bullet then its there for a reason, why not utilize it? It could be as simple as a checkbox toggle.

Currently this means if I want to have an analogue clock then I have to script each hand and this script will remain active in the scripting engine forever also, is that more or less drain on the system than the physics?


#8

The damping causes a fraction of velocity to be lost each frame. In theory such a progression would never reach true zero but get infinitesimally small. In practice it would take a long time to reach floating point error and at that point it either hangs out at the error or actually reaches zero: depending on how the math was actually implemented.

“Dynamic” means it can tumble and be knocked about.

“Kinematic” means it moves but its motion is determined by some outside system such as a script. Kinematic objects can have collision shapes but dynamic objects will bump off as if the kinematic objects were of infinite mass (unmovable by collisions).

“Static” is like kinematic but not moving. Bullet keeps static objects in their own list for optimization purposes.

There are a number of features in Bullet that we haven’t yet taken full advantage of. Mostly for lack of time and dev resources but also because some features make it easy to create “physics bombs” that can kill performance. We haven’t yet made the physics engine around Bullet smart enough to not step down some deep rabbit holes of heavy CPU usage. A never-resting object would tend to make some of these deeper and more problematic.

I think analog clocks should always be run by a script. The fast moving hands could be moved kinematically so that the script doesn’t have to continually update them, but for most clock hands (including the second hand) it would be “cheaper” for the CPU to just tick it to a new static position every second rather than make the physics engine update it at 60 or 90 Hz. Slow moving hands should definitely be static and slammed to a new rotation after longer periods.


#9

That makes sense, thanks for taking the time to share the understanding of where we are with this.

Thats the kind of information I can use, thank you so much.