[x3d-public] IntegerTrigger [was: BooleanToggle output]

[Andreas Plesch]

On Sep 25, 2017 9:17 AM, "Don Brutzman" <brutzman at nps.edu> wrote:

[levels of indentation in reply not being honored by mailer, hopefully
transcribed here OK.  focused on your recent reply prose.]


I am having trouble with the Android mail client which has its own ideas
about mail style indenting.


On 9/24/2017 8:14 AM, Andreas Plesch wrote:

>
> http://x3dom-integertrigger.glitch.me/IntegerTrigger_test.x3d has now a
> way to test set_boolean false:
> Clicking on the left cone starts a timer which switches left text off
> right away and after 2 seconds. So one can click on the right cone to
> switch left text back on and see if it is switched off after 2 seconds. It
> is, for all browsers I tested.
>
> Octaga, view3dscene and x_ite all trigger on set_boolean false.
>

it looks like it did the same in InstantReality, though timing seemed
immediate.


It is an awkward test. I wanted to avoid any other event utility node and
also the script node, so this was the only scene I could come up with.


these are helpful tests but it is certainly a challenge to sleuth how well
different players conform.


Apart from avoiding backwards incompatible changes, there are other
> arguments but overall I agree restricting triggering to 'True' input adds
> simplicity and clarity. I do think such would need to be considered as a
> backwards incompatible change.
>
> I would probably prefer to avoid confusion between spec. language and tool
> tip language, meaning marking the set_boolean true explanations in the tool
> tips somehow.
>

Very good.  Have amended hint in tooltips.


"Hint: input event set_boolean false has no effect."

to

"Hint: for logical consistency, input event set_boolean false has no effect
(under review as part of Mantis issue 519)."


Well, currently it has an effect. So a reader may conclude that the review
is about having no effect and was already resolved to change to having an
effect.
Perhaps:
"Hint: for logical consistency, input event set_boolean false  is under
review as part of Mantis issue 519 targeting such an event to have no
effect." ?



In terms of an IntegerTrigger node for x3dom, there just needs to be a
> decision. I lean towards being compatible with other browsers and a
> straight interpretation of the current spec. language. There also could be
> a IntegerTrueTrigger to enable use of the new behaviour.
>

Throughout this effort let's decide on simplest and most consistent
approach with honoring 'true' events only.  Specification process can
review and confirm.


[now manually reconstructing email-thread levels, hopefully OK]


        Looking into TimeTrigger next.
>>>
>>
>>     same as point (2), only honoring true events for simplicity and
>> logical clarity.
>>
>
> Agreed in general. Likely browsers currently also honor false events but
> will test.
>

OK, great let's keep converging on best answer.  As before, reacting to
false events is logically confusing and makes design/debugging quite
convoluted.


    Feels like we got another step closer, thanks...
>>
>>     Once we have all this distilled in Mantis issue capturing best-effort
>> prose, it will hopefully be straightforward to confirm resolution.
>>
>
> I do not have a sense of how widely the event utilities are used, eg. what
> the impact of such a resolution would be. I think it would be a positive
> change but a change nonetheless recognizing that this is the behaviour as
> it was originally intended.
>

Well, "originally intended" is a bit strong!  Correctness and usefulness
was always intended, functional design of these nodes has just turned out
to be more subtle than expected.  I think the original ambiguities in spec
prose reflect a lack of clarity that continued practice has helped us to
understand.


I think a source of ambiguity is that Boolean can be considered as a
logical true/false decision but also simply as neutral two state container
bit 0/1, flip/flop.

Treated as a state, it may be valuable to trigger whenever the state is
affected by an action.

But overall, I agree, that triggering only on true is simplest. Triggering
also on false then could be accomplished by a toggle.

But now I may want to know more about the original design strategy. I
suspect it was based on how to get TouchSensor work with Switch in an easy
way ?

Here is another thought. In a scene, can IntegerTrigger be substituted by a
single keyvalued IntegerSequencer using the next field which explicitly
ignores false input ? I think so. It probably still makes sense to have it
for scene readability and optimized implementation.


Getting the event utility functional descriptions distilled to the most
concise, coherent and consistent approach will help animation correctness
and meet the original intent of this component.  Ignoring set_boolean false
events definitely helps.


Yes, it does. I do think browsers just follow the spec. It may be almost
trivial to implement the new behavior for any browser perhaps making it
even conditional on the x3d version declared for the scene. But it requires
new releases and will take time.


Again thanks for your efforts together on this design Andreas.


Just following along,

Andreas



all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170925/59d1961f/attachment.html>