Acrobat Flying Circus like Cirque Du Soleil

[FairreLilette]

With SL's current technology...would it be possible to make an Acrobat Flying Circus like Cirque Du Soliel?

I'd suspect it could even be done with animesh acrobats plus real "avatar" performers.

Has anyone ever thought of making something like this...or would it just be too lag intense with SL's current technology?

[Da5id Weatherwax]

You ever played a really *evil* minecraft modpack where something is described as "expensive, but doable" ?

Don't plan on it being a short project. It would be doable but complex as heck and difficult to keep the lag down.

Another place where it's likely you'd have problems is animations that rotate the avatar in an entire circle. There will be places where what you want is the avatar to rotate past the "limit point" on an axis but the animation system insists on going "the long way around" instead. Sometimes you can overcome this by aggressively keyframing the transition but I've seen that fail too. Buy a wig, because you'll be tearing your hear out making Cirque du Soleil style animations

[OptimoMaximo]

On 10/25/2019 at 2:34 PM, Da5id Weatherwax said:

Another place where it's likely you'd have problems is animations that rotate the avatar in an entire circle. There will be places where what you want is the avatar to rotate past the "limit point" on an axis but the animation system insists on going "the long way around" instead.

There is no "limit point", it's all due to the animation software you use

https://gyazo.com/19dac26b18e6cdfcdd47e0b928a024fe

https://gyazo.com/54166de5e4026610e3fbaf8877666fc1

From the gifs you can see that i made the avatar rotate on itself 4 times (1440 degrees to be precise) and no "limit point" to make it go the shorter way around (not longer, anyway) occurred.

Edited October 28, 2019 by OptimoMaximo
typos

[Da5id Weatherwax]

oh I didn't mean to imply that kind of "limit point" - but more the mathematical one that results from the self-normalizing nature of calculating a rotational position. There are only 360 degrees or 2Pi radians of valid normalized range in a rotation about an axis and the math in handling them usually results in a value from -180 to +180, or -Pi to +Pi. Certainly the trig functions in calculating a quaternion are inherently self-normalizing in this way. The issue comes when the animation software has to handle tweening along a path that crosses from, say, -170 to +30. As you correctly point out they all handle this slightly differently and so it does depend on  the software used to generate the animation but it also depends on the viewers handling of the anim format in these situations too. It was a lot worse when all we had was bvh import because that introduced a third black box, the uploader converting the bvh to anim, but even now it's possible to come up with a set of keyframes that look like they work correctly in your animation software but when the result is uploaded the direction of the avatars rotation abruptly reverses between two keyframes. And it's inevitable that generating animations of the kind being discussed here are more likely to tickle that edge case.

[OptimoMaximo]

3 hours ago, Da5id Weatherwax said:

more the mathematical one that results from the self-normalizing nature of calculating a rotational position. There are only 360 degrees or 2Pi radians of valid normalized range in a rotation about an axis and the math in handling them usually results in a value from -180 to +180, or -Pi to +Pi.

hhhmmm..nope. I'm sorry but i have to disagree. The reason for 3D packages to default to euler angles is that there's no implied normalization taking place. When transposed in SL via scripting, that's certainly an implemented limitation, but animations do not go through those processes.

3 hours ago, Da5id Weatherwax said:

The issue comes when the animation software has to handle tweening along a path that crosses from, say, -170 to +30. As you correctly point out they all handle this slightly differently and so it does depend on  the software used to generate the animation but it also depends on the viewers handling of the anim format in these situations too. It was a lot worse when all we had was bvh import because that introduced a third black box, the uploader converting the bvh to anim, but even now it's possible to come up with a set of keyframes that look like they work correctly in your animation software but when the result is uploaded the direction of the avatars rotation abruptly reverses between two keyframes.

Sure, the uploader converter may fail in being precise because it performs a few tasks before data conversion to the internal format and then it "cleans up" such data to output a lighter file (i know this well because i wrote a .anim exporter for Maya, and i intently read through the viewer's python data handler that performs the translation from bvh to .anim to sort out issues i had in my script). But let's face it, the now-a-days main 3D softwares used in SL all support .anim, so aside from old-school users still using BVH for who-knows what reason, bvh is practically dead (unless it's a mean for animation exchange or import for retargeting purposes, although for the latter a FBX file performs just better, although bigger in size for sure).

However, .anim format has a specific rotation encoding that actually allows a LOT of complete 360 degrees rotations stacked on top of one another (i never tested the limit, truth be said), because it's not a pure normalized quaternion being written , it's normalized, conjugated (or negated, but i found conjugation gave out better results) and then translated into a integer range between 0 and 65535 (a 2 bytes allocation integer) before it gets to be written to file (each channel would be a double data type, 64 bits, or a float at 32 bits, depending on the 3D app and/or on the spcific function being called for the sampling, that instead needs to be 6 bytes,  2bytes per channel, and the fourth, the W, being omitted using a workaround called quaternion conjugation, which allows a safe reconstruction of the W term at run time, resulting in the need to write only x,y and z components from the calculated quaternion). Therefore, the problem definitely is in the program running the export, the 3D app is responsible only for pullling out a quaternion rotation but the problem is not there, it's in how the translation to the LL encoded value was done.

[Da5id Weatherwax]

This is going off-topic for the original discussion, so we should probably not go on, but it doesnt matter whether you rotate by 90 degrees or 450, you end up with the same quaternion - rotations are not "general" quaternions, they are unit quaternions. Every element of them is the product of a trigonometric function (or the "product" of several ) which can only produce values in the range  -1 <= n <= 1, inherently normalized. I'd love to carry on talking math with you and would love to learn from the insights you gained dissecting the import code smd writing your own implementation, but I guess this isn't the place for it

[OptimoMaximo]

5 hours ago, Da5id Weatherwax said:

inherently normalized

That is the difference. Maya at least outputs non unit quaternions when the function is called, then you explicitly apply a.normalize() function on the result, exactly for these types of applications. You can therefore extrapolate the intended behavior: it all gets scaled proportionally so that multiple turn around can be encoded. But I agree with you that this is going off topic 🙂