[x3d-public] Anchor target within scene: code example, numerous references

Sun Jan 27 15:34:17 PST 2019

➢ I am a bit worried about you mentioning "sometimes DEF of models first then USE inside the Switch can help… 

That is just a minor detail. Probably, to set up you will need to be careful what you choose to USE then see what you can do to minimize number of unique choosers. Right you are that regardless, it should not matter whether the interaction is with stuffs of the users HMD or interaction with stuffs in the Humanoid’s environment. Like when the user is getting selection hints in the HMD then responds using interactions with a scene choice panel touched by finger with more hints and other responses of HMD. 
To me, that is why whatever extension of humanoid-environmental interactions are considered, the HMD or whatever it is called, is another manifestation of some variation of X3D Sensor node, with very specific inputs and outputs, and maybe has to work like a network sensor in ways, but mainly is just another type of sensor that obtains from and transmits to other sensors and scene processing events in real time. 
True, there is no reason that the HMD could not be demonstrated as a device using the ‘external’ SAI, but it will be much more fun and more tunable by keeping the ‘device’ operating ‘internal’ like a native node. I don’t know enough details about what is actually going on but as a user, I want an ‘HMD’ master view but I also want Humanoid model(s) also interacting with the scene to each have one also and we may want to share views.  I mean if you are making a choice, you want to share. 
Hoping to see great demos,
Joe

From: Albert Jan Wonnink
Sent: Sunday, January 27, 2019 4:26 AM
To: Brutzman, Donald (Don) (CIV)
Cc: x3d-public at web3d.org
Subject: Re: [x3d-public] Anchor target within scene: code example,numerous references

Hi Don,

I am a bit worried about you mentioning "sometimes DEF of models first then USE inside the Switch can help ". The casus is about models that are not directly loaded (visible or not) in the main scene, but as a result of a select event from the user. You have to be able to choose between thousands of models if you want to make for example a 3d virtual web shop that can be visited using an HMD. So loading them all within the main scene would not be practical. But maybe that is not what you mean.
Do you have a sample scene in X3D that demonstrates how this can be done? That would be very helpful.

Regards,

Albert Jan

Van: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
Verzonden: zondag 27 januari 2019 06:17
Aan: Albert Jan Wonnink
CC: x3d-public at web3d.org; Nicholas Polys
Onderwerp: Re: [x3d-public] Anchor target within scene: code example, numerous references 

Thanks for your example, apologies for delayed response.  [Back from Korea now]

Appreciate the video you posted earlier, the point is clearer and the functionality looks excellent.

On 1/22/2019 9:54 AM, Albert Jan Wonnink wrote:
> [...] Just to clarify my case once more, I would like to show this scene:
>        
> X3D inline anchor prototype <https://youtu.be/vPLYxkTrxX8>

BTW the Web3D Consortium has a YouTube site that is a good place for posting things like this.  Everyone can feel free to suggest or contribute.

        YouTube; Web3D Consortium Playlists
        https://www.youtube.com/user/Web3DMaster/playlists

> The behavior here is implemented without any client-side scripting, just with a little extended X3D that allows to specify a target of an anchor within the 3D scene.
> The suggested workaround using viewpoints seems complicated for this kind of scenario, but I might be wrong about this.

The X3D pseudocode/snippets also helped provide clarity, thanks for that too.

if i were doing something like this, i would have a set of TouchSensor nodes trigger a corresponding set of IntegerTrigger nodes, for each model of interest, then have each IntegerTrigger output ROUTEd to a single Switch node that then switched to the model of interest.  This is a fairly common design pattern.

This kind of functionality is explained by EventUtilities component.  These nodes allow all manner of strongly typed functionality when creating animation chains.   Please see book chapter/slides for full explanations.  For memory performance, sometimes DEF of models first then USE inside the Switch can help when multiple usages are desired.

I believe that this Event Utilities suggestion matches Joe's suggestion, use the right connections to create an event chain with the functionality needed.  Unless special logic is involved, scripting is then not needed.  Offering reassurance is that there should be a Sequencer, Interpolator or Trigger/Toggle for whatever you want to do.  Note that, since X3D is strictly typed for all event outputs/inputs, more often than not there is only one straightforward way to get a trigger-timer-interpolator-target event chain constructed.

        X3D Example Archives: X3D for Web Authors, Chapter 07 Event Animation Interpolation
        http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter07EventAnimationInterpolation

has additional links:

        X3D for Web Authors, Chapter 07 Event Animation Interpolation, slideset
        http://x3dgraphics.com/slidesets/X3dForWebAuthors/Chapter07EventAnimationInterpolation.pdf

similarly

        X3D Example Archives: X3D for Web Authors, Chapter 08 User Interactivity
        http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter08UserInteractivity

        X3D for Web Authors, Chapter 08 User Interactivity, slideset
        http://x3dgraphics.com/slidesets/X3dForWebAuthors/Chapter08UserInteractivity.pdf

and
        X3D Example Archives: X3D for Web Authors, Chapter 09 Event Utilities Scripting
        http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter09EventUtilitiesScripting

        X3D for Web Authors, Chapter 09 Event Utilities Scripting, slideset
        http://x3dgraphics.com/slidesets/X3dForWebAuthors/Chapter09EventUtilitiesScripting.pdf

Uh, some people like the book too.  8)

The quick-reference sheet X3D Event Utility Nodes: Field Event Diagrams illustrates the functionality of the event utility nodes. These nodes receive and pass values that are sent via ROUTE connections.  Tooltips are further available for type, accessType, and each node with further detail - for example, ROUTE.

        X3D Event Utility Nodes: Field Event Diagrams
        http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter09EventUtilitiesScripting/X3dEventUtilityNodeEventDiagrams.pdf

        X3D Tooltips
        http://www.web3d.org/x3d/content/X3dTooltips.html#ROUTE
        http://www.web3d.org/x3d/content/X3dTooltips.html#accessType
        http://www.web3d.org/x3d/content/X3dTooltips.html#type

There are many similarities between HTML <a> anchor element and X3D Anchor.  However, again as Joe indicated, it is best to understand the differences and similarities first.

        http://www.web3d.org/x3d/content/X3dTooltips.html#Anchor

Essentially, Anchor url address of replacement world, or #ViewpointDEFName within the current Scene, or alternate Web resource, activated by the user selecting Shape geometry within the Anchor children nodes.  The parameter field can be used to carry HTML (frame or tab) target information.

        http://www.web3d.org/x3d/content/X3dTooltips.html#Anchor.url
        http://www.web3d.org/x3d/content/X3dTooltips.html#Anchor.parameter

Good node to compare: TouchSensor, which solely focuses on responding to selection and hovering events.  (Note that there is a little bit of overlap too, since a TouchSense isActive output event could be ROUTEd to another Viewpoint's set_bind input field.)

        http://www.web3d.org/x3d/content/X3dTooltips.html#TouchSensor

Of course all of these other sources are derivative... the authoritative functionality is defined by the X3D Architecture specification.  (Node names in tooltips are linked to that specification's index for that node.)  Links are also provided there to Schema and DTD documentation, which provide detail on what will pass validation tests.

        http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/networking.html#Anchor

        http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/pointingsensor.html#TouchSensor

        http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#Routes

Script nodes allow writing additional functionality.  Prototypes allow making customizable templates.  IMPORT/EXPORT allows sending events into or out of Inline nodes.

So that is all quite a lot.  Please holler if you find something missing - someone will come up with a good idea, or (occasionally) we'll fix a deficiency in the specifications.  All good.

All this semantic rigor and functional detail - courtesy of X3D Working Group and Web3D Community - means that it is possible to create scalable 3D worlds in multiple languages and file encodings, all with equivalent power and equivalent extensibility (the X in X3D).

Thanks for your work.  Have fun with immersive interactive X3D!  8)

On 1/24/2019 10:24 AM, Albert Jan Wonnink wrote:
> Hi Don,
> 
> the code behind the pages could be something like this
> 
> 
> 
> mainPage.x3d:
> 
> <X3D>
> 
>   <Scene>
> 
>   <!--first menu-->
> 
>    <Transform translation="-1 1 3">
> 
>     <!--first item-->
> 
>     <Transform translation="0 0 0">
> 
>      <Anchor url="'menu2_1.x3d'" parameter="'target=menu2'">
> 
>       <Shape …
> 
>      </Anchor>
> 
>   </Transform>
> 
>     <!--second item-->
> 
>     <Transform translation="0 -0.2 0">
> 
>      <Anchor url="'menu2_2.x3d'" parameter="'target=menu2'">
> 
>       <Shape …
> 
>      </Anchor>
> 
>   </Transform>
> 
>    <!--third item-->
> 
> ...
> 
> </Transform>
> 
> <!--position menu2-->
> 
> <Transform translation="0 1 3">
> 
>    <Inline DEF="menu2"></Inline>
> 
> </Transform>
> 
> <!--position models to display-->
> 
> <Transform translation="1 1 3">
> 
>    <Inline DEF="modelsToDisplay"></Inline>
> 
> </Transform>
> 
> </Scene>
> 
> </X3D>
> 
> 
> 
> 
> 
> For each 'submenu' there is a separate file
> 
> menu2_1.x3d( menu2_2.x3d, …)
> 
> <X3D>
> 
>   <Scene>
> 
>   <!--first menu-->
> 
>    <Transform>
> 
>     <!--first item-->
> 
>     <Transform translation="0 0 0">
> 
>      <Anchor url="'model_1.x3d'" parameter="'target=modelsToDisplay'">
> 
>       <Shape …
> 
>      </Anchor>
> 
>   </Transform>
> 
>     <!--second item-->
> 
>     <Transform translation="0 -0.2 0">
> 
>      <Anchor url="'menu2_2.x3d'" parameter="'target=modelsToDisplay'">
> 
>       <Shape …
> 
>      </Anchor>
> 
>   </Transform>
> 
>    <!--third item-->
> 
> ...
> 
> </Transform>
> 
> </Scene>
> 
> </X3D>
> 
> And there are the files that actually contain the models:
> 
> model_1.x3d, model_2.x3d ...
> 
> I think the bottom line is to allow the 'target' parameter not only have the predefined values (_blank, _self etc.) or frame names of the html page, but also allow the names of the inlines as a target.
> 
> Regards,
> 
> Albert Jan

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/20190127/bbe1af8e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 92F16485BE6C42EAACECEA6AE783FDF7.png
Type: image/png
Size: 161 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20190127/bbe1af8e/attachment-0001.png>