[x3d-public] Anchor target within scene: code example, numerous references
Brutzman, Donald (Don) (CIV)
brutzman at nps.edu
Mon Jan 28 13:49:12 PST 2019
OK for something like that:
a. trigger node on menu-selection geometry, e.g. TouchSensor,
b. ROUTE isActive event to particular Script method for a given selection,
c. Script creates a url linking directly to model of interest (or url for indirectly loading via query for model),
d. ROUTE new url to Inline in display case.
e. Server provides model of interest,
f. Inline displays model user has requested.
Given the precise nature of URLs, a catalog of selections should likely be carefully constructed via Script (or scripted url queries) rather than scattered throughout scene content.
Alternative: have multiple url addresses prestaged in multiple Inline nodes, then make sure to only activate one for loading at a time. They could all be coincident under that showcase-display Transform. There is no way to blanket-address all of the Inline's off, but there is a way to only select one at a time using Switch. This kind of alternative does avoid Script since the url information is placed elsewhere.
So once again, strong typing in X3D tends to narrow down how you might tackle any given problem but creativity can still loom large when figuring out just how to create a good domino chain of event activity.
And further, if autogenerating X3D beforehand, you don't have to worry about tedious constructs (in fact they might be preferred). 8)
On 1/28/2019 9:36 AM, Albert Jan Wonnink wrote:
> Hi Don,
>
> I actually meant an example where models are loaded from the server at a specified location in the existing scene only after a user 'clicks' a button. To establish whether or not this feature is supported by the current X3D specification, I think it would be best to have an example without JavaScript, because in the end everything can be implement that way (as popular libraries like Treejs and Babylon show).
> Another discussion of course is whether or not some logic should be defined by the meta language or not. I am sure there must already be some general X3D rules about that.
>
> Regards,
>
> Albert Jan
>
>
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> *Van:* Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
> *Verzonden:* maandag 28 januari 2019 07:09
> *Aan:* Albert Jan Wonnink
> *CC:* x3d-public at web3d.org; Nicholas Polys
> *Onderwerp:* Re: [x3d-public] Anchor target within scene: code example, numerous references
> On 1/27/2019 4:25 AM, Albert Jan Wonnink wrote:
>> Hi Don,
>>
>> I am a bit worried about you mentioning "sometimes DEF of models first then USE inside the Switch can help ".
>
> don't worry, that was a general comment and not about your cases.
>
>> 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.
>
> For something like that, then easiest is to have each selection connected to a different inputOnly method in a Script node, which outputs an MFString url address to the Inline node in the showcase section, then loads a new model.
>
> Other variations might be possible but for sophisticated/precise text url updates you likely want a Script node.
>
>> Do you have a sample scene in X3D that demonstrates how this can be done? That would be very helpful.
>
> Here is something different, a BackgroundSequencer, with an adaptable approach. If you had an array of Strings in a Script, you could not only select them via index but you could also have next/previous/cycle functionality.
>
> http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter11LightingEnvironmentalEffects/BackgroundSequencerIndex.html
>
> btw this scene had some mistaken references within the Script code, now fixed.
>
> As you can see in a problem like this, there are many user/client/server/data issues to consider to best tradeoffs.
>
> Have fun with X3D! 8)
>
>
>> 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
>
>
> 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
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
More information about the x3d-public
mailing list