[x3d-public] Units for BVH vs HAnimMotion.values

Sat Oct 14 17:31:37 PDT 2023

Also, even if there were three decimal points on a line after the “center,”
and I could write a substitution commands for sed, you’d still complain
about too many digits.

So it’s pretty fruitless about moving any decimal points, better to fix
x3d.py.

John

On Sat, Oct 14, 2023 at 6:49 PM John Carlson <yottzumm at gmail.com> wrote:

> Joe, in a text editor, to move the decimal point for 150+ numbers is
> inhumane.  If you’ve got a macro for it, please share.
>
> And you would have to do this each time you generate a file.
>
> Be my guest.
>
> On Sat, Oct 14, 2023 at 1:45 PM Joe D Williams <joedwil at earthlink.net>
> wrote:
>
>> Joe > We are not using it that way because we will always interpolate.
>>
>>
>>
>> "always" meaning realtime may allow interpolating between key times, even
>> if keyframes are provided at standard video/film frame rates. It is typical
>> that through good use of interpolation, key times and keyValues can and
>> should be much reduced.
>>
>>
>>
>> Another issue is what to do when the dimensions for hanim model like
>> skeleton or skin are given in cm and HAnim wants m. One solution is to
>> simply scale by 0.01 in the user code. As you will probably see when you
>> try to animate the thing lthat the rescale solution was too simple.
>>
>>
>>
>> But wait, I didn't forehead slaps when I said just move the decimal point
>> instead of multiplying by 0.01 (to get m from cm). Recall that in
>> authortime, which is when you want to make the conversion, we have a text
>> file. So, for any case, moving the decimal point using a text editor in
>> authortime is more accurate in terms of representing the author's intent,
>> than multiply by 0.01 in runtime.
>>
>>
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: John Carlson <yottzumm at gmail.com>
>> Sent: Oct 13, 2023 6:17 PM
>> To: Joe D Williams <joedwil at earthlink.net>
>> Cc: GPU Group <gpugroup at gmail.com>, X3D Graphics public mailing list <
>> x3d-public at web3d.org>
>> Subject: Re: [x3d-public] Units for BVH vs HAnimMotion.values
>>
>>
>> > Agreed that BVH/HAnimMotion should be converted to Interpolators, hence
>> my plea for shared keys between Interpolators.
>>
>> Don't concern yourself about the repetition. It is what it is. We just
>> have to deal with it.The bch will probably include a key for each video
>> frame since one objective is to not do any interpolation. We are not using
>> it that way because we will always interpolate.
>> The next step to make it usable is to process to remove extra keys and
>> keyvalues. If small frame interval, then probably lots of extra frames when
>> we can interpolate.
>>
>> > Should I look into a single MetadataFloat for all Interpolators keys?
>>
>> No because the right way, without a script is to justeliminate unneeded
>> keys andkeyvalues.
>> Maybe a different project task than getting Grampsrunning.
>>
>> > Programming a script that won't work in view3dscene?
>>
>> Not a real help now.
>>
>> > Mot Using a PROTO that may not work across all Interpolator node
>> types?  Doing a PROTO per Interpolator type and animation sequence?  How
>> many ProtoInstances do you want to see in your animation code?  Abandoning
>> HAnimMotion as unworkable seems reasonable, except for bloat.
>>
>> Just don't worry about that bloat for now.
>>
>> Joe
>>
>> On Fri, Oct 13, 2023 at 7:07 PM Joe D Williams <joedwil at earthlink.net>
>> wrote:
>>
>>> > Apparently BVH uses degrees for rotations.
>>>
>>>
>>>
>>> It is not specified. There is no spec. Degrees do not appear in any x3d
>>> user code, or any where else except these too simple to use directly random
>>> examples in random bvh archives, or defult spitout of some glorified
>>> animation tool. char. Literally any animation tool worth having does not do
>>> them in terms of degrees, junk coding. If tool cannot export quaternions or
>>> axis-angle it is not worth using. And just because the helpdesk doesn't
>>> know about it doesn't mean they don't have it.
>>>
>>>
>>>
>>> The conversion from typical bvh to axis-angle is in Part 2.
>>>
>>> Just do the conversion and don't worry about using angles anymore. There
>>> is no standard way to interpolate angles, and for good reason.
>>>
>>>
>>>
>>> A bvh file is NOT x3d user code, it is just a partially documented
>>> importation that may be adapted for use with x3d HAnim. This is true no
>>> matter if it comes from some instructor-student archive somewhere on the
>>> web, or hot off the press to represent some current character animation
>>> tool generated keyframes. Even if pretty-printed with x3d it is not x3d.
>>>
>>>
>>>
>>> Just convert the stuff and apply to skeleton. Don't deal with the angles
>>> bs except to convert it to x3d interpolators. It is just an import format,
>>> not standard, and not x3d.
>>>
>>>
>>>
>>> Just convert for most fun,
>>>
>>> Joe
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: GPU Group <gpugroup at gmail.com>
>>> Sent: Oct 13, 2023 12:48 PM
>>> To: John Carlson <yottzumm at gmail.com>
>>> Cc: X3D Graphics public mailing list <x3d-public at web3d.org>
>>> Subject: Re: [x3d-public] Units for BVH vs HAnimMotion.values
>>>
>>>
>>> I have the same question and posted it on h-anim. Might help to have
>>> some options and analysis of the options.
>>>
>> 1. Units statement
>>> Analysis: that would apply to all rotations in the file, including other
>>> scenery Transform rotations which is awkward for most workflows
>>> 2. Motion.values in radians by default
>>> Analysis: will break some scene example data such as HAnim Annex D
>>> Motion.values which is in degrees
>>> - would need to update Annex D
>>> 3. Motion.values in radians by default, and browsers can support degrees
>>> with a field
>>> Motion {
>>> SFString [] angleUnits 'RADIANS' ['RADIANS', 'DEGREES']
>>> //or
>>> SFBool [] angleUnitsDegrees FALSE
>>> }
>>> Analysis: would still break the Annex D example which doesn't show any
>>> Motion field for angle units, and would need to update the specification
>>> for Motion to include an additional field.
>>> 4. export in degrees, and put an export option on the export option
>>> panel for Motion data in [degrees, radians] so browsers will still work
>>> either way until a more permanent solution such as 2 or 3.
>>> Q. how many web3d browsers have implemented HAnimMotion and angle units
>>> did you use for Motion.values ?
>>> -Doug
>>>
>>> On Fri, Oct 13, 2023 at 12:44 PM John Carlson <yottzumm at gmail.com>
>>> wrote:
>>>
>>>> Apparently BVH uses degrees for rotations.  Units for HAnimMotion
>>>> should use radians unless otherwise specified in a UNIT statement, AFAIK.
>>>>
>>>> Comments?
>>>>
>>>> Thanks!
>>>>
>>>> John
>>>> _______________________________________________
>>>> x3d-public mailing list
>>>> x3d-public at web3d.org
>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>>
>>>
>>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20231014/537ae2bb/attachment.html>