timesensor fraction always starts at 0.

[splace]

time seems to be since world loaded, not since begin 1970. (same in x-ite.)

[create3000]

Please can you give an example under which circumstances this behavior occurs.

[splace]

i see, i had thought that maybe you had done this by choice, i will now assume you haven't and will investigate and produce a proper report.

FYI the problem world is an animated clock that shows correct time in view3dscene but midnight in tinania/x-ite.

[create3000]

I have, i have created a test file which does essentially this:

function set_touchTime (value, time)
{
	print (Date .now () / 1000);
	print (value);
	print (time);
}

And all three lines show the same time.

[splace]

i am just now looking into this, it is not time itself, it is the timesensor fraction, it always starts at 0.0, even when the time since starttime is not a multiple of interval.

reading the spec., i think it needs to start at an intermediate fraction in this case, although the diagram shown at the bottom implies it does always start at zero?

BTW the clock also works correctly in all the 'old' browsers.

[create3000]

A possible problem could be that you rely on a specific value of the fraction_changed event: for instance:

function set_fraction (value, time)
{
  if (value === 0)
    ...
}

It cannot be guarantied that the fraction value has a specific value on every cycle, even if the value is 0.

[splace]

the clock world has no code, it just routes fraction to interpolator. (see below)

also, i watched live fraction changes and they always start at zero not part-way when the real time indicates.

example: explanation; the timesensor has an interval roughly twice the current 'epoch' (about twice the number of seconds since 1970), so the fraction should currently be about 0.5 (and changing only very slowly) and this should result in the cone being upside-down, this is the result in other browsers, in titania and x-ite it is still upright.

<X3D profile='Interchange' version='3.3' >
  <Scene>
    <TimeSensor DEF='ts1'
        cycleInterval='3100000000'
        loop='true'/>
    <OrientationInterpolator DEF='Orientation'
        key='0, 0.3, 0.7, 1'
        keyValue='0 0 1 0, 0 0 1 1.885, 0 0 1 4.398, 0 0 1 0'/>
     <Transform DEF='Cone'>
        <Shape>
          <Appearance>
            <Material/>
          </Appearance>
          <Cone/>
        </Shape>
      </Transform>
    <ROUTE fromNode='Orientation' fromField='value_changed' toNode='Cone' toField='set_rotation'/>
    <ROUTE fromNode='ts1' fromField='fraction_changed' toNode='Orientation' toField='set_fraction'/>
  </Scene>
</X3D>

[create3000]

Can you provide the hole clock world code with a description or screenshot what should be displayed if it is not the code above, otherwise a screenshot only.

[create3000]

A test implementation shows the peak of the cone bottom down .

[create3000]

The cycleInterval is 3100000000 Seconds, which is almost a whole year in Seconds. A half year has gone. Thus the cone should be bottom down, as far as I know.

[create3000]

The fraction is now calculated with respect to startTime. If loop is true and startTime is 0 you could create a clock now, is this right? If startTime is other than 0 then this value is used, and you could turn the clock back or forth.

[create3000]

clock.zip
Created a clock test world, which should show the current UTC time.

[splace]

A test implementation shows the peak of the cone bottom down .

i have just rechecked, and can not get that output in eiither x-ite or Titania....

[splace]

Created a clock test world, which should show the current UTC time.

in Titania still starting at zero....

but world is correct, as shown in view3dscene...

[splace]

The cycleInterval is 3100000000 Seconds, which is almost a whole year in Seconds. A half year has gone.

(so many zeros) that is actually about 100years, i used this because we are currently about 50 years from the start of the epoch (1970) so the fraction should start at about 0.5 AND be in the first cycle.

[create3000]

The implementation is not published yet, I have done it just today. I want to ask you, if I am right before I release a new version.

[splace]

The fraction is now calculated with respect to startTime. If loop is true and startTime is 0 you could create a clock now, is this right? If startTime is other than 0 then this value is used, and you could turn the clock back or forth.

my understanding is that the fraction is calculated from the time since 1970 modulo the cycleinterval, the startTime/endTime only effects when the events are generated NOT their value. (zero endTime is special cased to mean infinity in the future.)

this means anything driven by (vrml2) timeSensors are in sync in all worlds (as long as the clocks are right.) i think this is intended for ease of networking multiuser worlds.

but... the pausing etc. parameters, (added in X3D) then do allow for non-synchronous stuff, but if you restrict yourself to vrml2 then the synchronous/deterministic behaviour has some nice features.

[splace]

The implementation is not published yet, I have done it just today. I want to ask you, if I am right before I release a new version.

see cross-post

[splace]

FYI Kambi (castle game engine) seems not to be a fan of this behaviour.

https://castle-engine.io/x3d_time_origin_considered_uncomfortable.php

[splace]

also.

having an (outside/beyond the standard?) option to set the time to non real-time, https://castle-engine.io/x3d_implementation_time.php seems to me to be perfectly reasonable, although the new x3d parameters probably allow you to do anything, there are still old worlds to consider. i remember Russian space events worlds that were in absolute time so without the ability to change to non real-time and in a standard complaint browser they are actually never viewable!

it used to be a thing, in vrml2, to use a script to generate a time event when the world was loaded, to get something to start on load, much time was wasted by people assuming it must be possible without a 'hack'.

[create3000]

My intention is to be 100 % standard compliant. Thus if it is right that the TimeSensor generates fractions with respect to startTime, I will implement this, regardless of my opinion. I will not make some strange experiments with time. I'm gonna implement this behaviour today in X_ITE and will let you know, how you can test it.

[create3000]

There is now an ALPHA version for X_ITE available with the changes applied:

<link rel="stylesheet" type="text/css" href="https://code.create3000.de/x_ite/alpha/dist/x_ite.css"/>
<script type="text/javascript" src="https://code.create3000.de/x_ite/alpha/dist/x_ite.min.js"></script>

Created a HTML page with the clock example, which you can test.

Clock.zip

[splace]

all examples, given here previously, working.

and i can't see this needs much testing, its either one way or the other.

but.....for clarity in any documentation

Thus if it is right that the TimeSensor generates fractions with respect to startTime, I will implement this,

for me what you original had WAS 'fractions with respect to startTime' (so always 0 at startTime) what was needed i would call 'fractions with respect to zero time'.

i realised late last night what i say above is for the faulty examples only, where startTime is 0 anyway, and will not work for the already working cases, so yes 'fractions with respect to startTime' even when the start time is at the default of 1/1/1970.

[splace]

in defence of the standard

i think that by having all timesensor fractions, and so animations, all operate with respect to the same point in time, really helps keep things simple when you try to build bigger worlds. the whole world behaves like interconnected clockwork.

but....

it would probably have been significantly better to have had two types of time generating node, this one and another more basic one.

[splace]

My intention is to be 100 % standard compliant.

i saw that originally on the website, its something of a task, kudos.

[splace]

using latest Titania flatpak, above issue is fixed.