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

[Andreas Plesch]

On Mon, Sep 25, 2017 at 7:51 PM, Andreas Plesch <andreasplesch at gmail.com>
wrote:

>
> 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.
>
>
I updated the IntegerTrigger test scene to show a first message on true
input and then a message on false input. The second message would not be
shown if there is no triggering on false.

http://x3dom-integertrigger.glitch.me/IntegerTrigger_test.x3d
http://x3dom-integertrigger.glitch.me/
<http://x3dom-integertrigger.glitch.me/IntegerTrigger_test.x3d>

I tested InstantPlayer, Octaga, BS Contact, x-ite, view3dscene and freeWrl.
All viewers except freeWrl show the second, on false input message. freeWrl
only shows the first message. In view3dscene one has to manually navigate
to the default viewpoint to see the messages.

-Andreas


> 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/brutzma
> n
>
>
>


-- 
Andreas Plesch
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20171007/97d91de6/attachment-0001.html>