From yottzumm at gmail.com Sat Feb 1 01:23:06 2025 From: yottzumm at gmail.com (John Carlson) Date: Sat, 1 Feb 2025 03:23:06 -0600 Subject: [x3d-public] Having a bit of difficult ROUTEing to node outside the ProtoDeclare in Sunrize In-Reply-To: References: Message-ID: Here's another attempt: It works mostly, but Adapter fraction doesn't reset anymore. Still doesn't get rid of scripts. * * -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Sat Feb 1 03:16:29 2025 From: yottzumm at gmail.com (John Carlson) Date: Sat, 1 Feb 2025 05:16:29 -0600 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: Message-ID: Andreas, For extra credit, reset the animation each time a toggle button is pressed. So far, it looks dubious without scripting. Got a reliable solution for resetting the animations? On Wed, Dec 11, 2024 at 3:08?PM Andreas Plesch wrote: > Hi John, group, > > Exploring how far one could get without X3D scripts and only using > event utilities, let me share an example of a panel of individually > controlled toggle buttons which then drive a simple assemblage of > individually animated spheres: > > > https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/6fd2fd0b0f745b3549b74150b7752d89/raw/37f94755f763ecc9a0439a0dab2f32441e8b12aa/toggleButtonExample.x3d > > https://gist.github.com/andreasplesch/6fd2fd0b0f745b3549b74150b7752d89 > > There are two sections, one for the control panel and one for the > controlled assemblage. Each section has a Proto as the main building > block for simple reuse. The toggle button Proto is based on wrapping, > synced Integer and BooleanSequencers for color toggling and outputting > useful events corresponding to the state of the button. This is > probably the most useful and interesting part. Everything else is more > for demonstration. > There is also an animatedBlob Proto which shows how animations might > be controlled by routing events from a toggle button. > The animations all start out in sync after being enabled by a button > but then can be individually paused and resumed for arbitrarily > pulsating patterns. > > Event utilities generally turn out to require verbose declarative > code, compared to logic in scripts but that can be mitigated to a good > extent by Protos which also help with scene structure. > > There is one standard related question which came up for me and I > think that may have been raised before. The question is what the > value_changed should be after a Sequencer receives a first 'next' > event without ever having received a set_fraction or other event. In > this case there is not a next value because there was never any value > in the first place. Both x3dom and x_ite currently output the first > keyValue and set the first key as the current key in this case. > > x_ite and x3dom work almost the same with the example. x_ite > immediately starts the animations where x3dom waits as intended until > the related Timesensors receive a first 'enabled' event. There may be > a simple fix for x_ite use but I could not find it. > > Thanks, -Andreas > > On Sat, Dec 7, 2024 at 4:37?PM John Carlson wrote: > > > > So here?s an interesting question: If I have the same ROUTE in two > different choices in a Switch, is one of them ignored? > > > > Not that I?m going to do that. > > > > I?m probably going to try using a Switch unless someone says that ROUTEs > are always active in a Switch, disagreeing with the AI. > > > > John > > > > On Sat, Dec 7, 2024 at 3:29?PM John Carlson wrote: > >> > >> From X3D4: > >> > >> > >> 4.4.8.2 Routes > >> > >> Routes are not nodes. > >> > >> [snip] > >> > >> Redundant routing is ignored. If an X3D file repeats a routing path, > the second and subsequent identical routes are ignored. This also applies > for routes created dynamically using the X3D SAI. > >> > >> > >> Can someone clarify how statements are affected by Switches? Can I > have different choices of a PROTO inside a Switch? Effectively changing > ProtoBody content at run-time??? > >> > >> John > >> > >> > >> > >> On Sat, Dec 7, 2024 at 2:40?PM John Carlson wrote: > >>> > >>> Would it be possible to put an animation?s ROUTEs in a Switch that > could be toggled on and off with a boolean toggle? > >>> > >>> Google AI says: > >>> > >>> Yes, you can absolutely put "ROUTE" nodes within a "Switch" node in > X3D; in fact, it's a common practice to use them together to dynamically > control which set of connections (via ROUTE) are active depending on which > child node of the Switch is currently selected. > >>> > >>> I didn?t realize that statements were affected by Switch. > >>> > >>> John > >>> > >>> On Sat, Dec 7, 2024 at 1:43?PM John Carlson > wrote: > >>>> > >>>> We are dealing with multiple facial animations. The thing we want to > do is combine animations using HAnimDisplacers. Currently, our animations > go from key = 0 to key = 1, (weight = 0 to weight = 1) and each animation > is controlled by a single TimeSensor that we enable or disable. What we > want to do is enable multiple facial animations, yet retain a single > TimeSensor. I have done something with enabling multiple time sensors all > at the same time. So, ideally, we could toggle each facial animation > individually. > >>>> > >>>> Note that one can have multiple simultaneous HAnimDisplacer > animations on a single Coordinate, they all add up just fine. There?s no > single animation per body part requirement as there is in other places in > X3D (according to Michalis, from my understanding). > >>>> > >>>> I don?t currently know how to individually toggle multiple animations > without toggling multiple TimeSensors, so assistance is welcome! Indeed, a > multiple toggle button X3D example would be welcome (hopefully, something > we can put in a scenegraph). > >>>> > >>>> Here?s what we currently have > >>>> > https://github.com/coderextreme/ci2had/blob/main/resources/SingleMenuJin.x3d > >>>> > >>>> As you can see, lots of duplication. > >>>> > >>>> Viewed best in FreeWRL and Sunrize/X_ITE. > >>>> > >>>> John > > > > -- > Andreas Plesch > Waltham, MA 02453 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreasplesch at gmail.com Sat Feb 1 12:34:25 2025 From: andreasplesch at gmail.com (Andreas Plesch) Date: Sat, 1 Feb 2025 15:34:25 -0500 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: Message-ID: Hi John, https://gist.githubusercontent.com/andreasplesch/6fd2fd0b0f745b3549b74150b7752d89/raw/c02637b602f9241c9ea73b5ad859ab330c071e25/toggleReset.x3d resets the animation everytime it is restarted after stopping. The only change is replacing resumeTime and pauseTime with startTime and stopTime . Instead of a toggle button, it would be possible to have two separate buttons, one for stopping and one for resetting. This may be what you are looking for, -Andreas On Sat, Feb 1, 2025 at 6:16?AM John Carlson wrote: > Andreas, > > For extra credit, reset the animation each time a toggle button is > pressed. So far, it looks dubious without scripting. > > Got a reliable solution for resetting the animations? > > On Wed, Dec 11, 2024 at 3:08?PM Andreas Plesch > wrote: > >> Hi John, group, >> >> Exploring how far one could get without X3D scripts and only using >> event utilities, let me share an example of a panel of individually >> controlled toggle buttons which then drive a simple assemblage of >> individually animated spheres: >> >> >> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/6fd2fd0b0f745b3549b74150b7752d89/raw/37f94755f763ecc9a0439a0dab2f32441e8b12aa/toggleButtonExample.x3d >> >> https://gist.github.com/andreasplesch/6fd2fd0b0f745b3549b74150b7752d89 >> >> There are two sections, one for the control panel and one for the >> controlled assemblage. Each section has a Proto as the main building >> block for simple reuse. The toggle button Proto is based on wrapping, >> synced Integer and BooleanSequencers for color toggling and outputting >> useful events corresponding to the state of the button. This is >> probably the most useful and interesting part. Everything else is more >> for demonstration. >> There is also an animatedBlob Proto which shows how animations might >> be controlled by routing events from a toggle button. >> The animations all start out in sync after being enabled by a button >> but then can be individually paused and resumed for arbitrarily >> pulsating patterns. >> >> Event utilities generally turn out to require verbose declarative >> code, compared to logic in scripts but that can be mitigated to a good >> extent by Protos which also help with scene structure. >> >> There is one standard related question which came up for me and I >> think that may have been raised before. The question is what the >> value_changed should be after a Sequencer receives a first 'next' >> event without ever having received a set_fraction or other event. In >> this case there is not a next value because there was never any value >> in the first place. Both x3dom and x_ite currently output the first >> keyValue and set the first key as the current key in this case. >> >> x_ite and x3dom work almost the same with the example. x_ite >> immediately starts the animations where x3dom waits as intended until >> the related Timesensors receive a first 'enabled' event. There may be >> a simple fix for x_ite use but I could not find it. >> >> Thanks, -Andreas >> >> On Sat, Dec 7, 2024 at 4:37?PM John Carlson wrote: >> > >> > So here?s an interesting question: If I have the same ROUTE in two >> different choices in a Switch, is one of them ignored? >> > >> > Not that I?m going to do that. >> > >> > I?m probably going to try using a Switch unless someone says that >> ROUTEs are always active in a Switch, disagreeing with the AI. >> > >> > John >> > >> > On Sat, Dec 7, 2024 at 3:29?PM John Carlson wrote: >> >> >> >> From X3D4: >> >> >> >> >> >> 4.4.8.2 Routes >> >> >> >> Routes are not nodes. >> >> >> >> [snip] >> >> >> >> Redundant routing is ignored. If an X3D file repeats a routing path, >> the second and subsequent identical routes are ignored. This also applies >> for routes created dynamically using the X3D SAI. >> >> >> >> >> >> Can someone clarify how statements are affected by Switches? Can I >> have different choices of a PROTO inside a Switch? Effectively changing >> ProtoBody content at run-time??? >> >> >> >> John >> >> >> >> >> >> >> >> On Sat, Dec 7, 2024 at 2:40?PM John Carlson >> wrote: >> >>> >> >>> Would it be possible to put an animation?s ROUTEs in a Switch that >> could be toggled on and off with a boolean toggle? >> >>> >> >>> Google AI says: >> >>> >> >>> Yes, you can absolutely put "ROUTE" nodes within a "Switch" node in >> X3D; in fact, it's a common practice to use them together to dynamically >> control which set of connections (via ROUTE) are active depending on which >> child node of the Switch is currently selected. >> >>> >> >>> I didn?t realize that statements were affected by Switch. >> >>> >> >>> John >> >>> >> >>> On Sat, Dec 7, 2024 at 1:43?PM John Carlson >> wrote: >> >>>> >> >>>> We are dealing with multiple facial animations. The thing we want >> to do is combine animations using HAnimDisplacers. Currently, our >> animations go from key = 0 to key = 1, (weight = 0 to weight = 1) and each >> animation is controlled by a single TimeSensor that we enable or disable. >> What we want to do is enable multiple facial animations, yet retain a >> single TimeSensor. I have done something with enabling multiple time >> sensors all at the same time. So, ideally, we could toggle each facial >> animation individually. >> >>>> >> >>>> Note that one can have multiple simultaneous HAnimDisplacer >> animations on a single Coordinate, they all add up just fine. There?s no >> single animation per body part requirement as there is in other places in >> X3D (according to Michalis, from my understanding). >> >>>> >> >>>> I don?t currently know how to individually toggle multiple >> animations without toggling multiple TimeSensors, so assistance is >> welcome! Indeed, a multiple toggle button X3D example would be welcome >> (hopefully, something we can put in a scenegraph). >> >>>> >> >>>> Here?s what we currently have >> >>>> >> https://github.com/coderextreme/ci2had/blob/main/resources/SingleMenuJin.x3d >> >>>> >> >>>> As you can see, lots of duplication. >> >>>> >> >>>> Viewed best in FreeWRL and Sunrize/X_ITE. >> >>>> >> >>>> John >> >> >> >> -- >> Andreas Plesch >> Waltham, MA 02453 >> > -- Andreas Plesch Waltham, MA 02453 -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Sat Feb 1 13:09:07 2025 From: yottzumm at gmail.com (John Carlson) Date: Sat, 1 Feb 2025 15:09:07 -0600 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: Message-ID: Weird. I used startTime and stopTime, but my animation doesn?t reset. Should I add pauseTime and resumeTime? https://create3000.github.io/x_ite/playground/?url= https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d I will investigate yours some more. On Sat, Feb 1, 2025 at 2:35?PM Andreas Plesch wrote: > Hi John, > > > https://gist.githubusercontent.com/andreasplesch/6fd2fd0b0f745b3549b74150b7752d89/raw/c02637b602f9241c9ea73b5ad859ab330c071e25/toggleReset.x3d > > resets the animation everytime it is restarted after stopping. > > The only change is replacing resumeTime and pauseTime with startTime and > stopTime . > Instead of a toggle button, it would be possible to have two separate > buttons, one for stopping and one for resetting. > > This may be what you are looking for, -Andreas > > On Sat, Feb 1, 2025 at 6:16?AM John Carlson wrote: > >> Andreas, >> >> For extra credit, reset the animation each time a toggle button is >> pressed. So far, it looks dubious without scripting. >> >> Got a reliable solution for resetting the animations? >> >> On Wed, Dec 11, 2024 at 3:08?PM Andreas Plesch >> wrote: >> >>> Hi John, group, >>> >>> Exploring how far one could get without X3D scripts and only using >>> event utilities, let me share an example of a panel of individually >>> controlled toggle buttons which then drive a simple assemblage of >>> individually animated spheres: >>> >>> >>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/6fd2fd0b0f745b3549b74150b7752d89/raw/37f94755f763ecc9a0439a0dab2f32441e8b12aa/toggleButtonExample.x3d >>> >>> https://gist.github.com/andreasplesch/6fd2fd0b0f745b3549b74150b7752d89 >>> >>> There are two sections, one for the control panel and one for the >>> controlled assemblage. Each section has a Proto as the main building >>> block for simple reuse. The toggle button Proto is based on wrapping, >>> synced Integer and BooleanSequencers for color toggling and outputting >>> useful events corresponding to the state of the button. This is >>> probably the most useful and interesting part. Everything else is more >>> for demonstration. >>> There is also an animatedBlob Proto which shows how animations might >>> be controlled by routing events from a toggle button. >>> The animations all start out in sync after being enabled by a button >>> but then can be individually paused and resumed for arbitrarily >>> pulsating patterns. >>> >>> Event utilities generally turn out to require verbose declarative >>> code, compared to logic in scripts but that can be mitigated to a good >>> extent by Protos which also help with scene structure. >>> >>> There is one standard related question which came up for me and I >>> think that may have been raised before. The question is what the >>> value_changed should be after a Sequencer receives a first 'next' >>> event without ever having received a set_fraction or other event. In >>> this case there is not a next value because there was never any value >>> in the first place. Both x3dom and x_ite currently output the first >>> keyValue and set the first key as the current key in this case. >>> >>> x_ite and x3dom work almost the same with the example. x_ite >>> immediately starts the animations where x3dom waits as intended until >>> the related Timesensors receive a first 'enabled' event. There may be >>> a simple fix for x_ite use but I could not find it. >>> >>> Thanks, -Andreas >>> >>> On Sat, Dec 7, 2024 at 4:37?PM John Carlson wrote: >>> > >>> > So here?s an interesting question: If I have the same ROUTE in two >>> different choices in a Switch, is one of them ignored? >>> > >>> > Not that I?m going to do that. >>> > >>> > I?m probably going to try using a Switch unless someone says that >>> ROUTEs are always active in a Switch, disagreeing with the AI. >>> > >>> > John >>> > >>> > On Sat, Dec 7, 2024 at 3:29?PM John Carlson >>> wrote: >>> >> >>> >> From X3D4: >>> >> >>> >> >>> >> 4.4.8.2 Routes >>> >> >>> >> Routes are not nodes. >>> >> >>> >> [snip] >>> >> >>> >> Redundant routing is ignored. If an X3D file repeats a routing path, >>> the second and subsequent identical routes are ignored. This also applies >>> for routes created dynamically using the X3D SAI. >>> >> >>> >> >>> >> Can someone clarify how statements are affected by Switches? Can I >>> have different choices of a PROTO inside a Switch? Effectively changing >>> ProtoBody content at run-time??? >>> >> >>> >> John >>> >> >>> >> >>> >> >>> >> On Sat, Dec 7, 2024 at 2:40?PM John Carlson >>> wrote: >>> >>> >>> >>> Would it be possible to put an animation?s ROUTEs in a Switch that >>> could be toggled on and off with a boolean toggle? >>> >>> >>> >>> Google AI says: >>> >>> >>> >>> Yes, you can absolutely put "ROUTE" nodes within a "Switch" node in >>> X3D; in fact, it's a common practice to use them together to dynamically >>> control which set of connections (via ROUTE) are active depending on which >>> child node of the Switch is currently selected. >>> >>> >>> >>> I didn?t realize that statements were affected by Switch. >>> >>> >>> >>> John >>> >>> >>> >>> On Sat, Dec 7, 2024 at 1:43?PM John Carlson >>> wrote: >>> >>>> >>> >>>> We are dealing with multiple facial animations. The thing we want >>> to do is combine animations using HAnimDisplacers. Currently, our >>> animations go from key = 0 to key = 1, (weight = 0 to weight = 1) and each >>> animation is controlled by a single TimeSensor that we enable or disable. >>> What we want to do is enable multiple facial animations, yet retain a >>> single TimeSensor. I have done something with enabling multiple time >>> sensors all at the same time. So, ideally, we could toggle each facial >>> animation individually. >>> >>>> >>> >>>> Note that one can have multiple simultaneous HAnimDisplacer >>> animations on a single Coordinate, they all add up just fine. There?s no >>> single animation per body part requirement as there is in other places in >>> X3D (according to Michalis, from my understanding). >>> >>>> >>> >>>> I don?t currently know how to individually toggle multiple >>> animations without toggling multiple TimeSensors, so assistance is >>> welcome! Indeed, a multiple toggle button X3D example would be welcome >>> (hopefully, something we can put in a scenegraph). >>> >>>> >>> >>>> Here?s what we currently have >>> >>>> >>> https://github.com/coderextreme/ci2had/blob/main/resources/SingleMenuJin.x3d >>> >>>> >>> >>>> As you can see, lots of duplication. >>> >>>> >>> >>>> Viewed best in FreeWRL and Sunrize/X_ITE. >>> >>>> >>> >>>> John >>> >>> >>> >>> -- >>> Andreas Plesch >>> Waltham, MA 02453 >>> >> > > -- > Andreas Plesch > Waltham, MA 02453 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Sat Feb 1 13:35:44 2025 From: yottzumm at gmail.com (John Carlson) Date: Sat, 1 Feb 2025 15:35:44 -0600 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: Message-ID: I'm trying very hard to look at this, but I'm not seeing the animation reset when one turns an animation off. Perhaps I should try X3DOM? https://create3000.github.io/x_ite/playground/?url=https://gist.githubusercontent.com/andreasplesch/6fd2fd0b0f745b3549b74150b7752d89/raw/c02637b602f9241c9ea73b5ad859ab330c071e25/toggleReset.x3d Trying to compare with: https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/6fd2fd0b0f745b3549b74150b7752d89/raw/c02637b602f9241c9ea73b5ad859ab330c071e25/toggleReset.x3d If I click multiple checkboxes, AFAICT, the whole animation doesn't reset. I want ALL animations to reset when a button is pressed in, and when any button is unpressed. This is a better link for mine: https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d So probably there needs to be a global start/stop time for all enabled TimeSensors? I see you have two ProtoDeclares and I only have one. I might be able to do something like that. Hmm! John On Sat, Feb 1, 2025 at 2:35?PM Andreas Plesch wrote: > Hi John, > > > https://gist.githubusercontent.com/andreasplesch/6fd2fd0b0f745b3549b74150b7752d89/raw/c02637b602f9241c9ea73b5ad859ab330c071e25/toggleReset.x3d > > resets the animation everytime it is restarted after stopping. > > The only change is replacing resumeTime and pauseTime with startTime and > stopTime . > Instead of a toggle button, it would be possible to have two separate > buttons, one for stopping and one for resetting. > > This may be what you are looking for, -Andreas > > On Sat, Feb 1, 2025 at 6:16?AM John Carlson wrote: > >> Andreas, >> >> For extra credit, reset the animation each time a toggle button is >> pressed. So far, it looks dubious without scripting. >> >> Got a reliable solution for resetting the animations? >> >> On Wed, Dec 11, 2024 at 3:08?PM Andreas Plesch >> wrote: >> >>> Hi John, group, >>> >>> Exploring how far one could get without X3D scripts and only using >>> event utilities, let me share an example of a panel of individually >>> controlled toggle buttons which then drive a simple assemblage of >>> individually animated spheres: >>> >>> >>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/6fd2fd0b0f745b3549b74150b7752d89/raw/37f94755f763ecc9a0439a0dab2f32441e8b12aa/toggleButtonExample.x3d >>> >>> https://gist.github.com/andreasplesch/6fd2fd0b0f745b3549b74150b7752d89 >>> >>> There are two sections, one for the control panel and one for the >>> controlled assemblage. Each section has a Proto as the main building >>> block for simple reuse. The toggle button Proto is based on wrapping, >>> synced Integer and BooleanSequencers for color toggling and outputting >>> useful events corresponding to the state of the button. This is >>> probably the most useful and interesting part. Everything else is more >>> for demonstration. >>> There is also an animatedBlob Proto which shows how animations might >>> be controlled by routing events from a toggle button. >>> The animations all start out in sync after being enabled by a button >>> but then can be individually paused and resumed for arbitrarily >>> pulsating patterns. >>> >>> Event utilities generally turn out to require verbose declarative >>> code, compared to logic in scripts but that can be mitigated to a good >>> extent by Protos which also help with scene structure. >>> >>> There is one standard related question which came up for me and I >>> think that may have been raised before. The question is what the >>> value_changed should be after a Sequencer receives a first 'next' >>> event without ever having received a set_fraction or other event. In >>> this case there is not a next value because there was never any value >>> in the first place. Both x3dom and x_ite currently output the first >>> keyValue and set the first key as the current key in this case. >>> >>> x_ite and x3dom work almost the same with the example. x_ite >>> immediately starts the animations where x3dom waits as intended until >>> the related Timesensors receive a first 'enabled' event. There may be >>> a simple fix for x_ite use but I could not find it. >>> >>> Thanks, -Andreas >>> >>> On Sat, Dec 7, 2024 at 4:37?PM John Carlson wrote: >>> > >>> > So here?s an interesting question: If I have the same ROUTE in two >>> different choices in a Switch, is one of them ignored? >>> > >>> > Not that I?m going to do that. >>> > >>> > I?m probably going to try using a Switch unless someone says that >>> ROUTEs are always active in a Switch, disagreeing with the AI. >>> > >>> > John >>> > >>> > On Sat, Dec 7, 2024 at 3:29?PM John Carlson >>> wrote: >>> >> >>> >> From X3D4: >>> >> >>> >> >>> >> 4.4.8.2 Routes >>> >> >>> >> Routes are not nodes. >>> >> >>> >> [snip] >>> >> >>> >> Redundant routing is ignored. If an X3D file repeats a routing path, >>> the second and subsequent identical routes are ignored. This also applies >>> for routes created dynamically using the X3D SAI. >>> >> >>> >> >>> >> Can someone clarify how statements are affected by Switches? Can I >>> have different choices of a PROTO inside a Switch? Effectively changing >>> ProtoBody content at run-time??? >>> >> >>> >> John >>> >> >>> >> >>> >> >>> >> On Sat, Dec 7, 2024 at 2:40?PM John Carlson >>> wrote: >>> >>> >>> >>> Would it be possible to put an animation?s ROUTEs in a Switch that >>> could be toggled on and off with a boolean toggle? >>> >>> >>> >>> Google AI says: >>> >>> >>> >>> Yes, you can absolutely put "ROUTE" nodes within a "Switch" node in >>> X3D; in fact, it's a common practice to use them together to dynamically >>> control which set of connections (via ROUTE) are active depending on which >>> child node of the Switch is currently selected. >>> >>> >>> >>> I didn?t realize that statements were affected by Switch. >>> >>> >>> >>> John >>> >>> >>> >>> On Sat, Dec 7, 2024 at 1:43?PM John Carlson >>> wrote: >>> >>>> >>> >>>> We are dealing with multiple facial animations. The thing we want >>> to do is combine animations using HAnimDisplacers. Currently, our >>> animations go from key = 0 to key = 1, (weight = 0 to weight = 1) and each >>> animation is controlled by a single TimeSensor that we enable or disable. >>> What we want to do is enable multiple facial animations, yet retain a >>> single TimeSensor. I have done something with enabling multiple time >>> sensors all at the same time. So, ideally, we could toggle each facial >>> animation individually. >>> >>>> >>> >>>> Note that one can have multiple simultaneous HAnimDisplacer >>> animations on a single Coordinate, they all add up just fine. There?s no >>> single animation per body part requirement as there is in other places in >>> X3D (according to Michalis, from my understanding). >>> >>>> >>> >>>> I don?t currently know how to individually toggle multiple >>> animations without toggling multiple TimeSensors, so assistance is >>> welcome! Indeed, a multiple toggle button X3D example would be welcome >>> (hopefully, something we can put in a scenegraph). >>> >>>> >>> >>>> Here?s what we currently have >>> >>>> >>> https://github.com/coderextreme/ci2had/blob/main/resources/SingleMenuJin.x3d >>> >>>> >>> >>>> As you can see, lots of duplication. >>> >>>> >>> >>>> Viewed best in FreeWRL and Sunrize/X_ITE. >>> >>>> >>> >>>> John >>> >>> >>> >>> -- >>> Andreas Plesch >>> Waltham, MA 02453 >>> >> > > -- > Andreas Plesch > Waltham, MA 02453 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreasplesch at gmail.com Sat Feb 1 15:55:19 2025 From: andreasplesch at gmail.com (Andreas Plesch) Date: Sat, 1 Feb 2025 18:55:19 -0500 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: Message-ID: Both x-ite and x3dom behave the same. Each animation is independent and resets individually after it is stopped and then restarted. It seems you aim for another behaviour with some dependency between animations. -Andreas On Sat, Feb 1, 2025 at 4:35?PM John Carlson wrote: > I'm trying very hard to look at this, but I'm not seeing the animation > reset when one turns an animation off. Perhaps I should try X3DOM? > > > https://create3000.github.io/x_ite/playground/?url=https://gist.githubusercontent.com/andreasplesch/6fd2fd0b0f745b3549b74150b7752d89/raw/c02637b602f9241c9ea73b5ad859ab330c071e25/toggleReset.x3d > > Trying to compare with: > > https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/6fd2fd0b0f745b3549b74150b7752d89/raw/c02637b602f9241c9ea73b5ad859ab330c071e25/toggleReset.x3d > > > If I click multiple checkboxes, AFAICT, the whole animation doesn't > reset. I want ALL animations to reset when a button is pressed in, and > when any button is unpressed. > > This is a better link for mine: > > > https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d > > So probably there needs to be a global start/stop time for all enabled > TimeSensors? > > I see you have two ProtoDeclares and I only have one. I might be able to > do something like that. > > Hmm! > > John > > > On Sat, Feb 1, 2025 at 2:35?PM Andreas Plesch > wrote: > >> Hi John, >> >> >> https://gist.githubusercontent.com/andreasplesch/6fd2fd0b0f745b3549b74150b7752d89/raw/c02637b602f9241c9ea73b5ad859ab330c071e25/toggleReset.x3d >> >> resets the animation everytime it is restarted after stopping. >> >> The only change is replacing resumeTime and pauseTime with startTime and >> stopTime . >> Instead of a toggle button, it would be possible to have two separate >> buttons, one for stopping and one for resetting. >> >> This may be what you are looking for, -Andreas >> >> On Sat, Feb 1, 2025 at 6:16?AM John Carlson wrote: >> >>> Andreas, >>> >>> For extra credit, reset the animation each time a toggle button is >>> pressed. So far, it looks dubious without scripting. >>> >>> Got a reliable solution for resetting the animations? >>> >>> On Wed, Dec 11, 2024 at 3:08?PM Andreas Plesch >>> wrote: >>> >>>> Hi John, group, >>>> >>>> Exploring how far one could get without X3D scripts and only using >>>> event utilities, let me share an example of a panel of individually >>>> controlled toggle buttons which then drive a simple assemblage of >>>> individually animated spheres: >>>> >>>> >>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/6fd2fd0b0f745b3549b74150b7752d89/raw/37f94755f763ecc9a0439a0dab2f32441e8b12aa/toggleButtonExample.x3d >>>> >>>> https://gist.github.com/andreasplesch/6fd2fd0b0f745b3549b74150b7752d89 >>>> >>>> There are two sections, one for the control panel and one for the >>>> controlled assemblage. Each section has a Proto as the main building >>>> block for simple reuse. The toggle button Proto is based on wrapping, >>>> synced Integer and BooleanSequencers for color toggling and outputting >>>> useful events corresponding to the state of the button. This is >>>> probably the most useful and interesting part. Everything else is more >>>> for demonstration. >>>> There is also an animatedBlob Proto which shows how animations might >>>> be controlled by routing events from a toggle button. >>>> The animations all start out in sync after being enabled by a button >>>> but then can be individually paused and resumed for arbitrarily >>>> pulsating patterns. >>>> >>>> Event utilities generally turn out to require verbose declarative >>>> code, compared to logic in scripts but that can be mitigated to a good >>>> extent by Protos which also help with scene structure. >>>> >>>> There is one standard related question which came up for me and I >>>> think that may have been raised before. The question is what the >>>> value_changed should be after a Sequencer receives a first 'next' >>>> event without ever having received a set_fraction or other event. In >>>> this case there is not a next value because there was never any value >>>> in the first place. Both x3dom and x_ite currently output the first >>>> keyValue and set the first key as the current key in this case. >>>> >>>> x_ite and x3dom work almost the same with the example. x_ite >>>> immediately starts the animations where x3dom waits as intended until >>>> the related Timesensors receive a first 'enabled' event. There may be >>>> a simple fix for x_ite use but I could not find it. >>>> >>>> Thanks, -Andreas >>>> >>>> On Sat, Dec 7, 2024 at 4:37?PM John Carlson wrote: >>>> > >>>> > So here?s an interesting question: If I have the same ROUTE in two >>>> different choices in a Switch, is one of them ignored? >>>> > >>>> > Not that I?m going to do that. >>>> > >>>> > I?m probably going to try using a Switch unless someone says that >>>> ROUTEs are always active in a Switch, disagreeing with the AI. >>>> > >>>> > John >>>> > >>>> > On Sat, Dec 7, 2024 at 3:29?PM John Carlson >>>> wrote: >>>> >> >>>> >> From X3D4: >>>> >> >>>> >> >>>> >> 4.4.8.2 Routes >>>> >> >>>> >> Routes are not nodes. >>>> >> >>>> >> [snip] >>>> >> >>>> >> Redundant routing is ignored. If an X3D file repeats a routing path, >>>> the second and subsequent identical routes are ignored. This also applies >>>> for routes created dynamically using the X3D SAI. >>>> >> >>>> >> >>>> >> Can someone clarify how statements are affected by Switches? Can I >>>> have different choices of a PROTO inside a Switch? Effectively changing >>>> ProtoBody content at run-time??? >>>> >> >>>> >> John >>>> >> >>>> >> >>>> >> >>>> >> On Sat, Dec 7, 2024 at 2:40?PM John Carlson >>>> wrote: >>>> >>> >>>> >>> Would it be possible to put an animation?s ROUTEs in a Switch that >>>> could be toggled on and off with a boolean toggle? >>>> >>> >>>> >>> Google AI says: >>>> >>> >>>> >>> Yes, you can absolutely put "ROUTE" nodes within a "Switch" node in >>>> X3D; in fact, it's a common practice to use them together to dynamically >>>> control which set of connections (via ROUTE) are active depending on which >>>> child node of the Switch is currently selected. >>>> >>> >>>> >>> I didn?t realize that statements were affected by Switch. >>>> >>> >>>> >>> John >>>> >>> >>>> >>> On Sat, Dec 7, 2024 at 1:43?PM John Carlson >>>> wrote: >>>> >>>> >>>> >>>> We are dealing with multiple facial animations. The thing we want >>>> to do is combine animations using HAnimDisplacers. Currently, our >>>> animations go from key = 0 to key = 1, (weight = 0 to weight = 1) and each >>>> animation is controlled by a single TimeSensor that we enable or disable. >>>> What we want to do is enable multiple facial animations, yet retain a >>>> single TimeSensor. I have done something with enabling multiple time >>>> sensors all at the same time. So, ideally, we could toggle each facial >>>> animation individually. >>>> >>>> >>>> >>>> Note that one can have multiple simultaneous HAnimDisplacer >>>> animations on a single Coordinate, they all add up just fine. There?s no >>>> single animation per body part requirement as there is in other places in >>>> X3D (according to Michalis, from my understanding). >>>> >>>> >>>> >>>> I don?t currently know how to individually toggle multiple >>>> animations without toggling multiple TimeSensors, so assistance is >>>> welcome! Indeed, a multiple toggle button X3D example would be welcome >>>> (hopefully, something we can put in a scenegraph). >>>> >>>> >>>> >>>> Here?s what we currently have >>>> >>>> >>>> https://github.com/coderextreme/ci2had/blob/main/resources/SingleMenuJin.x3d >>>> >>>> >>>> >>>> As you can see, lots of duplication. >>>> >>>> >>>> >>>> Viewed best in FreeWRL and Sunrize/X_ITE. >>>> >>>> >>>> >>>> John >>>> >>>> >>>> >>>> -- >>>> Andreas Plesch >>>> Waltham, MA 02453 >>>> >>> >> >> -- >> Andreas Plesch >> Waltham, MA 02453 >> > -- Andreas Plesch Waltham, MA 02453 -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Sat Feb 1 16:22:55 2025 From: yottzumm at gmail.com (John Carlson) Date: Sat, 1 Feb 2025 18:22:55 -0600 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: Message-ID: What I?m trying to achieve is pressing multiple buttons, and resetting all transforms when any button is clicked (either on or off). On Sat, Feb 1, 2025 at 5:55?PM Andreas Plesch wrote: > Both x-ite and x3dom behave the same. Each animation is independent and > resets individually after it is stopped and then restarted. > > It seems you aim for another behaviour with some dependency between > animations. > > -Andreas > > On Sat, Feb 1, 2025 at 4:35?PM John Carlson wrote: > >> I'm trying very hard to look at this, but I'm not seeing the animation >> reset when one turns an animation off. Perhaps I should try X3DOM? >> >> >> https://create3000.github.io/x_ite/playground/?url=https://gist.githubusercontent.com/andreasplesch/6fd2fd0b0f745b3549b74150b7752d89/raw/c02637b602f9241c9ea73b5ad859ab330c071e25/toggleReset.x3d >> >> Trying to compare with: >> >> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/6fd2fd0b0f745b3549b74150b7752d89/raw/c02637b602f9241c9ea73b5ad859ab330c071e25/toggleReset.x3d >> >> >> If I click multiple checkboxes, AFAICT, the whole animation doesn't >> reset. I want ALL animations to reset when a button is pressed in, and >> when any button is unpressed. >> >> This is a better link for mine: >> >> >> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >> >> So probably there needs to be a global start/stop time for all enabled >> TimeSensors? >> >> I see you have two ProtoDeclares and I only have one. I might be able to >> do something like that. >> >> Hmm! >> >> John >> >> >> On Sat, Feb 1, 2025 at 2:35?PM Andreas Plesch >> wrote: >> >>> Hi John, >>> >>> >>> https://gist.githubusercontent.com/andreasplesch/6fd2fd0b0f745b3549b74150b7752d89/raw/c02637b602f9241c9ea73b5ad859ab330c071e25/toggleReset.x3d >>> >>> resets the animation everytime it is restarted after stopping. >>> >>> The only change is replacing resumeTime and pauseTime with startTime and >>> stopTime . >>> Instead of a toggle button, it would be possible to have two separate >>> buttons, one for stopping and one for resetting. >>> >>> This may be what you are looking for, -Andreas >>> >>> On Sat, Feb 1, 2025 at 6:16?AM John Carlson wrote: >>> >>>> Andreas, >>>> >>>> For extra credit, reset the animation each time a toggle button is >>>> pressed. So far, it looks dubious without scripting. >>>> >>>> Got a reliable solution for resetting the animations? >>>> >>>> On Wed, Dec 11, 2024 at 3:08?PM Andreas Plesch >>>> wrote: >>>> >>>>> Hi John, group, >>>>> >>>>> Exploring how far one could get without X3D scripts and only using >>>>> event utilities, let me share an example of a panel of individually >>>>> controlled toggle buttons which then drive a simple assemblage of >>>>> individually animated spheres: >>>>> >>>>> >>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/6fd2fd0b0f745b3549b74150b7752d89/raw/37f94755f763ecc9a0439a0dab2f32441e8b12aa/toggleButtonExample.x3d >>>>> >>>>> https://gist.github.com/andreasplesch/6fd2fd0b0f745b3549b74150b7752d89 >>>>> >>>>> There are two sections, one for the control panel and one for the >>>>> controlled assemblage. Each section has a Proto as the main building >>>>> block for simple reuse. The toggle button Proto is based on wrapping, >>>>> synced Integer and BooleanSequencers for color toggling and outputting >>>>> useful events corresponding to the state of the button. This is >>>>> probably the most useful and interesting part. Everything else is more >>>>> for demonstration. >>>>> There is also an animatedBlob Proto which shows how animations might >>>>> be controlled by routing events from a toggle button. >>>>> The animations all start out in sync after being enabled by a button >>>>> but then can be individually paused and resumed for arbitrarily >>>>> pulsating patterns. >>>>> >>>>> Event utilities generally turn out to require verbose declarative >>>>> code, compared to logic in scripts but that can be mitigated to a good >>>>> extent by Protos which also help with scene structure. >>>>> >>>>> There is one standard related question which came up for me and I >>>>> think that may have been raised before. The question is what the >>>>> value_changed should be after a Sequencer receives a first 'next' >>>>> event without ever having received a set_fraction or other event. In >>>>> this case there is not a next value because there was never any value >>>>> in the first place. Both x3dom and x_ite currently output the first >>>>> keyValue and set the first key as the current key in this case. >>>>> >>>>> x_ite and x3dom work almost the same with the example. x_ite >>>>> immediately starts the animations where x3dom waits as intended until >>>>> the related Timesensors receive a first 'enabled' event. There may be >>>>> a simple fix for x_ite use but I could not find it. >>>>> >>>>> Thanks, -Andreas >>>>> >>>>> On Sat, Dec 7, 2024 at 4:37?PM John Carlson >>>>> wrote: >>>>> > >>>>> > So here?s an interesting question: If I have the same ROUTE in two >>>>> different choices in a Switch, is one of them ignored? >>>>> > >>>>> > Not that I?m going to do that. >>>>> > >>>>> > I?m probably going to try using a Switch unless someone says that >>>>> ROUTEs are always active in a Switch, disagreeing with the AI. >>>>> > >>>>> > John >>>>> > >>>>> > On Sat, Dec 7, 2024 at 3:29?PM John Carlson >>>>> wrote: >>>>> >> >>>>> >> From X3D4: >>>>> >> >>>>> >> >>>>> >> 4.4.8.2 Routes >>>>> >> >>>>> >> Routes are not nodes. >>>>> >> >>>>> >> [snip] >>>>> >> >>>>> >> Redundant routing is ignored. If an X3D file repeats a routing >>>>> path, the second and subsequent identical routes are ignored. This also >>>>> applies for routes created dynamically using the X3D SAI. >>>>> >> >>>>> >> >>>>> >> Can someone clarify how statements are affected by Switches? Can I >>>>> have different choices of a PROTO inside a Switch? Effectively changing >>>>> ProtoBody content at run-time??? >>>>> >> >>>>> >> John >>>>> >> >>>>> >> >>>>> >> >>>>> >> On Sat, Dec 7, 2024 at 2:40?PM John Carlson >>>>> wrote: >>>>> >>> >>>>> >>> Would it be possible to put an animation?s ROUTEs in a Switch that >>>>> could be toggled on and off with a boolean toggle? >>>>> >>> >>>>> >>> Google AI says: >>>>> >>> >>>>> >>> Yes, you can absolutely put "ROUTE" nodes within a "Switch" node >>>>> in X3D; in fact, it's a common practice to use them together to dynamically >>>>> control which set of connections (via ROUTE) are active depending on which >>>>> child node of the Switch is currently selected. >>>>> >>> >>>>> >>> I didn?t realize that statements were affected by Switch. >>>>> >>> >>>>> >>> John >>>>> >>> >>>>> >>> On Sat, Dec 7, 2024 at 1:43?PM John Carlson >>>>> wrote: >>>>> >>>> >>>>> >>>> We are dealing with multiple facial animations. The thing we >>>>> want to do is combine animations using HAnimDisplacers. Currently, our >>>>> animations go from key = 0 to key = 1, (weight = 0 to weight = 1) and each >>>>> animation is controlled by a single TimeSensor that we enable or disable. >>>>> What we want to do is enable multiple facial animations, yet retain a >>>>> single TimeSensor. I have done something with enabling multiple time >>>>> sensors all at the same time. So, ideally, we could toggle each facial >>>>> animation individually. >>>>> >>>> >>>>> >>>> Note that one can have multiple simultaneous HAnimDisplacer >>>>> animations on a single Coordinate, they all add up just fine. There?s no >>>>> single animation per body part requirement as there is in other places in >>>>> X3D (according to Michalis, from my understanding). >>>>> >>>> >>>>> >>>> I don?t currently know how to individually toggle multiple >>>>> animations without toggling multiple TimeSensors, so assistance is >>>>> welcome! Indeed, a multiple toggle button X3D example would be welcome >>>>> (hopefully, something we can put in a scenegraph). >>>>> >>>> >>>>> >>>> Here?s what we currently have >>>>> >>>> >>>>> https://github.com/coderextreme/ci2had/blob/main/resources/SingleMenuJin.x3d >>>>> >>>> >>>>> >>>> As you can see, lots of duplication. >>>>> >>>> >>>>> >>>> Viewed best in FreeWRL and Sunrize/X_ITE. >>>>> >>>> >>>>> >>>> John >>>>> >>>>> >>>>> >>>>> -- >>>>> Andreas Plesch >>>>> Waltham, MA 02453 >>>>> >>>> >>> >>> -- >>> Andreas Plesch >>> Waltham, MA 02453 >>> >> > > -- > Andreas Plesch > Waltham, MA 02453 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Sat Feb 1 18:44:05 2025 From: yottzumm at gmail.com (John Carlson) Date: Sat, 1 Feb 2025 20:44:05 -0600 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: Message-ID: I think what I will do is create a reset button to send startTime to all TimeSensors, enabled or not. John On Sat, Feb 1, 2025 at 5:55?PM Andreas Plesch wrote: > Both x-ite and x3dom behave the same. Each animation is independent and > resets individually after it is stopped and then restarted. > > It seems you aim for another behaviour with some dependency between > animations. > > -Andreas > > On Sat, Feb 1, 2025 at 4:35?PM John Carlson wrote: > >> I'm trying very hard to look at this, but I'm not seeing the animation >> reset when one turns an animation off. Perhaps I should try X3DOM? >> >> >> https://create3000.github.io/x_ite/playground/?url=https://gist.githubusercontent.com/andreasplesch/6fd2fd0b0f745b3549b74150b7752d89/raw/c02637b602f9241c9ea73b5ad859ab330c071e25/toggleReset.x3d >> >> Trying to compare with: >> >> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/6fd2fd0b0f745b3549b74150b7752d89/raw/c02637b602f9241c9ea73b5ad859ab330c071e25/toggleReset.x3d >> >> >> If I click multiple checkboxes, AFAICT, the whole animation doesn't >> reset. I want ALL animations to reset when a button is pressed in, and >> when any button is unpressed. >> >> This is a better link for mine: >> >> >> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >> >> So probably there needs to be a global start/stop time for all enabled >> TimeSensors? >> >> I see you have two ProtoDeclares and I only have one. I might be able to >> do something like that. >> >> Hmm! >> >> John >> >> >> On Sat, Feb 1, 2025 at 2:35?PM Andreas Plesch >> wrote: >> >>> Hi John, >>> >>> >>> https://gist.githubusercontent.com/andreasplesch/6fd2fd0b0f745b3549b74150b7752d89/raw/c02637b602f9241c9ea73b5ad859ab330c071e25/toggleReset.x3d >>> >>> resets the animation everytime it is restarted after stopping. >>> >>> The only change is replacing resumeTime and pauseTime with startTime and >>> stopTime . >>> Instead of a toggle button, it would be possible to have two separate >>> buttons, one for stopping and one for resetting. >>> >>> This may be what you are looking for, -Andreas >>> >>> On Sat, Feb 1, 2025 at 6:16?AM John Carlson wrote: >>> >>>> Andreas, >>>> >>>> For extra credit, reset the animation each time a toggle button is >>>> pressed. So far, it looks dubious without scripting. >>>> >>>> Got a reliable solution for resetting the animations? >>>> >>>> On Wed, Dec 11, 2024 at 3:08?PM Andreas Plesch >>>> wrote: >>>> >>>>> Hi John, group, >>>>> >>>>> Exploring how far one could get without X3D scripts and only using >>>>> event utilities, let me share an example of a panel of individually >>>>> controlled toggle buttons which then drive a simple assemblage of >>>>> individually animated spheres: >>>>> >>>>> >>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/6fd2fd0b0f745b3549b74150b7752d89/raw/37f94755f763ecc9a0439a0dab2f32441e8b12aa/toggleButtonExample.x3d >>>>> >>>>> https://gist.github.com/andreasplesch/6fd2fd0b0f745b3549b74150b7752d89 >>>>> >>>>> There are two sections, one for the control panel and one for the >>>>> controlled assemblage. Each section has a Proto as the main building >>>>> block for simple reuse. The toggle button Proto is based on wrapping, >>>>> synced Integer and BooleanSequencers for color toggling and outputting >>>>> useful events corresponding to the state of the button. This is >>>>> probably the most useful and interesting part. Everything else is more >>>>> for demonstration. >>>>> There is also an animatedBlob Proto which shows how animations might >>>>> be controlled by routing events from a toggle button. >>>>> The animations all start out in sync after being enabled by a button >>>>> but then can be individually paused and resumed for arbitrarily >>>>> pulsating patterns. >>>>> >>>>> Event utilities generally turn out to require verbose declarative >>>>> code, compared to logic in scripts but that can be mitigated to a good >>>>> extent by Protos which also help with scene structure. >>>>> >>>>> There is one standard related question which came up for me and I >>>>> think that may have been raised before. The question is what the >>>>> value_changed should be after a Sequencer receives a first 'next' >>>>> event without ever having received a set_fraction or other event. In >>>>> this case there is not a next value because there was never any value >>>>> in the first place. Both x3dom and x_ite currently output the first >>>>> keyValue and set the first key as the current key in this case. >>>>> >>>>> x_ite and x3dom work almost the same with the example. x_ite >>>>> immediately starts the animations where x3dom waits as intended until >>>>> the related Timesensors receive a first 'enabled' event. There may be >>>>> a simple fix for x_ite use but I could not find it. >>>>> >>>>> Thanks, -Andreas >>>>> >>>>> On Sat, Dec 7, 2024 at 4:37?PM John Carlson >>>>> wrote: >>>>> > >>>>> > So here?s an interesting question: If I have the same ROUTE in two >>>>> different choices in a Switch, is one of them ignored? >>>>> > >>>>> > Not that I?m going to do that. >>>>> > >>>>> > I?m probably going to try using a Switch unless someone says that >>>>> ROUTEs are always active in a Switch, disagreeing with the AI. >>>>> > >>>>> > John >>>>> > >>>>> > On Sat, Dec 7, 2024 at 3:29?PM John Carlson >>>>> wrote: >>>>> >> >>>>> >> From X3D4: >>>>> >> >>>>> >> >>>>> >> 4.4.8.2 Routes >>>>> >> >>>>> >> Routes are not nodes. >>>>> >> >>>>> >> [snip] >>>>> >> >>>>> >> Redundant routing is ignored. If an X3D file repeats a routing >>>>> path, the second and subsequent identical routes are ignored. This also >>>>> applies for routes created dynamically using the X3D SAI. >>>>> >> >>>>> >> >>>>> >> Can someone clarify how statements are affected by Switches? Can I >>>>> have different choices of a PROTO inside a Switch? Effectively changing >>>>> ProtoBody content at run-time??? >>>>> >> >>>>> >> John >>>>> >> >>>>> >> >>>>> >> >>>>> >> On Sat, Dec 7, 2024 at 2:40?PM John Carlson >>>>> wrote: >>>>> >>> >>>>> >>> Would it be possible to put an animation?s ROUTEs in a Switch that >>>>> could be toggled on and off with a boolean toggle? >>>>> >>> >>>>> >>> Google AI says: >>>>> >>> >>>>> >>> Yes, you can absolutely put "ROUTE" nodes within a "Switch" node >>>>> in X3D; in fact, it's a common practice to use them together to dynamically >>>>> control which set of connections (via ROUTE) are active depending on which >>>>> child node of the Switch is currently selected. >>>>> >>> >>>>> >>> I didn?t realize that statements were affected by Switch. >>>>> >>> >>>>> >>> John >>>>> >>> >>>>> >>> On Sat, Dec 7, 2024 at 1:43?PM John Carlson >>>>> wrote: >>>>> >>>> >>>>> >>>> We are dealing with multiple facial animations. The thing we >>>>> want to do is combine animations using HAnimDisplacers. Currently, our >>>>> animations go from key = 0 to key = 1, (weight = 0 to weight = 1) and each >>>>> animation is controlled by a single TimeSensor that we enable or disable. >>>>> What we want to do is enable multiple facial animations, yet retain a >>>>> single TimeSensor. I have done something with enabling multiple time >>>>> sensors all at the same time. So, ideally, we could toggle each facial >>>>> animation individually. >>>>> >>>> >>>>> >>>> Note that one can have multiple simultaneous HAnimDisplacer >>>>> animations on a single Coordinate, they all add up just fine. There?s no >>>>> single animation per body part requirement as there is in other places in >>>>> X3D (according to Michalis, from my understanding). >>>>> >>>> >>>>> >>>> I don?t currently know how to individually toggle multiple >>>>> animations without toggling multiple TimeSensors, so assistance is >>>>> welcome! Indeed, a multiple toggle button X3D example would be welcome >>>>> (hopefully, something we can put in a scenegraph). >>>>> >>>> >>>>> >>>> Here?s what we currently have >>>>> >>>> >>>>> https://github.com/coderextreme/ci2had/blob/main/resources/SingleMenuJin.x3d >>>>> >>>> >>>>> >>>> As you can see, lots of duplication. >>>>> >>>> >>>>> >>>> Viewed best in FreeWRL and Sunrize/X_ITE. >>>>> >>>> >>>>> >>>> John >>>>> >>>>> >>>>> >>>>> -- >>>>> Andreas Plesch >>>>> Waltham, MA 02453 >>>>> >>>> >>> >>> -- >>> Andreas Plesch >>> Waltham, MA 02453 >>> >> > > -- > Andreas Plesch > Waltham, MA 02453 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Sat Feb 1 18:47:11 2025 From: yottzumm at gmail.com (John Carlson) Date: Sat, 1 Feb 2025 20:47:11 -0600 Subject: [x3d-public] Having a bit of difficult ROUTEing to node outside the ProtoDeclare in Sunrize In-Reply-To: References: Message-ID: Apparently, I overthought this, and simpler answers overcame this. John On Fri, Jan 31, 2025 at 4:29?PM John Carlson wrote: > I'm having a bit of difficult ROUTEing to node outside the ProtoDeclare > in Sunrize > I get this error: > > Sunrize reports: > XML Parser: Unknown named or imported node 'clock'. > > CGE model viewer reports: > > X3D: Route destination node name "clock" not found > > I don't really see what I am doing wrong yet. > > loop="true" /> > > > > type="SFVec3f"/> > type="SFString"/> > type="MFString"/> > > > value="40.0 3.0"/> > value="2.4"/> > value="1.2"/> > > > > > > > > > > > > > > > > > protoField="textTranslation"/> > > > > > > > > protoField="menuItemString"/> > > > > > > > > > > > > > > > > > > > > > > > > > fromField="touchTime" toNode="ScriptToggle" toField="inTime"/> > toNode="ScriptToggle" toField="diffuseColor"/> > toNode="MenuBackground_Material" toField="diffuseColor" /> > fromField="touchTime" toNode="clock" toField="startTime"/> > ' > > > > > > > > > > > > > > > > > > > toNode="AnimationAdapter_JinBlink" toField="set_fraction"/> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Sun Feb 2 02:11:42 2025 From: yottzumm at gmail.com (John Carlson) Date: Sun, 2 Feb 2025 04:11:42 -0600 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: Message-ID: What I really think I want to do is send a set_fraction = 0 event to all ScalarInterpolators, and have that controlled by a menu selection. John On Sat, Feb 1, 2025 at 8:44?PM John Carlson wrote: > I think what I will do is create a reset button to send startTime to all > TimeSensors, enabled or not. > > John > > On Sat, Feb 1, 2025 at 5:55?PM Andreas Plesch > wrote: > >> Both x-ite and x3dom behave the same. Each animation is independent and >> resets individually after it is stopped and then restarted. >> >> It seems you aim for another behaviour with some dependency between >> animations. >> >> -Andreas >> >> On Sat, Feb 1, 2025 at 4:35?PM John Carlson wrote: >> >>> I'm trying very hard to look at this, but I'm not seeing the animation >>> reset when one turns an animation off. Perhaps I should try X3DOM? >>> >>> >>> https://create3000.github.io/x_ite/playground/?url=https://gist.githubusercontent.com/andreasplesch/6fd2fd0b0f745b3549b74150b7752d89/raw/c02637b602f9241c9ea73b5ad859ab330c071e25/toggleReset.x3d >>> >>> Trying to compare with: >>> >>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/6fd2fd0b0f745b3549b74150b7752d89/raw/c02637b602f9241c9ea73b5ad859ab330c071e25/toggleReset.x3d >>> >>> >>> If I click multiple checkboxes, AFAICT, the whole animation doesn't >>> reset. I want ALL animations to reset when a button is pressed in, and >>> when any button is unpressed. >>> >>> This is a better link for mine: >>> >>> >>> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>> >>> So probably there needs to be a global start/stop time for all enabled >>> TimeSensors? >>> >>> I see you have two ProtoDeclares and I only have one. I might be able >>> to do something like that. >>> >>> Hmm! >>> >>> John >>> >>> >>> On Sat, Feb 1, 2025 at 2:35?PM Andreas Plesch >>> wrote: >>> >>>> Hi John, >>>> >>>> >>>> https://gist.githubusercontent.com/andreasplesch/6fd2fd0b0f745b3549b74150b7752d89/raw/c02637b602f9241c9ea73b5ad859ab330c071e25/toggleReset.x3d >>>> >>>> resets the animation everytime it is restarted after stopping. >>>> >>>> The only change is replacing resumeTime and pauseTime with startTime >>>> and stopTime . >>>> Instead of a toggle button, it would be possible to have two separate >>>> buttons, one for stopping and one for resetting. >>>> >>>> This may be what you are looking for, -Andreas >>>> >>>> On Sat, Feb 1, 2025 at 6:16?AM John Carlson wrote: >>>> >>>>> Andreas, >>>>> >>>>> For extra credit, reset the animation each time a toggle button is >>>>> pressed. So far, it looks dubious without scripting. >>>>> >>>>> Got a reliable solution for resetting the animations? >>>>> >>>>> On Wed, Dec 11, 2024 at 3:08?PM Andreas Plesch < >>>>> andreasplesch at gmail.com> wrote: >>>>> >>>>>> Hi John, group, >>>>>> >>>>>> Exploring how far one could get without X3D scripts and only using >>>>>> event utilities, let me share an example of a panel of individually >>>>>> controlled toggle buttons which then drive a simple assemblage of >>>>>> individually animated spheres: >>>>>> >>>>>> >>>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/6fd2fd0b0f745b3549b74150b7752d89/raw/37f94755f763ecc9a0439a0dab2f32441e8b12aa/toggleButtonExample.x3d >>>>>> >>>>>> https://gist.github.com/andreasplesch/6fd2fd0b0f745b3549b74150b7752d89 >>>>>> >>>>>> There are two sections, one for the control panel and one for the >>>>>> controlled assemblage. Each section has a Proto as the main building >>>>>> block for simple reuse. The toggle button Proto is based on wrapping, >>>>>> synced Integer and BooleanSequencers for color toggling and outputting >>>>>> useful events corresponding to the state of the button. This is >>>>>> probably the most useful and interesting part. Everything else is more >>>>>> for demonstration. >>>>>> There is also an animatedBlob Proto which shows how animations might >>>>>> be controlled by routing events from a toggle button. >>>>>> The animations all start out in sync after being enabled by a button >>>>>> but then can be individually paused and resumed for arbitrarily >>>>>> pulsating patterns. >>>>>> >>>>>> Event utilities generally turn out to require verbose declarative >>>>>> code, compared to logic in scripts but that can be mitigated to a good >>>>>> extent by Protos which also help with scene structure. >>>>>> >>>>>> There is one standard related question which came up for me and I >>>>>> think that may have been raised before. The question is what the >>>>>> value_changed should be after a Sequencer receives a first 'next' >>>>>> event without ever having received a set_fraction or other event. In >>>>>> this case there is not a next value because there was never any value >>>>>> in the first place. Both x3dom and x_ite currently output the first >>>>>> keyValue and set the first key as the current key in this case. >>>>>> >>>>>> x_ite and x3dom work almost the same with the example. x_ite >>>>>> immediately starts the animations where x3dom waits as intended until >>>>>> the related Timesensors receive a first 'enabled' event. There may be >>>>>> a simple fix for x_ite use but I could not find it. >>>>>> >>>>>> Thanks, -Andreas >>>>>> >>>>>> On Sat, Dec 7, 2024 at 4:37?PM John Carlson >>>>>> wrote: >>>>>> > >>>>>> > So here?s an interesting question: If I have the same ROUTE in two >>>>>> different choices in a Switch, is one of them ignored? >>>>>> > >>>>>> > Not that I?m going to do that. >>>>>> > >>>>>> > I?m probably going to try using a Switch unless someone says that >>>>>> ROUTEs are always active in a Switch, disagreeing with the AI. >>>>>> > >>>>>> > John >>>>>> > >>>>>> > On Sat, Dec 7, 2024 at 3:29?PM John Carlson >>>>>> wrote: >>>>>> >> >>>>>> >> From X3D4: >>>>>> >> >>>>>> >> >>>>>> >> 4.4.8.2 Routes >>>>>> >> >>>>>> >> Routes are not nodes. >>>>>> >> >>>>>> >> [snip] >>>>>> >> >>>>>> >> Redundant routing is ignored. If an X3D file repeats a routing >>>>>> path, the second and subsequent identical routes are ignored. This also >>>>>> applies for routes created dynamically using the X3D SAI. >>>>>> >> >>>>>> >> >>>>>> >> Can someone clarify how statements are affected by Switches? Can >>>>>> I have different choices of a PROTO inside a Switch? Effectively changing >>>>>> ProtoBody content at run-time??? >>>>>> >> >>>>>> >> John >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> On Sat, Dec 7, 2024 at 2:40?PM John Carlson >>>>>> wrote: >>>>>> >>> >>>>>> >>> Would it be possible to put an animation?s ROUTEs in a Switch >>>>>> that could be toggled on and off with a boolean toggle? >>>>>> >>> >>>>>> >>> Google AI says: >>>>>> >>> >>>>>> >>> Yes, you can absolutely put "ROUTE" nodes within a "Switch" node >>>>>> in X3D; in fact, it's a common practice to use them together to dynamically >>>>>> control which set of connections (via ROUTE) are active depending on which >>>>>> child node of the Switch is currently selected. >>>>>> >>> >>>>>> >>> I didn?t realize that statements were affected by Switch. >>>>>> >>> >>>>>> >>> John >>>>>> >>> >>>>>> >>> On Sat, Dec 7, 2024 at 1:43?PM John Carlson >>>>>> wrote: >>>>>> >>>> >>>>>> >>>> We are dealing with multiple facial animations. The thing we >>>>>> want to do is combine animations using HAnimDisplacers. Currently, our >>>>>> animations go from key = 0 to key = 1, (weight = 0 to weight = 1) and each >>>>>> animation is controlled by a single TimeSensor that we enable or disable. >>>>>> What we want to do is enable multiple facial animations, yet retain a >>>>>> single TimeSensor. I have done something with enabling multiple time >>>>>> sensors all at the same time. So, ideally, we could toggle each facial >>>>>> animation individually. >>>>>> >>>> >>>>>> >>>> Note that one can have multiple simultaneous HAnimDisplacer >>>>>> animations on a single Coordinate, they all add up just fine. There?s no >>>>>> single animation per body part requirement as there is in other places in >>>>>> X3D (according to Michalis, from my understanding). >>>>>> >>>> >>>>>> >>>> I don?t currently know how to individually toggle multiple >>>>>> animations without toggling multiple TimeSensors, so assistance is >>>>>> welcome! Indeed, a multiple toggle button X3D example would be welcome >>>>>> (hopefully, something we can put in a scenegraph). >>>>>> >>>> >>>>>> >>>> Here?s what we currently have >>>>>> >>>> >>>>>> https://github.com/coderextreme/ci2had/blob/main/resources/SingleMenuJin.x3d >>>>>> >>>> >>>>>> >>>> As you can see, lots of duplication. >>>>>> >>>> >>>>>> >>>> Viewed best in FreeWRL and Sunrize/X_ITE. >>>>>> >>>> >>>>>> >>>> John >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Andreas Plesch >>>>>> Waltham, MA 02453 >>>>>> >>>>> >>>> >>>> -- >>>> Andreas Plesch >>>> Waltham, MA 02453 >>>> >>> >> >> -- >> Andreas Plesch >> Waltham, MA 02453 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Sun Feb 2 02:42:29 2025 From: yottzumm at gmail.com (John Carlson) Date: Sun, 2 Feb 2025 04:42:29 -0600 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: Message-ID: Andreas, Joe, Reset Button, Reset_Clock added. See attached zip for details, or visit link; https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d For some reason, this link doesn't show the live scene? https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d Puzzled, haven't researched it yet. Looks good in Sunrize and X_ITE, will try FreeWRL next. John > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Clocks3.zip Type: application/x-zip-compressed Size: 257426 bytes Desc: not available URL: From andreasplesch at gmail.com Sun Feb 2 13:58:56 2025 From: andreasplesch at gmail.com (Andreas Plesch) Date: Sun, 2 Feb 2025 16:58:56 -0500 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: Message-ID: I think x3dom, reasonably, expects a value for the fieldValue nodes: For example: and others. On Sun, Feb 2, 2025 at 5:42?AM John Carlson wrote: > Andreas, Joe, > > Reset Button, Reset_Clock added. > > See attached zip for details, or visit link; > > > https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d > > For some reason, this link doesn't show the live scene? > > > https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d > > Puzzled, haven't researched it yet. Looks good in Sunrize and X_ITE, will > try FreeWRL next. > > John > >> -- Andreas Plesch Waltham, MA 02453 -------------- next part -------------- An HTML attachment was scrubbed... URL: From joedwil at earthlink.net Sun Feb 2 17:40:55 2025 From: joedwil at earthlink.net (Joe D Williams) Date: Mon, 03 Feb 2025 01:40:55 +0000 Subject: [x3d-public] Audio from gltf in x3d Message-ID: https://youtu.be/P7I5GV56B4g?list=TLPQMDIwMjIwMjUkPbAPdXV4wg&t=1192 https://youtu.be/mqaPSF5wpjo I was hoping Alexey and Chintan might be able to point to x3d as having a good implementation of the gltf audio metaversal spacial and more audio scheme. He mentioned web audio (non-positioned). Wondering what is diff for x3d vs GLTF audio. I Can't find this Meta-driven gltf audio api. https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/sound.html https://developer.mozilla.org/en-US/docs/Web/API/Web_Audio_API Thanks for audio fun, Joe From joedwil at earthlink.net Sun Feb 2 17:56:53 2025 From: joedwil at earthlink.net (Joe D Williams) Date: Mon, 03 Feb 2025 01:56:53 +0000 Subject: [x3d-public] Audio from gltf in x3d +mpeg Message-ID: <8f918b7d-11dc-8e3b-6825-85c40a439b0a@earthlink.net> Also this: https://github.com/KhronosGroup/glTF/blob/main/extensions/2.0/Vendor/MPEG_audio_spatial/README.md -----Original Message----- From: Extensible 3D (X3D) Graphics public discussion Sent: Feb 2, 2025 5:41 PM To: Cc: Joe D Williams Subject: [x3d-public] Audio from gltf in x3d https://youtu.be/P7I5GV56B4g?list=TLPQMDIwMjIwMjUkPbAPdXV4wg&t=1192 https://youtu.be/mqaPSF5wpjo I was hoping Alexey and Chintan might be able to point to x3d as having a good implementation of the gltf audio metaversal spacial and more audio scheme. He mentioned web audio (non-positioned). Wondering what is diff for x3d vs GLTF audio. I Can't find this Meta-driven gltf audio api. https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/sound.html https://developer.mozilla.org/en-US/docs/Web/API/Web_Audio_API Thanks for audio fun, Joe _______________________________________________ x3d-public mailing list x3d-public at web3d.org http://web3d.org/mailman/listinfo/x3d-public_web3d.org From andreasplesch at gmail.com Sun Feb 2 20:39:40 2025 From: andreasplesch at gmail.com (Andreas Plesch) Date: Sun, 2 Feb 2025 23:39:40 -0500 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: Message-ID: Apologies in advance if the following comes across as a bit of rigid thinking for a corner case but unfortunately there is now an example. A larger standard question is how to correctly process a fieldValue statement with a default value for the value attribute. The XML schema for fieldValue says that the default value for the value attribute is "", the empty string. Relying on that default is rarely, perhaps never, a useful use of fieldValue but is allowed. Scenario A) In the case the field for which such a fieldValue is given is of type SFTime, this would strictly mean that the value is invalid since the "" is not an encoding of a floating point number and does not pass the regex test. Therefore processing could become undefined and should be halted. Scenario B) Another, perhaps less strict but more useful interpretation is that the empty string for SFTime signals the lack of a value and that therefore a default value for the SFTime field should be adopted. This default could be an initial -1 as the Tooltips suggest, and would likely be overwritten. A) is stricter and follows the rules more literally. B) is perhaps more often what authors intend but may need some clarification in the specification. This applies only to the XML encoding. I think the XML encoding for fieldValue should require one of: an existing value attribute, or at least one child node (as a XFNode value). Not sure if the XML schema could handle that. Would you prefer A) or B) ? Personally A) with some error messages but some X3D browsers accept B). Thanks, Andreas On Sun, Feb 2, 2025 at 4:58?PM Andreas Plesch wrote: > I think x3dom, reasonably, expects a value for the fieldValue nodes: > > For example: > > > > and others. > > On Sun, Feb 2, 2025 at 5:42?AM John Carlson wrote: > >> Andreas, Joe, >> >> Reset Button, Reset_Clock added. >> >> See attached zip for details, or visit link; >> >> >> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >> >> For some reason, this link doesn't show the live scene? >> >> >> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >> >> Puzzled, haven't researched it yet. Looks good in Sunrize and X_ITE, >> will try FreeWRL next. >> >> John >> >>> > > -- > Andreas Plesch > Waltham, MA 02453 > -- Andreas Plesch Waltham, MA 02453 -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Sun Feb 2 21:48:40 2025 From: yottzumm at gmail.com (John Carlson) Date: Sun, 2 Feb 2025 23:48:40 -0600 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: Message-ID: Andreas, "startTime" is an accessType outputOnly field, so why do I need to provide a value attribute in fieldValue? I'm kind of confused. I'm probably missing something in the spec. Thanks for any clarification. I have finally enabled schematron on the project, but I'm finding it hard to understand the messages, and modifications that I make, while removing the immediate problems, seem to move the problems elsewhere. Explaining why I need a "startTime" fieldValue value is my main lack of understanding, but perhaps I need a whole review of accessType. Castle Model Converter reports: castle-model-converter: Warning: X3D: X3D XML: element references unknown field name "enabled" castle-model-converter: Warning: X3D: X3D XML: element references unknown field name "startTime" castle-model-converter: Warning: X3D: X3D XML: element references unknown field name "stopTime" I will try providing a field value in the ProtoInterface If I "cleanup" enabled, startTime and stopTime, I get: castle-model-converter: Warning: VRML/X3D: Within prototype "MenuItem", event "inputTrue" references (by "IS" clause) non-existing event "enabled" castle-model-converter: Warning: VRML/X3D: Within prototype "MenuItem", event "triggerTime" references (by "IS" clause) non-existing event "startTime" castle-model-converter: Warning: VRML/X3D: Within prototype "MenuItem", event "triggerTime" references (by "IS" clause) non-existing event "stopTime" I guess what I conclude at this point is, startTime and stopTime are bad DEF names, but what about enabled as a field? The dominoes are falling. About your two scenarios in the other message, perhaps this is revealing. See attached attempt to fix original issue, which resulted in the above. John On Sun, Feb 2, 2025 at 3:59?PM Andreas Plesch wrote: > I think x3dom, reasonably, expects a value for the fieldValue nodes: > > For example: > > > > and others. > > On Sun, Feb 2, 2025 at 5:42?AM John Carlson wrote: > >> Andreas, Joe, >> >> Reset Button, Reset_Clock added. >> >> See attached zip for details, or visit link; >> >> >> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >> >> For some reason, this link doesn't show the live scene? >> >> >> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >> >> Puzzled, haven't researched it yet. Looks good in Sunrize and X_ITE, >> will try FreeWRL next. >> >> John >> >>> > > -- > Andreas Plesch > Waltham, MA 02453 > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Clocks4.zip Type: application/x-zip-compressed Size: 147020 bytes Desc: not available URL: From yottzumm at gmail.com Sun Feb 2 22:11:45 2025 From: yottzumm at gmail.com (John Carlson) Date: Mon, 3 Feb 2025 00:11:45 -0600 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: Message-ID: I have no problems with your thinking Andreas. My only questions are 1) Why am I chosen to find these corner cases? 2) Can Castle Model Viewer support ECMAScript soon, perhaps in an Electron or better WebView? 3) It would seem like ProtoInterface field accessType="outputOnly" needs to be treated specially. Primarily, I am concerned that A) alone will not solve 3) above and B) may be required. Castle Model Viewer already has A), which is helpful, but I don't have a workaround yet. On Sun, Feb 2, 2025 at 10:40?PM Andreas Plesch wrote: > Apologies in advance if the following comes across as a bit of > rigid thinking for a corner case but unfortunately there is now an example. > A larger standard question is how to correctly process a fieldValue > statement with a default value for the value attribute. > The XML schema for fieldValue says that the default value for the value > attribute is "", the empty string. Relying on that default is rarely, > perhaps never, a useful use of fieldValue but is allowed. > > Scenario A) > In the case the field for which such a fieldValue is given is of type > SFTime, this would strictly mean that the value is invalid since the "" is > not an encoding of a floating point number and does not pass the regex > test. Therefore processing could become undefined and should be halted. > > Scenario B) > Another, perhaps less strict but more useful interpretation is that the > empty string for SFTime signals the lack of a value and that therefore a > default value for the SFTime field should be adopted. This default could be > an initial -1 as the Tooltips suggest, and would likely be overwritten. > > A) is stricter and follows the rules more literally. B) is perhaps > more often what authors intend but may need some clarification in the > specification. > > This applies only to the XML encoding. > > I think the XML encoding for fieldValue should require one of: an existing > value attribute, or at least one child node (as a XFNode value). Not sure > if the XML schema could handle that. > > Would you prefer A) or B) ? > > Personally A) with some error messages but some X3D browsers accept B). > > Thanks, Andreas > > > On Sun, Feb 2, 2025 at 4:58?PM Andreas Plesch > wrote: > >> I think x3dom, reasonably, expects a value for the fieldValue nodes: >> >> For example: >> >> >> >> and others. >> >> On Sun, Feb 2, 2025 at 5:42?AM John Carlson wrote: >> >>> Andreas, Joe, >>> >>> Reset Button, Reset_Clock added. >>> >>> See attached zip for details, or visit link; >>> >>> >>> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>> >>> For some reason, this link doesn't show the live scene? >>> >>> >>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>> >>> Puzzled, haven't researched it yet. Looks good in Sunrize and X_ITE, >>> will try FreeWRL next. >>> >>> John >>> >>>> >> >> -- >> Andreas Plesch >> Waltham, MA 02453 >> > > > -- > Andreas Plesch > Waltham, MA 02453 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger.seelig at yahoo.de Mon Feb 3 02:06:30 2025 From: holger.seelig at yahoo.de (Holger Seelig) Date: Mon, 3 Feb 2025 11:06:30 +0100 Subject: [x3d-public] Differences in default values of TextureProperties Spec vs X3DUOM vs Tooltips References: Message-ID: The three fields have in Spec a default value of ?DEFAUT? and in X3DUOM and Tooltips a default value of ?FASTEST?. Which one is the correct value? Field SFString 'minificationFilter' in node TextureProperties has different value (Spec <=> X3DUOM): DEFAULT !== FASTEST. Field SFString 'magnificationFilter' in node TextureProperties has different value (Spec <=> X3DUOM): DEFAULT !== FASTEST. Field SFString 'textureCompression' in node TextureProperties has different value (Spec <=> X3DUOM): DEFAULT !== FASTEST. https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/texturing.html#TextureProperties https://www.web3d.org/specifications/X3dUnifiedObjectModel-4.0.xml https://www.web3d.org/x3d/content/X3dTooltips.html#TextureProperties Best regards, Holger -- Holger Seelig Leipzig, Germany holger.seelig at yahoo.de https://create3000.github.io/x_ite/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From michalis.kambi at gmail.com Mon Feb 3 03:57:00 2025 From: michalis.kambi at gmail.com (Michalis Kamburelis) Date: Mon, 3 Feb 2025 12:57:00 +0100 Subject: [x3d-public] Differences in default values of TextureProperties Spec vs X3DUOM vs Tooltips In-Reply-To: References: Message-ID: The default for minificationFilter , magnificationFilter has changed, the new correct default is "DEFAULT" (which, in turn, means "browser-specified default magnification/minification mode"). See my email from 2013 August for reasons: https://web3d.org/pipermail/x3d-public_web3d.org/2013-August/002496.html . We did the change in spec around 2022-03-09 (that's when I see I changed it in CGE implementation, though I cannot find the x3d-public relevant thread). See CGE notes: https://castle-engine.io/x3d_implementation_texturing.php . Basically, before the change, TextureProperties was a bit of a trap, because changing: ImageTexture { url "sample.png" } -> ImageTexture { url "sample.png" textureProperties TextureProperties { } } ...was a "trap", because it unintuitively also changed the filtering of "sample.png" to "fastest" (which should mean "nearest"). This was unexpected for authors (I stumbled into this trap, I had other X3D users of CGE that stumbled into this trap). Now (with new default) the above change does nothing, which is more intuitive (since you didn't set any TextureProperties fields) -> before and after the change, browser uses default minification/magnification. IOW, mere existence of TextureProperties node makes no change above. Regards, Michalis pon., 3 lut 2025 o 11:07 Holger Seelig via x3d-public napisa?(a): > > The three fields have in Spec a default value of ?DEFAUT? and in X3DUOM and Tooltips a default value of ?FASTEST?. Which one is the correct value? > > Field SFString 'minificationFilter' in node TextureProperties has different value (Spec <=> X3DUOM): DEFAULT !== FASTEST. Field SFString 'magnificationFilter' in node TextureProperties has different value (Spec <=> X3DUOM): DEFAULT !== FASTEST. > Field SFString 'textureCompression' in node TextureProperties has different value (Spec <=> X3DUOM): DEFAULT !== FASTEST. > > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/texturing.html#TextureProperties > https://www.web3d.org/specifications/X3dUnifiedObjectModel-4.0.xml > https://www.web3d.org/x3d/content/X3dTooltips.html#TextureProperties > > Best regards, > Holger > > -- > Holger Seelig > Leipzig, Germany > > holger.seelig at yahoo.de > https://create3000.github.io/x_ite/ > > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org From holger.seelig at yahoo.de Mon Feb 3 04:16:34 2025 From: holger.seelig at yahoo.de (Holger Seelig) Date: Mon, 3 Feb 2025 13:16:34 +0100 Subject: [x3d-public] Differences in default values of TextureProperties Spec vs X3DUOM vs Tooltips In-Reply-To: References: Message-ID: <1AAB4939-352D-4024-8E01-FE3E07566704@yahoo.de> Thank you Michalis for explaining this change. This all makes much sense. Best regards, Holger -- Holger Seelig Leipzig, Germany holger.seelig at yahoo.de https://create3000.github.io/x_ite/ > Am 03.02.2025 um 12:57 schrieb Michalis Kamburelis : > > The default for minificationFilter , magnificationFilter has changed, > the new correct default is "DEFAULT" (which, in turn, means > "browser-specified default magnification/minification mode"). > > See my email from 2013 August for reasons: > https://web3d.org/pipermail/x3d-public_web3d.org/2013-August/002496.html > . > > We did the change in spec around 2022-03-09 (that's when I see I > changed it in CGE implementation, though I cannot find the x3d-public > relevant thread). See CGE notes: > https://castle-engine.io/x3d_implementation_texturing.php . > > Basically, before the change, TextureProperties was a bit of a trap, > because changing: > > ImageTexture { > url "sample.png" > } > > -> > > ImageTexture { > url "sample.png" > textureProperties TextureProperties { > } > } > > ...was a "trap", because it unintuitively also changed the filtering > of "sample.png" to "fastest" (which should mean "nearest"). This was > unexpected for authors (I stumbled into this trap, I had other X3D > users of CGE that stumbled into this trap). > > Now (with new default) the above change does nothing, which is more > intuitive (since you didn't set any TextureProperties fields) -> > before and after the change, browser uses default > minification/magnification. IOW, mere existence of TextureProperties > node makes no change above. > > Regards, > Michalis > > pon., 3 lut 2025 o 11:07 Holger Seelig via x3d-public > napisa?(a): >> >> The three fields have in Spec a default value of ?DEFAUT? and in X3DUOM and Tooltips a default value of ?FASTEST?. Which one is the correct value? >> >> Field SFString 'minificationFilter' in node TextureProperties has different value (Spec <=> X3DUOM): DEFAULT !== FASTEST. Field SFString 'magnificationFilter' in node TextureProperties has different value (Spec <=> X3DUOM): DEFAULT !== FASTEST. >> Field SFString 'textureCompression' in node TextureProperties has different value (Spec <=> X3DUOM): DEFAULT !== FASTEST. >> >> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/texturing.html#TextureProperties >> https://www.web3d.org/specifications/X3dUnifiedObjectModel-4.0.xml >> https://www.web3d.org/x3d/content/X3dTooltips.html#TextureProperties >> >> Best regards, >> Holger >> >> -- >> Holger Seelig >> Leipzig, Germany >> >> holger.seelig at yahoo.de >> https://create3000.github.io/x_ite/ >> >> _______________________________________________ >> x3d-public mailing list >> x3d-public at web3d.org >> http://web3d.org/mailman/listinfo/x3d-public_web3d.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreasplesch at gmail.com Mon Feb 3 04:39:46 2025 From: andreasplesch at gmail.com (Andreas Plesch) Date: Mon, 3 Feb 2025 07:39:46 -0500 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: Message-ID: Hi John, On Mon, Feb 3, 2025 at 12:48?AM John Carlson wrote: > Andreas, "startTime" is an accessType outputOnly field, so why do I need > to provide a value attribute in fieldValue? I'm kind of confused. I'm > probably missing something in the spec. > You are right, I only outlined scenarios where the accessType allows input or initialization.. In the outputOnly case it is not necessary to provide a fieldValue node at all since there is no value which can be provided. Providing the node would indeed be confusing, to both the user code reader and any X3D browser. I believe the spec. is silent on this case in any encoding. Best, Andreas Thanks for any clarification. > > I have finally enabled schematron on the project, but I'm finding it hard > to understand the messages, and modifications that I make, while removing > the immediate problems, seem to move the problems elsewhere. > > Explaining why I need a "startTime" fieldValue value is my main lack of > understanding, but perhaps I need a whole review of accessType. > > Castle Model Converter reports: > > castle-model-converter: Warning: X3D: X3D XML: element > references unknown field name "enabled" > castle-model-converter: Warning: X3D: X3D XML: element > references unknown field name "startTime" > castle-model-converter: Warning: X3D: X3D XML: element > references unknown field name "stopTime" > > I will try providing a field value in the ProtoInterface > > If I "cleanup" enabled, startTime and stopTime, I get: > > castle-model-converter: Warning: VRML/X3D: Within prototype "MenuItem", > event "inputTrue" references (by "IS" clause) non-existing event "enabled" > castle-model-converter: Warning: VRML/X3D: Within prototype "MenuItem", > event "triggerTime" references (by "IS" clause) non-existing event > "startTime" > castle-model-converter: Warning: VRML/X3D: Within prototype "MenuItem", > event "triggerTime" references (by "IS" clause) non-existing event > "stopTime" > > I guess what I conclude at this point is, startTime and stopTime are bad > DEF names, but what about enabled as a field? The dominoes are falling. > > About your two scenarios in the other message, perhaps this is revealing. > > See attached attempt to fix original issue, which resulted in the above. > > John > > On Sun, Feb 2, 2025 at 3:59?PM Andreas Plesch > wrote: > >> I think x3dom, reasonably, expects a value for the fieldValue nodes: >> >> For example: >> >> >> >> and others. >> >> On Sun, Feb 2, 2025 at 5:42?AM John Carlson wrote: >> >>> Andreas, Joe, >>> >>> Reset Button, Reset_Clock added. >>> >>> See attached zip for details, or visit link; >>> >>> >>> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>> >>> For some reason, this link doesn't show the live scene? >>> >>> >>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>> >>> Puzzled, haven't researched it yet. Looks good in Sunrize and X_ITE, >>> will try FreeWRL next. >>> >>> John >>> >>>> >> >> -- >> Andreas Plesch >> Waltham, MA 02453 >> > -- Andreas Plesch Waltham, MA 02453 -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreasplesch at gmail.com Mon Feb 3 04:43:49 2025 From: andreasplesch at gmail.com (Andreas Plesch) Date: Mon, 3 Feb 2025 07:43:49 -0500 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: Message-ID: Hi John, my only thought is that only A) - the strict scenario - can be relied upon currently. Best, -Andreas On Mon, Feb 3, 2025 at 1:11?AM John Carlson wrote: > I have no problems with your thinking Andreas. My only questions are 1) > Why am I chosen to find these corner cases? 2) Can Castle Model Viewer > support ECMAScript soon, perhaps in an Electron or better WebView? 3) It > would seem like ProtoInterface field accessType="outputOnly" needs to be > treated specially. > > Primarily, I am concerned that A) alone will not solve 3) above and B) may > be required. Castle Model Viewer already has A), which is helpful, but I > don't have a workaround yet. > > On Sun, Feb 2, 2025 at 10:40?PM Andreas Plesch > wrote: > >> Apologies in advance if the following comes across as a bit of >> rigid thinking for a corner case but unfortunately there is now an example. >> A larger standard question is how to correctly process a fieldValue >> statement with a default value for the value attribute. >> The XML schema for fieldValue says that the default value for the value >> attribute is "", the empty string. Relying on that default is rarely, >> perhaps never, a useful use of fieldValue but is allowed. >> >> Scenario A) >> In the case the field for which such a fieldValue is given is of type >> SFTime, this would strictly mean that the value is invalid since the "" is >> not an encoding of a floating point number and does not pass the regex >> test. Therefore processing could become undefined and should be halted. >> >> Scenario B) >> Another, perhaps less strict but more useful interpretation is that the >> empty string for SFTime signals the lack of a value and that therefore a >> default value for the SFTime field should be adopted. This default could be >> an initial -1 as the Tooltips suggest, and would likely be overwritten. >> >> A) is stricter and follows the rules more literally. B) is perhaps >> more often what authors intend but may need some clarification in the >> specification. >> >> This applies only to the XML encoding. >> >> I think the XML encoding for fieldValue should require one of: an >> existing value attribute, or at least one child node (as a XFNode value). >> Not sure if the XML schema could handle that. >> >> Would you prefer A) or B) ? >> >> Personally A) with some error messages but some X3D browsers accept B). >> >> Thanks, Andreas >> >> >> On Sun, Feb 2, 2025 at 4:58?PM Andreas Plesch >> wrote: >> >>> I think x3dom, reasonably, expects a value for the fieldValue nodes: >>> >>> For example: >>> >>> >>> >>> and others. >>> >>> On Sun, Feb 2, 2025 at 5:42?AM John Carlson wrote: >>> >>>> Andreas, Joe, >>>> >>>> Reset Button, Reset_Clock added. >>>> >>>> See attached zip for details, or visit link; >>>> >>>> >>>> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>> >>>> For some reason, this link doesn't show the live scene? >>>> >>>> >>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>> >>>> Puzzled, haven't researched it yet. Looks good in Sunrize and X_ITE, >>>> will try FreeWRL next. >>>> >>>> John >>>> >>>>> >>> >>> -- >>> Andreas Plesch >>> Waltham, MA 02453 >>> >> >> >> -- >> Andreas Plesch >> Waltham, MA 02453 >> > -- Andreas Plesch Waltham, MA 02453 -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Mon Feb 3 08:24:35 2025 From: yottzumm at gmail.com (John Carlson) Date: Mon, 3 Feb 2025 10:24:35 -0600 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: Message-ID: That means another solution for outputOnly needs to be found, like passing the whole TimeSensor into the ProtoInstance and routing inside the ProtoBody. I?ll try and see if it works. Later. Code is currently here: https://github.com/coderextreme/ci2had/blob/main/python/manyclocks.py John On Mon, Feb 3, 2025 at 6:44?AM Andreas Plesch wrote: > Hi John, > > my only thought is that only A) - the strict scenario - can be relied upon > currently. > > Best, -Andreas > > On Mon, Feb 3, 2025 at 1:11?AM John Carlson wrote: > >> I have no problems with your thinking Andreas. My only questions are 1) >> Why am I chosen to find these corner cases? 2) Can Castle Model Viewer >> support ECMAScript soon, perhaps in an Electron or better WebView? 3) It >> would seem like ProtoInterface field accessType="outputOnly" needs to be >> treated specially. >> >> Primarily, I am concerned that A) alone will not solve 3) above and B) >> may be required. Castle Model Viewer already has A), which is helpful, but >> I don't have a workaround yet. >> >> On Sun, Feb 2, 2025 at 10:40?PM Andreas Plesch >> wrote: >> >>> Apologies in advance if the following comes across as a bit of >>> rigid thinking for a corner case but unfortunately there is now an example. >>> A larger standard question is how to correctly process a fieldValue >>> statement with a default value for the value attribute. >>> The XML schema for fieldValue says that the default value for the value >>> attribute is "", the empty string. Relying on that default is rarely, >>> perhaps never, a useful use of fieldValue but is allowed. >>> >>> Scenario A) >>> In the case the field for which such a fieldValue is given is of type >>> SFTime, this would strictly mean that the value is invalid since the "" is >>> not an encoding of a floating point number and does not pass the regex >>> test. Therefore processing could become undefined and should be halted. >>> >>> Scenario B) >>> Another, perhaps less strict but more useful interpretation is that the >>> empty string for SFTime signals the lack of a value and that therefore a >>> default value for the SFTime field should be adopted. This default could be >>> an initial -1 as the Tooltips suggest, and would likely be overwritten. >>> >>> A) is stricter and follows the rules more literally. B) is perhaps >>> more often what authors intend but may need some clarification in the >>> specification. >>> >>> This applies only to the XML encoding. >>> >>> I think the XML encoding for fieldValue should require one of: an >>> existing value attribute, or at least one child node (as a XFNode value). >>> Not sure if the XML schema could handle that. >>> >>> Would you prefer A) or B) ? >>> >>> Personally A) with some error messages but some X3D browsers accept B). >>> >>> Thanks, Andreas >>> >>> >>> On Sun, Feb 2, 2025 at 4:58?PM Andreas Plesch >>> wrote: >>> >>>> I think x3dom, reasonably, expects a value for the fieldValue nodes: >>>> >>>> For example: >>>> >>>> >>>> >>>> and others. >>>> >>>> On Sun, Feb 2, 2025 at 5:42?AM John Carlson wrote: >>>> >>>>> Andreas, Joe, >>>>> >>>>> Reset Button, Reset_Clock added. >>>>> >>>>> See attached zip for details, or visit link; >>>>> >>>>> >>>>> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>> >>>>> For some reason, this link doesn't show the live scene? >>>>> >>>>> >>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>> >>>>> Puzzled, haven't researched it yet. Looks good in Sunrize and X_ITE, >>>>> will try FreeWRL next. >>>>> >>>>> John >>>>> >>>>>> >>>> >>>> -- >>>> Andreas Plesch >>>> Waltham, MA 02453 >>>> >>> >>> >>> -- >>> Andreas Plesch >>> Waltham, MA 02453 >>> >> > > -- > Andreas Plesch > Waltham, MA 02453 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Mon Feb 3 22:56:28 2025 From: yottzumm at gmail.com (John Carlson) Date: Tue, 4 Feb 2025 00:56:28 -0600 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: Message-ID: Indeed, moving the TimeSensor USE to a fieldValue makes Castle report this: castle-model-converter: Warning: X3D: Route destination node name "clock" not found castle-model-converter: Warning: X3D: Route destination node name "clock" not found castle-model-converter: Warning: X3D: Route destination node name "clock" not found Seems like I've made a full circle. Now I can't get anything to work. So option B) sounds really good, and I'll just recommend Sunrize, or do scripting. What I can try to do is provide an initializer value to clock in ProtoInterface. see attachment. John On Mon, Feb 3, 2025 at 12:11?AM John Carlson wrote: > I have no problems with your thinking Andreas. My only questions are 1) > Why am I chosen to find these corner cases? 2) Can Castle Model Viewer > support ECMAScript soon, perhaps in an Electron or better WebView? 3) It > would seem like ProtoInterface field accessType="outputOnly" needs to be > treated specially. > > Primarily, I am concerned that A) alone will not solve 3) above and B) may > be required. Castle Model Viewer already has A), which is helpful, but I > don't have a workaround yet. > > On Sun, Feb 2, 2025 at 10:40?PM Andreas Plesch > wrote: > >> Apologies in advance if the following comes across as a bit of >> rigid thinking for a corner case but unfortunately there is now an example. >> A larger standard question is how to correctly process a fieldValue >> statement with a default value for the value attribute. >> The XML schema for fieldValue says that the default value for the value >> attribute is "", the empty string. Relying on that default is rarely, >> perhaps never, a useful use of fieldValue but is allowed. >> >> Scenario A) >> In the case the field for which such a fieldValue is given is of type >> SFTime, this would strictly mean that the value is invalid since the "" is >> not an encoding of a floating point number and does not pass the regex >> test. Therefore processing could become undefined and should be halted. >> >> Scenario B) >> Another, perhaps less strict but more useful interpretation is that the >> empty string for SFTime signals the lack of a value and that therefore a >> default value for the SFTime field should be adopted. This default could be >> an initial -1 as the Tooltips suggest, and would likely be overwritten. >> >> A) is stricter and follows the rules more literally. B) is perhaps >> more often what authors intend but may need some clarification in the >> specification. >> >> This applies only to the XML encoding. >> >> I think the XML encoding for fieldValue should require one of: an >> existing value attribute, or at least one child node (as a XFNode value). >> Not sure if the XML schema could handle that. >> >> Would you prefer A) or B) ? >> >> Personally A) with some error messages but some X3D browsers accept B). >> >> Thanks, Andreas >> >> >> On Sun, Feb 2, 2025 at 4:58?PM Andreas Plesch >> wrote: >> >>> I think x3dom, reasonably, expects a value for the fieldValue nodes: >>> >>> For example: >>> >>> >>> >>> and others. >>> >>> On Sun, Feb 2, 2025 at 5:42?AM John Carlson wrote: >>> >>>> Andreas, Joe, >>>> >>>> Reset Button, Reset_Clock added. >>>> >>>> See attached zip for details, or visit link; >>>> >>>> >>>> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>> >>>> For some reason, this link doesn't show the live scene? >>>> >>>> >>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>> >>>> Puzzled, haven't researched it yet. Looks good in Sunrize and X_ITE, >>>> will try FreeWRL next. >>>> >>>> John >>>> >>>>> >>> >>> -- >>> Andreas Plesch >>> Waltham, MA 02453 >>> >> >> >> -- >> Andreas Plesch >> Waltham, MA 02453 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Clocks5.zip Type: application/x-zip-compressed Size: 249729 bytes Desc: not available URL: From yottzumm at gmail.com Mon Feb 3 23:01:57 2025 From: yottzumm at gmail.com (John Carlson) Date: Tue, 4 Feb 2025 01:01:57 -0600 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: Message-ID: Note that I've added this to the ProtoInterface with same results: Hmm! John On Tue, Feb 4, 2025 at 12:56?AM John Carlson wrote: > Indeed, moving the TimeSensor USE to a fieldValue makes Castle report > this: > > castle-model-converter: Warning: X3D: Route destination node name "clock" > not found > castle-model-converter: Warning: X3D: Route destination node name "clock" > not found > castle-model-converter: Warning: X3D: Route destination node name "clock" > not found > > > Seems like I've made a full circle. Now I can't get anything to work. > > So option B) sounds really good, and I'll just recommend Sunrize, or do > scripting. > > What I can try to do is provide an initializer value to clock in > ProtoInterface. > > see attachment. > > John > > On Mon, Feb 3, 2025 at 12:11?AM John Carlson wrote: > >> I have no problems with your thinking Andreas. My only questions are 1) >> Why am I chosen to find these corner cases? 2) Can Castle Model Viewer >> support ECMAScript soon, perhaps in an Electron or better WebView? 3) It >> would seem like ProtoInterface field accessType="outputOnly" needs to be >> treated specially. >> >> Primarily, I am concerned that A) alone will not solve 3) above and B) >> may be required. Castle Model Viewer already has A), which is helpful, but >> I don't have a workaround yet. >> >> On Sun, Feb 2, 2025 at 10:40?PM Andreas Plesch >> wrote: >> >>> Apologies in advance if the following comes across as a bit of >>> rigid thinking for a corner case but unfortunately there is now an example. >>> A larger standard question is how to correctly process a fieldValue >>> statement with a default value for the value attribute. >>> The XML schema for fieldValue says that the default value for the value >>> attribute is "", the empty string. Relying on that default is rarely, >>> perhaps never, a useful use of fieldValue but is allowed. >>> >>> Scenario A) >>> In the case the field for which such a fieldValue is given is of type >>> SFTime, this would strictly mean that the value is invalid since the "" is >>> not an encoding of a floating point number and does not pass the regex >>> test. Therefore processing could become undefined and should be halted. >>> >>> Scenario B) >>> Another, perhaps less strict but more useful interpretation is that the >>> empty string for SFTime signals the lack of a value and that therefore a >>> default value for the SFTime field should be adopted. This default could be >>> an initial -1 as the Tooltips suggest, and would likely be overwritten. >>> >>> A) is stricter and follows the rules more literally. B) is perhaps >>> more often what authors intend but may need some clarification in the >>> specification. >>> >>> This applies only to the XML encoding. >>> >>> I think the XML encoding for fieldValue should require one of: an >>> existing value attribute, or at least one child node (as a XFNode value). >>> Not sure if the XML schema could handle that. >>> >>> Would you prefer A) or B) ? >>> >>> Personally A) with some error messages but some X3D browsers accept B). >>> >>> Thanks, Andreas >>> >>> >>> On Sun, Feb 2, 2025 at 4:58?PM Andreas Plesch >>> wrote: >>> >>>> I think x3dom, reasonably, expects a value for the fieldValue nodes: >>>> >>>> For example: >>>> >>>> >>>> >>>> and others. >>>> >>>> On Sun, Feb 2, 2025 at 5:42?AM John Carlson wrote: >>>> >>>>> Andreas, Joe, >>>>> >>>>> Reset Button, Reset_Clock added. >>>>> >>>>> See attached zip for details, or visit link; >>>>> >>>>> >>>>> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>> >>>>> For some reason, this link doesn't show the live scene? >>>>> >>>>> >>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>> >>>>> Puzzled, haven't researched it yet. Looks good in Sunrize and X_ITE, >>>>> will try FreeWRL next. >>>>> >>>>> John >>>>> >>>>>> >>>> >>>> -- >>>> Andreas Plesch >>>> Waltham, MA 02453 >>>> >>> >>> >>> -- >>> Andreas Plesch >>> Waltham, MA 02453 >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreasplesch at gmail.com Tue Feb 4 10:26:40 2025 From: andreasplesch at gmail.com (Andreas Plesch) Date: Tue, 4 Feb 2025 13:26:40 -0500 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: Message-ID: Hi John, all, It turns out that x3dom currently expects a default value for Proto fields even for outputOnly fields. This is due to how Proto fields are initialized. They always need to have a value. While the spec. does not require this, it seems still good practice to always define a default value in the ProtoInterface. There may be a case where an outputOnly field is used in ISing where a valid value would be expected. There may be other corner cases. Here is your example with added default values for outputOnly fields: https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/af5ff3148c1159f71d34fb78c1f63024/raw/b3d4470107ab74e301ed48448ab2a4f4154672e0/ManyClocks_John.x3d This could be fixed in x3dom, by always setting some default value. Is there a list of recommended defaults for each data type if no other source of defaults is available? For SFTime it seems to be -1. -Andreas On Mon, Feb 3, 2025 at 7:39?AM Andreas Plesch wrote: > Hi John, > > On Mon, Feb 3, 2025 at 12:48?AM John Carlson wrote: > >> Andreas, "startTime" is an accessType outputOnly field, so why do I need >> to provide a value attribute in fieldValue? I'm kind of confused. I'm >> probably missing something in the spec. >> > > You are right, I only outlined scenarios where the accessType allows input > or initialization.. > In the outputOnly case it is not necessary to provide a fieldValue node at > all since there is no value which can be provided. Providing the node would > indeed be confusing, to both the user code reader and any X3D browser. > I believe the spec. is silent on this case in any encoding. > > Best, Andreas > > Thanks for any clarification. >> >> I have finally enabled schematron on the project, but I'm finding it hard >> to understand the messages, and modifications that I make, while removing >> the immediate problems, seem to move the problems elsewhere. >> >> Explaining why I need a "startTime" fieldValue value is my main lack of >> understanding, but perhaps I need a whole review of accessType. >> >> Castle Model Converter reports: >> >> castle-model-converter: Warning: X3D: X3D XML: element >> references unknown field name "enabled" >> castle-model-converter: Warning: X3D: X3D XML: element >> references unknown field name "startTime" >> castle-model-converter: Warning: X3D: X3D XML: element >> references unknown field name "stopTime" >> >> I will try providing a field value in the ProtoInterface >> >> If I "cleanup" enabled, startTime and stopTime, I get: >> >> castle-model-converter: Warning: VRML/X3D: Within prototype "MenuItem", >> event "inputTrue" references (by "IS" clause) non-existing event "enabled" >> castle-model-converter: Warning: VRML/X3D: Within prototype "MenuItem", >> event "triggerTime" references (by "IS" clause) non-existing event >> "startTime" >> castle-model-converter: Warning: VRML/X3D: Within prototype "MenuItem", >> event "triggerTime" references (by "IS" clause) non-existing event >> "stopTime" >> >> I guess what I conclude at this point is, startTime and stopTime are bad >> DEF names, but what about enabled as a field? The dominoes are falling. >> >> About your two scenarios in the other message, perhaps this is revealing. >> >> See attached attempt to fix original issue, which resulted in the above. >> >> John >> >> On Sun, Feb 2, 2025 at 3:59?PM Andreas Plesch >> wrote: >> >>> I think x3dom, reasonably, expects a value for the fieldValue nodes: >>> >>> For example: >>> >>> >>> >>> and others. >>> >>> On Sun, Feb 2, 2025 at 5:42?AM John Carlson wrote: >>> >>>> Andreas, Joe, >>>> >>>> Reset Button, Reset_Clock added. >>>> >>>> See attached zip for details, or visit link; >>>> >>>> >>>> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>> >>>> For some reason, this link doesn't show the live scene? >>>> >>>> >>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>> >>>> Puzzled, haven't researched it yet. Looks good in Sunrize and X_ITE, >>>> will try FreeWRL next. >>>> >>>> John >>>> >>>>> >>> >>> -- >>> Andreas Plesch >>> Waltham, MA 02453 >>> >> > > -- > Andreas Plesch > Waltham, MA 02453 > -- Andreas Plesch Waltham, MA 02453 -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger.seelig at yahoo.de Tue Feb 4 11:01:36 2025 From: holger.seelig at yahoo.de (Holger Seelig) Date: Tue, 4 Feb 2025 20:01:36 +0100 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: Message-ID: <2572A7BF-F34E-480C-9DB1-25F51D84AA61@yahoo.de> The default value for a field is either specified for each node type or the default value for Script or ComposedShader node custom fields is defined in https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/fieldTypes.html. Mostly false, 0, ??, identity, ... A proto instance will inherit its default values from the proto declaration its fields. Fields such as outputOnly will normally have a default value from fieldTypes.html. There is an exception with X3DInterpolatorNode.value_changed: https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/interpolators.html#X3DInterpolatorNode If an X3DInterpolatorNode value_changed outputOnly field is read before it receives any inputs, keyValue[0] is returned if keyValue is not empty... Best regards, Holger -- Holger Seelig Leipzig, Germany holger.seelig at yahoo.de https://create3000.github.io/x_ite/ > Am 04.02.2025 um 19:26 schrieb Andreas Plesch via x3d-public : > > Hi John, all, > > It turns out that x3dom currently expects a default value for Proto fields even for outputOnly fields. This is due to how Proto fields are initialized. They always need to have a value. While the spec. does not require this, it seems still good practice to always define a default value in the ProtoInterface. There may be a case where an outputOnly field is used in ISing where a valid value would be expected. There may be other corner cases. > > Here is your example with added default values for outputOnly fields: > > https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/af5ff3148c1159f71d34fb78c1f63024/raw/b3d4470107ab74e301ed48448ab2a4f4154672e0/ManyClocks_John.x3d > > This could be fixed in x3dom, by always setting some default value. Is there a list of recommended defaults for each data type if no other source of defaults is available? For SFTime it seems to be -1. > > -Andreas > > > On Mon, Feb 3, 2025 at 7:39?AM Andreas Plesch > wrote: >> Hi John, >> >> On Mon, Feb 3, 2025 at 12:48?AM John Carlson > wrote: >>> Andreas, "startTime" is an accessType outputOnly field, so why do I need to provide a value attribute in fieldValue? I'm kind of confused. I'm probably missing something in the spec. >> >> You are right, I only outlined scenarios where the accessType allows input or initialization.. >> In the outputOnly case it is not necessary to provide a fieldValue node at all since there is no value which can be provided. Providing the node would indeed be confusing, to both the user code reader and any X3D browser. >> I believe the spec. is silent on this case in any encoding. >> >> Best, Andreas >> >>> Thanks for any clarification. >>> >>> I have finally enabled schematron on the project, but I'm finding it hard to understand the messages, and modifications that I make, while removing the immediate problems, seem to move the problems elsewhere. >>> >>> Explaining why I need a "startTime" fieldValue value is my main lack of understanding, but perhaps I need a whole review of accessType. >>> >>> Castle Model Converter reports: >>> >>> castle-model-converter: Warning: X3D: X3D XML: element references unknown field name "enabled" >>> castle-model-converter: Warning: X3D: X3D XML: element references unknown field name "startTime" >>> castle-model-converter: Warning: X3D: X3D XML: element references unknown field name "stopTime" >>> >>> I will try providing a field value in the ProtoInterface >>> >>> If I "cleanup" enabled, startTime and stopTime, I get: >>> >>> castle-model-converter: Warning: VRML/X3D: Within prototype "MenuItem", event "inputTrue" references (by "IS" clause) non-existing event "enabled" >>> castle-model-converter: Warning: VRML/X3D: Within prototype "MenuItem", event "triggerTime" references (by "IS" clause) non-existing event "startTime" >>> castle-model-converter: Warning: VRML/X3D: Within prototype "MenuItem", event "triggerTime" references (by "IS" clause) non-existing event "stopTime" >>> >>> I guess what I conclude at this point is, startTime and stopTime are bad DEF names, but what about enabled as a field? The dominoes are falling. >>> >>> About your two scenarios in the other message, perhaps this is revealing. >>> >>> See attached attempt to fix original issue, which resulted in the above. >>> >>> John >>> >>> On Sun, Feb 2, 2025 at 3:59?PM Andreas Plesch > wrote: >>>> I think x3dom, reasonably, expects a value for the fieldValue nodes: >>>> >>>> For example: >>>> >>>> >>>> >>>> and others. >>>> >>>> On Sun, Feb 2, 2025 at 5:42?AM John Carlson > wrote: >>>>> Andreas, Joe, >>>>> >>>>> Reset Button, Reset_Clock added. >>>>> >>>>> See attached zip for details, or visit link; >>>>> >>>>> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>> >>>>> For some reason, this link doesn't show the live scene? >>>>> >>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>> >>>>> Puzzled, haven't researched it yet. Looks good in Sunrize and X_ITE, will try FreeWRL next. >>>>> >>>>> John >>>> >>>> >>>> >>>> -- >>>> Andreas Plesch >>>> Waltham, MA 02453 >> >> >> >> -- >> Andreas Plesch >> Waltham, MA 02453 > > > > -- > Andreas Plesch > Waltham, MA 02453 > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Tue Feb 4 11:33:33 2025 From: yottzumm at gmail.com (John Carlson) Date: Tue, 4 Feb 2025 13:33:33 -0600 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: Message-ID: I will try to test this in castle model converter. I did try setting a value for the outputOnly fields, but the converter wouldn?t shut up. The model below doesn?t seem to animate when one presses the menu items. Did you get it to animate? On Tue, Feb 4, 2025 at 12:27?PM Andreas Plesch wrote: > Hi John, all, > > It turns out that x3dom currently expects a default value for Proto fields > even for outputOnly fields. This is due to how Proto fields are > initialized. They always need to have a value. While the spec. does not > require this, it seems still good practice to always define a default value > in the ProtoInterface. There may be a case where an outputOnly field is > used in ISing where a valid value would be expected. There may be other > corner cases. > > Here is your example with added default values for outputOnly fields: > > > https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/af5ff3148c1159f71d34fb78c1f63024/raw/b3d4470107ab74e301ed48448ab2a4f4154672e0/ManyClocks_John.x3d > > This could be fixed in x3dom, by always setting some default value. Is > there a list of recommended defaults for each data type if no other source > of defaults is available? For SFTime it seems to be -1. > > > -Andreas > > > On Mon, Feb 3, 2025 at 7:39?AM Andreas Plesch > wrote: > >> Hi John, >> >> On Mon, Feb 3, 2025 at 12:48?AM John Carlson wrote: >> >>> Andreas, "startTime" is an accessType outputOnly field, so why do I need >>> to provide a value attribute in fieldValue? I'm kind of confused. I'm >>> probably missing something in the spec. >>> >> >> You are right, I only outlined scenarios where the accessType allows >> input or initialization.. >> In the outputOnly case it is not necessary to provide a fieldValue node >> at all since there is no value which can be provided. Providing the node >> would indeed be confusing, to both the user code reader and any X3D browser. >> I believe the spec. is silent on this case in any encoding. >> >> Best, Andreas >> >> Thanks for any clarification. >>> >>> I have finally enabled schematron on the project, but I'm finding it >>> hard to understand the messages, and modifications that I make, while >>> removing the immediate problems, seem to move the problems elsewhere. >>> >>> Explaining why I need a "startTime" fieldValue value is my main lack of >>> understanding, but perhaps I need a whole review of accessType. >>> >>> Castle Model Converter reports: >>> >>> castle-model-converter: Warning: X3D: X3D XML: element >>> references unknown field name "enabled" >>> castle-model-converter: Warning: X3D: X3D XML: element >>> references unknown field name "startTime" >>> castle-model-converter: Warning: X3D: X3D XML: element >>> references unknown field name "stopTime" >>> >>> I will try providing a field value in the ProtoInterface >>> >>> If I "cleanup" enabled, startTime and stopTime, I get: >>> >>> castle-model-converter: Warning: VRML/X3D: Within prototype "MenuItem", >>> event "inputTrue" references (by "IS" clause) non-existing event "enabled" >>> castle-model-converter: Warning: VRML/X3D: Within prototype "MenuItem", >>> event "triggerTime" references (by "IS" clause) non-existing event >>> "startTime" >>> castle-model-converter: Warning: VRML/X3D: Within prototype "MenuItem", >>> event "triggerTime" references (by "IS" clause) non-existing event >>> "stopTime" >>> >>> I guess what I conclude at this point is, startTime and stopTime are bad >>> DEF names, but what about enabled as a field? The dominoes are falling. >>> >>> About your two scenarios in the other message, perhaps this is revealing. >>> >>> See attached attempt to fix original issue, which resulted in the above. >>> >>> John >>> >>> On Sun, Feb 2, 2025 at 3:59?PM Andreas Plesch >>> wrote: >>> >>>> I think x3dom, reasonably, expects a value for the fieldValue nodes: >>>> >>>> For example: >>>> >>>> >>>> >>>> and others. >>>> >>>> On Sun, Feb 2, 2025 at 5:42?AM John Carlson wrote: >>>> >>>>> Andreas, Joe, >>>>> >>>>> Reset Button, Reset_Clock added. >>>>> >>>>> See attached zip for details, or visit link; >>>>> >>>>> >>>>> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>> >>>>> For some reason, this link doesn't show the live scene? >>>>> >>>>> >>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>> >>>>> Puzzled, haven't researched it yet. Looks good in Sunrize and X_ITE, >>>>> will try FreeWRL next. >>>>> >>>>> John >>>>> >>>>>> >>>> >>>> -- >>>> Andreas Plesch >>>> Waltham, MA 02453 >>>> >>> >> >> -- >> Andreas Plesch >> Waltham, MA 02453 >> > > > -- > Andreas Plesch > Waltham, MA 02453 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Tue Feb 4 11:39:50 2025 From: yottzumm at gmail.com (John Carlson) Date: Tue, 4 Feb 2025 13:39:50 -0600 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: <2572A7BF-F34E-480C-9DB1-25F51D84AA61@yahoo.de> References: <2572A7BF-F34E-480C-9DB1-25F51D84AA61@yahoo.de> Message-ID: I didn?t try setting the values in the ProtoInterface without also setting the values in the ProtoInstance. That?s another thing to try. John On Tue, Feb 4, 2025 at 1:01?PM Holger Seelig wrote: > The default value for a field is either specified for each node type or > the default value for Script or ComposedShader node custom fields is > defined in > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/fieldTypes.html. > Mostly false, 0, ??, identity, ... > > A proto instance will inherit its default values from the proto > declaration its fields. Fields such as outputOnly will normally have a > default value from fieldTypes.html. > > There is an exception with X3DInterpolatorNode.value_changed: > > > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/interpolators.html#X3DInterpolatorNode > > If an X3DInterpolatorNode value_changed outputOnly field is read before it > receives any inputs, keyValue[0] is returned if keyValue is not empty... > > Best regards, > Holger > > -- > Holger Seelig > Leipzig, Germany > > holger.seelig at yahoo.de > https://create3000.github.io/x_ite/ > > Am 04.02.2025 um 19:26 schrieb Andreas Plesch via x3d-public < > x3d-public at web3d.org>: > > Hi John, all, > > It turns out that x3dom currently expects a default value for Proto fields > even for outputOnly fields. This is due to how Proto fields are > initialized. They always need to have a value. While the spec. does not > require this, it seems still good practice to always define a default value > in the ProtoInterface. There may be a case where an outputOnly field is > used in ISing where a valid value would be expected. There may be other > corner cases. > > Here is your example with added default values for outputOnly fields: > > > https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/af5ff3148c1159f71d34fb78c1f63024/raw/b3d4470107ab74e301ed48448ab2a4f4154672e0/ManyClocks_John.x3d > > This could be fixed in x3dom, by always setting some default value. Is > there a list of recommended defaults for each data type if no other source > of defaults is available? For SFTime it seems to be -1. > > -Andreas > > > On Mon, Feb 3, 2025 at 7:39?AM Andreas Plesch > wrote: > >> Hi John, >> >> On Mon, Feb 3, 2025 at 12:48?AM John Carlson wrote: >> >>> Andreas, "startTime" is an accessType outputOnly field, so why do I need >>> to provide a value attribute in fieldValue? I'm kind of confused. I'm >>> probably missing something in the spec. >>> >> >> You are right, I only outlined scenarios where the accessType allows >> input or initialization.. >> In the outputOnly case it is not necessary to provide a fieldValue node >> at all since there is no value which can be provided. Providing the node >> would indeed be confusing, to both the user code reader and any X3D browser. >> I believe the spec. is silent on this case in any encoding. >> >> Best, Andreas >> >> Thanks for any clarification. >>> >>> I have finally enabled schematron on the project, but I'm finding it >>> hard to understand the messages, and modifications that I make, while >>> removing the immediate problems, seem to move the problems elsewhere. >>> >>> Explaining why I need a "startTime" fieldValue value is my main lack of >>> understanding, but perhaps I need a whole review of accessType. >>> >>> Castle Model Converter reports: >>> >>> castle-model-converter: Warning: X3D: X3D XML: element >>> references unknown field name "enabled" >>> castle-model-converter: Warning: X3D: X3D XML: element >>> references unknown field name "startTime" >>> castle-model-converter: Warning: X3D: X3D XML: element >>> references unknown field name "stopTime" >>> >>> I will try providing a field value in the ProtoInterface >>> >>> If I "cleanup" enabled, startTime and stopTime, I get: >>> >>> castle-model-converter: Warning: VRML/X3D: Within prototype "MenuItem", >>> event "inputTrue" references (by "IS" clause) non-existing event "enabled" >>> castle-model-converter: Warning: VRML/X3D: Within prototype "MenuItem", >>> event "triggerTime" references (by "IS" clause) non-existing event >>> "startTime" >>> castle-model-converter: Warning: VRML/X3D: Within prototype "MenuItem", >>> event "triggerTime" references (by "IS" clause) non-existing event >>> "stopTime" >>> >>> I guess what I conclude at this point is, startTime and stopTime are bad >>> DEF names, but what about enabled as a field? The dominoes are falling. >>> >>> About your two scenarios in the other message, perhaps this is revealing. >>> >>> See attached attempt to fix original issue, which resulted in the above. >>> >>> John >>> >>> On Sun, Feb 2, 2025 at 3:59?PM Andreas Plesch >>> wrote: >>> >>>> I think x3dom, reasonably, expects a value for the fieldValue nodes: >>>> >>>> For example: >>>> >>>> >>>> >>>> and others. >>>> >>>> On Sun, Feb 2, 2025 at 5:42?AM John Carlson wrote: >>>> >>>>> Andreas, Joe, >>>>> >>>>> Reset Button, Reset_Clock added. >>>>> >>>>> See attached zip for details, or visit link; >>>>> >>>>> >>>>> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>> >>>>> For some reason, this link doesn't show the live scene? >>>>> >>>>> >>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>> >>>>> Puzzled, haven't researched it yet. Looks good in Sunrize and X_ITE, >>>>> will try FreeWRL next. >>>>> >>>>> John >>>>> >>>>>> >>>> >>>> -- >>>> Andreas Plesch >>>> Waltham, MA 02453 >>>> >>> >> >> -- >> Andreas Plesch >> Waltham, MA 02453 >> > > > -- > Andreas Plesch > Waltham, MA 02453 > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Tue Feb 4 11:55:42 2025 From: yottzumm at gmail.com (John Carlson) Date: Tue, 4 Feb 2025 13:55:42 -0600 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: <2572A7BF-F34E-480C-9DB1-25F51D84AA61@yahoo.de> References: <2572A7BF-F34E-480C-9DB1-25F51D84AA61@yahoo.de> Message-ID: I can confirm that SFTime fields are defaulted to -1 as Holger says: https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/fieldTypes.html#SFTimeAndMFTime See last paragraph John On Tue, Feb 4, 2025 at 1:01?PM Holger Seelig wrote: > The default value for a field is either specified for each node type or > the default value for Script or ComposedShader node custom fields is > defined in > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/fieldTypes.html. > Mostly false, 0, ??, identity, ... > > A proto instance will inherit its default values from the proto > declaration its fields. Fields such as outputOnly will normally have a > default value from fieldTypes.html. > > There is an exception with X3DInterpolatorNode.value_changed: > > > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/interpolators.html#X3DInterpolatorNode > > If an X3DInterpolatorNode value_changed outputOnly field is read before it > receives any inputs, keyValue[0] is returned if keyValue is not empty... > > Best regards, > Holger > > -- > Holger Seelig > Leipzig, Germany > > holger.seelig at yahoo.de > https://create3000.github.io/x_ite/ > > Am 04.02.2025 um 19:26 schrieb Andreas Plesch via x3d-public < > x3d-public at web3d.org>: > > Hi John, all, > > It turns out that x3dom currently expects a default value for Proto fields > even for outputOnly fields. This is due to how Proto fields are > initialized. They always need to have a value. While the spec. does not > require this, it seems still good practice to always define a default value > in the ProtoInterface. There may be a case where an outputOnly field is > used in ISing where a valid value would be expected. There may be other > corner cases. > > Here is your example with added default values for outputOnly fields: > > > https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/af5ff3148c1159f71d34fb78c1f63024/raw/b3d4470107ab74e301ed48448ab2a4f4154672e0/ManyClocks_John.x3d > > This could be fixed in x3dom, by always setting some default value. Is > there a list of recommended defaults for each data type if no other source > of defaults is available? For SFTime it seems to be -1. > > -Andreas > > > On Mon, Feb 3, 2025 at 7:39?AM Andreas Plesch > wrote: > >> Hi John, >> >> On Mon, Feb 3, 2025 at 12:48?AM John Carlson wrote: >> >>> Andreas, "startTime" is an accessType outputOnly field, so why do I need >>> to provide a value attribute in fieldValue? I'm kind of confused. I'm >>> probably missing something in the spec. >>> >> >> You are right, I only outlined scenarios where the accessType allows >> input or initialization.. >> In the outputOnly case it is not necessary to provide a fieldValue node >> at all since there is no value which can be provided. Providing the node >> would indeed be confusing, to both the user code reader and any X3D browser. >> I believe the spec. is silent on this case in any encoding. >> >> Best, Andreas >> >> Thanks for any clarification. >>> >>> I have finally enabled schematron on the project, but I'm finding it >>> hard to understand the messages, and modifications that I make, while >>> removing the immediate problems, seem to move the problems elsewhere. >>> >>> Explaining why I need a "startTime" fieldValue value is my main lack of >>> understanding, but perhaps I need a whole review of accessType. >>> >>> Castle Model Converter reports: >>> >>> castle-model-converter: Warning: X3D: X3D XML: element >>> references unknown field name "enabled" >>> castle-model-converter: Warning: X3D: X3D XML: element >>> references unknown field name "startTime" >>> castle-model-converter: Warning: X3D: X3D XML: element >>> references unknown field name "stopTime" >>> >>> I will try providing a field value in the ProtoInterface >>> >>> If I "cleanup" enabled, startTime and stopTime, I get: >>> >>> castle-model-converter: Warning: VRML/X3D: Within prototype "MenuItem", >>> event "inputTrue" references (by "IS" clause) non-existing event "enabled" >>> castle-model-converter: Warning: VRML/X3D: Within prototype "MenuItem", >>> event "triggerTime" references (by "IS" clause) non-existing event >>> "startTime" >>> castle-model-converter: Warning: VRML/X3D: Within prototype "MenuItem", >>> event "triggerTime" references (by "IS" clause) non-existing event >>> "stopTime" >>> >>> I guess what I conclude at this point is, startTime and stopTime are bad >>> DEF names, but what about enabled as a field? The dominoes are falling. >>> >>> About your two scenarios in the other message, perhaps this is revealing. >>> >>> See attached attempt to fix original issue, which resulted in the above. >>> >>> John >>> >>> On Sun, Feb 2, 2025 at 3:59?PM Andreas Plesch >>> wrote: >>> >>>> I think x3dom, reasonably, expects a value for the fieldValue nodes: >>>> >>>> For example: >>>> >>>> >>>> >>>> and others. >>>> >>>> On Sun, Feb 2, 2025 at 5:42?AM John Carlson wrote: >>>> >>>>> Andreas, Joe, >>>>> >>>>> Reset Button, Reset_Clock added. >>>>> >>>>> See attached zip for details, or visit link; >>>>> >>>>> >>>>> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>> >>>>> For some reason, this link doesn't show the live scene? >>>>> >>>>> >>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>> >>>>> Puzzled, haven't researched it yet. Looks good in Sunrize and X_ITE, >>>>> will try FreeWRL next. >>>>> >>>>> John >>>>> >>>>>> >>>> >>>> -- >>>> Andreas Plesch >>>> Waltham, MA 02453 >>>> >>> >> >> -- >> Andreas Plesch >> Waltham, MA 02453 >> > > > -- > Andreas Plesch > Waltham, MA 02453 > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreasplesch at gmail.com Tue Feb 4 12:22:04 2025 From: andreasplesch at gmail.com (Andreas Plesch) Date: Tue, 4 Feb 2025 15:22:04 -0500 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: <2572A7BF-F34E-480C-9DB1-25F51D84AA61@yahoo.de> References: <2572A7BF-F34E-480C-9DB1-25F51D84AA61@yahoo.de> Message-ID: Thanks, exactly what I was looking for. Best, Andreas On Tue, Feb 4, 2025, 2:01?PM Holger Seelig wrote: > The default value for a field is either specified for each node type or > the default value for Script or ComposedShader node custom fields is > defined in > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/fieldTypes.html. > Mostly false, 0, ??, identity, ... > > A proto instance will inherit its default values from the proto > declaration its fields. Fields such as outputOnly will normally have a > default value from fieldTypes.html. > > There is an exception with X3DInterpolatorNode.value_changed: > > > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/interpolators.html#X3DInterpolatorNode > > If an X3DInterpolatorNode value_changed outputOnly field is read before it > receives any inputs, keyValue[0] is returned if keyValue is not empty... > > Best regards, > Holger > > -- > Holger Seelig > Leipzig, Germany > > holger.seelig at yahoo.de > https://create3000.github.io/x_ite/ > > Am 04.02.2025 um 19:26 schrieb Andreas Plesch via x3d-public < > x3d-public at web3d.org>: > > Hi John, all, > > It turns out that x3dom currently expects a default value for Proto fields > even for outputOnly fields. This is due to how Proto fields are > initialized. They always need to have a value. While the spec. does not > require this, it seems still good practice to always define a default value > in the ProtoInterface. There may be a case where an outputOnly field is > used in ISing where a valid value would be expected. There may be other > corner cases. > > Here is your example with added default values for outputOnly fields: > > > https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/af5ff3148c1159f71d34fb78c1f63024/raw/b3d4470107ab74e301ed48448ab2a4f4154672e0/ManyClocks_John.x3d > > This could be fixed in x3dom, by always setting some default value. Is > there a list of recommended defaults for each data type if no other source > of defaults is available? For SFTime it seems to be -1. > > -Andreas > > > On Mon, Feb 3, 2025 at 7:39?AM Andreas Plesch > wrote: > >> Hi John, >> >> On Mon, Feb 3, 2025 at 12:48?AM John Carlson wrote: >> >>> Andreas, "startTime" is an accessType outputOnly field, so why do I need >>> to provide a value attribute in fieldValue? I'm kind of confused. I'm >>> probably missing something in the spec. >>> >> >> You are right, I only outlined scenarios where the accessType allows >> input or initialization.. >> In the outputOnly case it is not necessary to provide a fieldValue node >> at all since there is no value which can be provided. Providing the node >> would indeed be confusing, to both the user code reader and any X3D browser. >> I believe the spec. is silent on this case in any encoding. >> >> Best, Andreas >> >> Thanks for any clarification. >>> >>> I have finally enabled schematron on the project, but I'm finding it >>> hard to understand the messages, and modifications that I make, while >>> removing the immediate problems, seem to move the problems elsewhere. >>> >>> Explaining why I need a "startTime" fieldValue value is my main lack of >>> understanding, but perhaps I need a whole review of accessType. >>> >>> Castle Model Converter reports: >>> >>> castle-model-converter: Warning: X3D: X3D XML: element >>> references unknown field name "enabled" >>> castle-model-converter: Warning: X3D: X3D XML: element >>> references unknown field name "startTime" >>> castle-model-converter: Warning: X3D: X3D XML: element >>> references unknown field name "stopTime" >>> >>> I will try providing a field value in the ProtoInterface >>> >>> If I "cleanup" enabled, startTime and stopTime, I get: >>> >>> castle-model-converter: Warning: VRML/X3D: Within prototype "MenuItem", >>> event "inputTrue" references (by "IS" clause) non-existing event "enabled" >>> castle-model-converter: Warning: VRML/X3D: Within prototype "MenuItem", >>> event "triggerTime" references (by "IS" clause) non-existing event >>> "startTime" >>> castle-model-converter: Warning: VRML/X3D: Within prototype "MenuItem", >>> event "triggerTime" references (by "IS" clause) non-existing event >>> "stopTime" >>> >>> I guess what I conclude at this point is, startTime and stopTime are bad >>> DEF names, but what about enabled as a field? The dominoes are falling. >>> >>> About your two scenarios in the other message, perhaps this is revealing. >>> >>> See attached attempt to fix original issue, which resulted in the above. >>> >>> John >>> >>> On Sun, Feb 2, 2025 at 3:59?PM Andreas Plesch >>> wrote: >>> >>>> I think x3dom, reasonably, expects a value for the fieldValue nodes: >>>> >>>> For example: >>>> >>>> >>>> >>>> and others. >>>> >>>> On Sun, Feb 2, 2025 at 5:42?AM John Carlson wrote: >>>> >>>>> Andreas, Joe, >>>>> >>>>> Reset Button, Reset_Clock added. >>>>> >>>>> See attached zip for details, or visit link; >>>>> >>>>> >>>>> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>> >>>>> For some reason, this link doesn't show the live scene? >>>>> >>>>> >>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>> >>>>> Puzzled, haven't researched it yet. Looks good in Sunrize and X_ITE, >>>>> will try FreeWRL next. >>>>> >>>>> John >>>>> >>>>>> >>>> >>>> -- >>>> Andreas Plesch >>>> Waltham, MA 02453 >>>> >>> >> >> -- >> Andreas Plesch >> Waltham, MA 02453 >> > > > -- > Andreas Plesch > Waltham, MA 02453 > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Tue Feb 4 12:55:21 2025 From: yottzumm at gmail.com (John Carlson) Date: Tue, 4 Feb 2025 14:55:21 -0600 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: <2572A7BF-F34E-480C-9DB1-25F51D84AA61@yahoo.de> Message-ID: I have added default values in the ProtoDeclare for outputOnly fields, reverting back to passing out startTime, stopTime and enabled. Referring to this repository: https://github.com/coderextreme/ci2had/ I primarily wish to get this working: https://github.com/coderextreme/ci2had/blob/main/resources/CleanedYouClocks.x3d, but first, I want to get ManyClocks.x3d working, because it precedes CleanedYouClocks.x3d, but feel free to get it working first (it's a cleaned up version). If all else fails, I'll probably strip out the Proto (ugh!). -------------------------------------------------------------- I have confirmed that this doesn't animate: https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/ManyClocks.x3d -------------------------------------------------------------- This does animate: https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/ManyClocks.x3d --------------------------------------------------------------- Castle Model Converter produces errors. The viewer doesn't animate, probably because I use HAnimDisplacers. There are no scripts, in an attempt to appease people who don't like scripts. We now have a good example that has HAnimDisplacers, but no scripts. $ ~/Downloads/castle-model-viewer-5.3.0-win64-x86_64/castle-model-viewer/castle-model-converter.exe --validate resources/ManyClocks.x3d 2>&1 |sort -u castle-model-converter: Warning: X3D: X3D XML: element references unknown field name "enabled" castle-model-converter: Warning: X3D: X3D XML: element references unknown field name "startTime" castle-model-converter: Warning: X3D: X3D XML: element references unknown field name "stopTime" Exception "Exception": Validation failed (consult the warnings above), exiting with non-zero status --------------------------------------------------------------- FreeWRL kills JavaScript for some reason (there's no Script), but still doesn;'t animate (try pressing Fear). $ /c/Program\ Files\ \(x86\)/freeWRL/freeWRL.6.7/freeWRL.exe resources/ManyClocks.x3d MidiInWinMM::initialize: no MIDI input devices currently available. libfreewrl version 6.7.0 -h for commandline use openGL version 4.6.0 NVIDIA 560.94 GLSL shader max version 4.60 NVIDIA 460 maximum texture size system/gpu: 32768 runtime/freewrl: 16384 processor architecture x64 maxiumum image texture units 32 depth bits 24 Skinning Method: GPU calling kill_javascript() done kill_javascript Ending texture load thread gracefully finalizeRenderSceneUpdateScene --------------------------------------------------------------------------------------------------- Schematron reports a bunch of problems, all of which I ignore. See attached. log and build.xml --------------------------------------------------------------------------------------------------- There are many info issues when validating with X3DJSAIL, but I'm not sure about this one: $ java -cp ~/Downloads/X3DJSAIL.4.0.full.jar org.web3d.x3d.jsail.CommandLine -validate resources/ManyClocks.x3d|grep -v info [snip] org.web3d.x3d.sai.InvalidFieldException: IndexedFaceSet containing TextureCoordinate node with 295 values must also include texCoordIndex or coordIndex field at org.web3d.x3d.jsail.Geometry3D.IndexedFaceSet.validate(IndexedFaceSet.java:3756) at org.web3d.x3d.jsail.Shape.Shape.validate(Shape.java:2060) at org.web3d.x3d.jsail.Grouping.Transform.validate(Transform.java:2556) at org.web3d.x3d.jsail.HAnim.HAnimSegment.validate(HAnimSegment.java:6175) at org.web3d.x3d.jsail.HAnim.HAnimJoint.validate(HAnimJoint.java:7476) at org.web3d.x3d.jsail.HAnim.HAnimJoint.validate(HAnimJoint.java:7476) at org.web3d.x3d.jsail.HAnim.HAnimHumanoid.validate(HAnimHumanoid.java:6317) at org.web3d.x3d.jsail.Grouping.Transform.validate(Transform.java:2556) at org.web3d.x3d.jsail.Core.Scene.validate(Scene.java:869) at org.web3d.x3d.jsail.Core.X3D.validate(X3D.java:4549) at org.web3d.x3d.jsail.CommandLine.run(CommandLine.java:1098) at org.web3d.x3d.jsail.CommandLine.main(CommandLine.java:242) I don't have a recent version of X3DJSAIL On Tue, Feb 4, 2025 at 2:22?PM Andreas Plesch wrote: > Thanks, exactly what I was looking for. > > Best, Andreas > > > On Tue, Feb 4, 2025, 2:01?PM Holger Seelig wrote: > >> The default value for a field is either specified for each node type or >> the default value for Script or ComposedShader node custom fields is >> defined in >> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/fieldTypes.html. >> Mostly false, 0, ??, identity, ... >> >> A proto instance will inherit its default values from the proto >> declaration its fields. Fields such as outputOnly will normally have a >> default value from fieldTypes.html. >> >> There is an exception with X3DInterpolatorNode.value_changed: >> >> >> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/interpolators.html#X3DInterpolatorNode >> >> If an X3DInterpolatorNode value_changed outputOnly field is read before >> it receives any inputs, keyValue[0] is returned if keyValue is not empty... >> >> Best regards, >> Holger >> >> -- >> Holger Seelig >> Leipzig, Germany >> >> holger.seelig at yahoo.de >> https://create3000.github.io/x_ite/ >> >> Am 04.02.2025 um 19:26 schrieb Andreas Plesch via x3d-public < >> x3d-public at web3d.org>: >> >> Hi John, all, >> >> It turns out that x3dom currently expects a default value for Proto >> fields even for outputOnly fields. This is due to how Proto fields are >> initialized. They always need to have a value. While the spec. does not >> require this, it seems still good practice to always define a default value >> in the ProtoInterface. There may be a case where an outputOnly field is >> used in ISing where a valid value would be expected. There may be other >> corner cases. >> >> Here is your example with added default values for outputOnly fields: >> >> >> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/af5ff3148c1159f71d34fb78c1f63024/raw/b3d4470107ab74e301ed48448ab2a4f4154672e0/ManyClocks_John.x3d >> >> This could be fixed in x3dom, by always setting some default value. Is >> there a list of recommended defaults for each data type if no other source >> of defaults is available? For SFTime it seems to be -1. >> >> -Andreas >> >> >> On Mon, Feb 3, 2025 at 7:39?AM Andreas Plesch >> wrote: >> >>> Hi John, >>> >>> On Mon, Feb 3, 2025 at 12:48?AM John Carlson wrote: >>> >>>> Andreas, "startTime" is an accessType outputOnly field, so why do I >>>> need to provide a value attribute in fieldValue? I'm kind of confused. >>>> I'm probably missing something in the spec. >>>> >>> >>> You are right, I only outlined scenarios where the accessType allows >>> input or initialization.. >>> In the outputOnly case it is not necessary to provide a fieldValue node >>> at all since there is no value which can be provided. Providing the node >>> would indeed be confusing, to both the user code reader and any X3D browser. >>> I believe the spec. is silent on this case in any encoding. >>> >>> Best, Andreas >>> >>> Thanks for any clarification. >>>> >>>> I have finally enabled schematron on the project, but I'm finding it >>>> hard to understand the messages, and modifications that I make, while >>>> removing the immediate problems, seem to move the problems elsewhere. >>>> >>>> Explaining why I need a "startTime" fieldValue value is my main lack of >>>> understanding, but perhaps I need a whole review of accessType. >>>> >>>> Castle Model Converter reports: >>>> >>>> castle-model-converter: Warning: X3D: X3D XML: element >>>> references unknown field name "enabled" >>>> castle-model-converter: Warning: X3D: X3D XML: element >>>> references unknown field name "startTime" >>>> castle-model-converter: Warning: X3D: X3D XML: element >>>> references unknown field name "stopTime" >>>> >>>> I will try providing a field value in the ProtoInterface >>>> >>>> If I "cleanup" enabled, startTime and stopTime, I get: >>>> >>>> castle-model-converter: Warning: VRML/X3D: Within prototype "MenuItem", >>>> event "inputTrue" references (by "IS" clause) non-existing event "enabled" >>>> castle-model-converter: Warning: VRML/X3D: Within prototype "MenuItem", >>>> event "triggerTime" references (by "IS" clause) non-existing event >>>> "startTime" >>>> castle-model-converter: Warning: VRML/X3D: Within prototype "MenuItem", >>>> event "triggerTime" references (by "IS" clause) non-existing event >>>> "stopTime" >>>> >>>> I guess what I conclude at this point is, startTime and stopTime are >>>> bad DEF names, but what about enabled as a field? The dominoes are falling. >>>> >>>> About your two scenarios in the other message, perhaps this is >>>> revealing. >>>> >>>> See attached attempt to fix original issue, which resulted in the above. >>>> >>>> John >>>> >>>> On Sun, Feb 2, 2025 at 3:59?PM Andreas Plesch >>>> wrote: >>>> >>>>> I think x3dom, reasonably, expects a value for the fieldValue nodes: >>>>> >>>>> For example: >>>>> >>>>> >>>>> >>>>> and others. >>>>> >>>>> On Sun, Feb 2, 2025 at 5:42?AM John Carlson >>>>> wrote: >>>>> >>>>>> Andreas, Joe, >>>>>> >>>>>> Reset Button, Reset_Clock added. >>>>>> >>>>>> See attached zip for details, or visit link; >>>>>> >>>>>> >>>>>> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>> >>>>>> For some reason, this link doesn't show the live scene? >>>>>> >>>>>> >>>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>> >>>>>> Puzzled, haven't researched it yet. Looks good in Sunrize and X_ITE, >>>>>> will try FreeWRL next. >>>>>> >>>>>> John >>>>>> >>>>>>> >>>>> >>>>> -- >>>>> Andreas Plesch >>>>> Waltham, MA 02453 >>>>> >>>> >>> >>> -- >>> Andreas Plesch >>> Waltham, MA 02453 >>> >> >> >> -- >> Andreas Plesch >> Waltham, MA 02453 >> _______________________________________________ >> x3d-public mailing list >> x3d-public at web3d.org >> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ManyClocksSchematron.zip Type: application/x-zip-compressed Size: 52775 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: build.xml Type: text/xml Size: 1198 bytes Desc: not available URL: From michalis.kambi at gmail.com Tue Feb 4 13:23:18 2025 From: michalis.kambi at gmail.com (Michalis Kamburelis) Date: Tue, 4 Feb 2025 22:23:18 +0100 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: <2572A7BF-F34E-480C-9DB1-25F51D84AA61@yahoo.de> Message-ID: Hi, Sorry for not following this thread from the start, I just saw a mention of castle-model-converter making warnings on the testcase. I confirm they also occur with latest Castle Model Viewer. Looking at the testcase, I think Castle Model Viewer/Converter warnings are right. They say: """ X3D: X3D XML: element references unknown field name "startTime" X3D: X3D XML: element references unknown field name "stopTime" X3D: X3D XML: element references unknown field name "enabled" """ because you have XML elements inside the prototype instance of MenuItem (). But the prototype declaration () says these are "output only" events. They are "events", not fields, so strictly speaking they have no "persistent" value, at least that's how X3D specification treats them. (And that's how CGE implements them, events really hold no persistent value, they only pass values.) """ """ I understand that for JS scripts, it may make sense to specify a value even for outputOnly field (if one accesses from JS Script a value of output event that wasn't yet generated, which I understand is possible from standard JS API), but that's X3DOM extension, as Andreas pointed out. I don't think spec allows to specify values for such output events -- again, they are not even "fields" using spec terminology, so "fieldValue" would be confusing :) The spec specifies "default value of an uninitialized xxx field" in https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/fieldTypes.html to serve as a fallback in edge-cases, like above. Moreover, note that in this specific case, these do not seem to serve any purpose. XML elements .... do not actually contain any value :) ( Again, sorry for not following this thread from start -- I do not know how the file was generated/created. ) I looks like they should just be removed. Regards, Michalis wt., 4 lut 2025 o 21:55 John Carlson napisa?(a): > > I have added default values in the ProtoDeclare for outputOnly fields, reverting back to passing out startTime, stopTime and enabled. > > Referring to this repository: > > https://github.com/coderextreme/ci2had/ > > I primarily wish to get this working: https://github.com/coderextreme/ci2had/blob/main/resources/CleanedYouClocks.x3d, but first, I want to get ManyClocks.x3d working, because it precedes CleanedYouClocks.x3d, but feel free to get it working first (it's a cleaned up version). > > If all else fails, I'll probably strip out the Proto (ugh!). > -------------------------------------------------------------- > I have confirmed that this doesn't animate: > > https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/ManyClocks.x3d > -------------------------------------------------------------- > This does animate: > > https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/ManyClocks.x3d > --------------------------------------------------------------- > Castle Model Converter produces errors. The viewer doesn't animate, probably because I use HAnimDisplacers. There are no scripts, in an attempt to appease people who don't like scripts. We now have a good example that has HAnimDisplacers, but no scripts. > > $ ~/Downloads/castle-model-viewer-5.3.0-win64-x86_64/castle-model-viewer/castle-model-converter.exe --validate resources/ManyClocks.x3d 2>&1 |sort -u > castle-model-converter: Warning: X3D: X3D XML: element references unknown field name "enabled" > castle-model-converter: Warning: X3D: X3D XML: element references unknown field name "startTime" > castle-model-converter: Warning: X3D: X3D XML: element references unknown field name "stopTime" > Exception "Exception": > Validation failed (consult the warnings above), exiting with non-zero status > --------------------------------------------------------------- > FreeWRL kills JavaScript for some reason (there's no Script), but still doesn;'t animate (try pressing Fear). > > $ /c/Program\ Files\ \(x86\)/freeWRL/freeWRL.6.7/freeWRL.exe resources/ManyClocks.x3d > > MidiInWinMM::initialize: no MIDI input devices currently available. > > libfreewrl version 6.7.0 > -h for commandline use > openGL version 4.6.0 NVIDIA 560.94 > GLSL shader max version 4.60 NVIDIA 460 > maximum texture size system/gpu: 32768 runtime/freewrl: 16384 > processor architecture x64 > maxiumum image texture units 32 > depth bits 24 > Skinning Method: GPU > calling kill_javascript() > done kill_javascript > Ending texture load thread gracefully > finalizeRenderSceneUpdateScene > --------------------------------------------------------------------------------------------------- > Schematron reports a bunch of problems, all of which I ignore. See attached. log and build.xml > --------------------------------------------------------------------------------------------------- > There are many info issues when validating with X3DJSAIL, but I'm not sure about this one: > $ java -cp ~/Downloads/X3DJSAIL.4.0.full.jar org.web3d.x3d.jsail.CommandLine -validate resources/ManyClocks.x3d|grep -v > info > [snip] > org.web3d.x3d.sai.InvalidFieldException: IndexedFaceSet containing TextureCoordinate node with 295 values must also include texCoordIndex or coordIndex field > at org.web3d.x3d.jsail.Geometry3D.IndexedFaceSet.validate(IndexedFaceSet.java:3756) > at org.web3d.x3d.jsail.Shape.Shape.validate(Shape.java:2060) > at org.web3d.x3d.jsail.Grouping.Transform.validate(Transform.java:2556) > at org.web3d.x3d.jsail.HAnim.HAnimSegment.validate(HAnimSegment.java:6175) > at org.web3d.x3d.jsail.HAnim.HAnimJoint.validate(HAnimJoint.java:7476) > at org.web3d.x3d.jsail.HAnim.HAnimJoint.validate(HAnimJoint.java:7476) > at org.web3d.x3d.jsail.HAnim.HAnimHumanoid.validate(HAnimHumanoid.java:6317) > at org.web3d.x3d.jsail.Grouping.Transform.validate(Transform.java:2556) > at org.web3d.x3d.jsail.Core.Scene.validate(Scene.java:869) > at org.web3d.x3d.jsail.Core.X3D.validate(X3D.java:4549) > at org.web3d.x3d.jsail.CommandLine.run(CommandLine.java:1098) > at org.web3d.x3d.jsail.CommandLine.main(CommandLine.java:242) > > I don't have a recent version of X3DJSAIL > > On Tue, Feb 4, 2025 at 2:22?PM Andreas Plesch wrote: >> >> Thanks, exactly what I was looking for. >> >> Best, Andreas >> >> >> On Tue, Feb 4, 2025, 2:01?PM Holger Seelig wrote: >>> >>> The default value for a field is either specified for each node type or the default value for Script or ComposedShader node custom fields is defined in https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/fieldTypes.html. Mostly false, 0, ??, identity, ... >>> >>> A proto instance will inherit its default values from the proto declaration its fields. Fields such as outputOnly will normally have a default value from fieldTypes.html. >>> >>> There is an exception with X3DInterpolatorNode.value_changed: >>> >>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/interpolators.html#X3DInterpolatorNode >>> >>> If an X3DInterpolatorNode value_changed outputOnly field is read before it receives any inputs, keyValue[0] is returned if keyValue is not empty... >>> >>> Best regards, >>> Holger >>> >>> -- >>> Holger Seelig >>> Leipzig, Germany >>> >>> holger.seelig at yahoo.de >>> https://create3000.github.io/x_ite/ >>> >>> Am 04.02.2025 um 19:26 schrieb Andreas Plesch via x3d-public : >>> >>> Hi John, all, >>> >>> It turns out that x3dom currently expects a default value for Proto fields even for outputOnly fields. This is due to how Proto fields are initialized. They always need to have a value. While the spec. does not require this, it seems still good practice to always define a default value in the ProtoInterface. There may be a case where an outputOnly field is used in ISing where a valid value would be expected. There may be other corner cases. >>> >>> Here is your example with added default values for outputOnly fields: >>> >>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/af5ff3148c1159f71d34fb78c1f63024/raw/b3d4470107ab74e301ed48448ab2a4f4154672e0/ManyClocks_John.x3d >>> >>> This could be fixed in x3dom, by always setting some default value. Is there a list of recommended defaults for each data type if no other source of defaults is available? For SFTime it seems to be -1. >>> >>> -Andreas >>> >>> >>> On Mon, Feb 3, 2025 at 7:39?AM Andreas Plesch wrote: >>>> >>>> Hi John, >>>> >>>> On Mon, Feb 3, 2025 at 12:48?AM John Carlson wrote: >>>>> >>>>> Andreas, "startTime" is an accessType outputOnly field, so why do I need to provide a value attribute in fieldValue? I'm kind of confused. I'm probably missing something in the spec. >>>> >>>> >>>> You are right, I only outlined scenarios where the accessType allows input or initialization.. >>>> In the outputOnly case it is not necessary to provide a fieldValue node at all since there is no value which can be provided. Providing the node would indeed be confusing, to both the user code reader and any X3D browser. >>>> I believe the spec. is silent on this case in any encoding. >>>> >>>> Best, Andreas >>>> >>>>> Thanks for any clarification. >>>>> >>>>> I have finally enabled schematron on the project, but I'm finding it hard to understand the messages, and modifications that I make, while removing the immediate problems, seem to move the problems elsewhere. >>>>> >>>>> Explaining why I need a "startTime" fieldValue value is my main lack of understanding, but perhaps I need a whole review of accessType. >>>>> >>>>> Castle Model Converter reports: >>>>> >>>>> castle-model-converter: Warning: X3D: X3D XML: element references unknown field name "enabled" >>>>> castle-model-converter: Warning: X3D: X3D XML: element references unknown field name "startTime" >>>>> castle-model-converter: Warning: X3D: X3D XML: element references unknown field name "stopTime" >>>>> >>>>> I will try providing a field value in the ProtoInterface >>>>> >>>>> If I "cleanup" enabled, startTime and stopTime, I get: >>>>> >>>>> castle-model-converter: Warning: VRML/X3D: Within prototype "MenuItem", event "inputTrue" references (by "IS" clause) non-existing event "enabled" >>>>> castle-model-converter: Warning: VRML/X3D: Within prototype "MenuItem", event "triggerTime" references (by "IS" clause) non-existing event "startTime" >>>>> castle-model-converter: Warning: VRML/X3D: Within prototype "MenuItem", event "triggerTime" references (by "IS" clause) non-existing event "stopTime" >>>>> >>>>> I guess what I conclude at this point is, startTime and stopTime are bad DEF names, but what about enabled as a field? The dominoes are falling. >>>>> >>>>> About your two scenarios in the other message, perhaps this is revealing. >>>>> >>>>> See attached attempt to fix original issue, which resulted in the above. >>>>> >>>>> John >>>>> >>>>> On Sun, Feb 2, 2025 at 3:59?PM Andreas Plesch wrote: >>>>>> >>>>>> I think x3dom, reasonably, expects a value for the fieldValue nodes: >>>>>> >>>>>> For example: >>>>>> >>>>>> >>>>>> >>>>>> and others. >>>>>> >>>>>> On Sun, Feb 2, 2025 at 5:42?AM John Carlson wrote: >>>>>>> >>>>>>> Andreas, Joe, >>>>>>> >>>>>>> Reset Button, Reset_Clock added. >>>>>>> >>>>>>> See attached zip for details, or visit link; >>>>>>> >>>>>>> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>>> >>>>>>> For some reason, this link doesn't show the live scene? >>>>>>> >>>>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>>> >>>>>>> Puzzled, haven't researched it yet. Looks good in Sunrize and X_ITE, will try FreeWRL next. >>>>>>> >>>>>>> John >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Andreas Plesch >>>>>> Waltham, MA 02453 >>>> >>>> >>>> >>>> -- >>>> Andreas Plesch >>>> Waltham, MA 02453 >>> >>> >>> >>> -- >>> Andreas Plesch >>> Waltham, MA 02453 >>> _______________________________________________ >>> x3d-public mailing list >>> x3d-public at web3d.org >>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>> >>> From yottzumm at gmail.com Tue Feb 4 14:15:52 2025 From: yottzumm at gmail.com (John Carlson) Date: Tue, 4 Feb 2025 16:15:52 -0600 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: <2572A7BF-F34E-480C-9DB1-25F51D84AA61@yahoo.de> Message-ID: Comments inline. On Tue, Feb 4, 2025 at 3:23?PM Michalis Kamburelis wrote: > Hi, > > Sorry for not following this thread from the start, I just saw a > mention of castle-model-converter making warnings on the testcase. I > confirm they also occur with latest Castle Model Viewer. > > Looking at the testcase, I think Castle Model Viewer/Converter > warnings are right. They say: > > """ > X3D: X3D XML: element references unknown field name > "startTime" > X3D: X3D XML: element references unknown field name "stopTime" > X3D: X3D XML: element references unknown field name "enabled" > """ > > because you have XML elements > > > > > > inside the prototype instance of MenuItem ( name="MenuItem">). > > But the prototype declaration () says > these are "output only" events. They are "events", not fields, so > strictly speaking they have no "persistent" value, at least that's how > X3D specification treats them. (And that's how CGE implements them, > events really hold no persistent value, they only pass values.) > > """ > value='0' /> > value='0'/> > value='false'/> > """ > > I understand that for JS scripts, it may make sense to specify a value > even for outputOnly field (if one accesses from JS Script a value of > output event that wasn't yet generated, which I understand is possible > from standard JS API), but that's X3DOM extension, as Andreas pointed > out. More recent versions have not included any Script nodes. That?s the main current requirement. > > > I don't think spec allows to specify values for such output events -- > again, they are not even "fields" using spec terminology, so > "fieldValue" would be confusing :) The spec specifies "default value > of an uninitialized xxx field" in > > https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/fieldTypes.html > to serve as a fallback in edge-cases, like above. Interesting take on events versus fields. > > > Moreover, note that in this specific case, these do not seem to serve > any purpose. XML elements > > > > > > .... do not actually contain any value :) ( Again, sorry for not > following this thread from start -- I do not know how the file was > generated/created. ) I looks like they should just be removed. These s are mentioned in ROUTEs outside the Proto. Search for Reset and Reset_Clock, for example. I will try to create a simple example, but this is super frustrating to get anything beyond Sunrize and X_ITE working. Sunrize won?t allow me to pass a TimeSensor USE into a Proto, and ROUTE to the TimeSensor inside the Proto, so that?s super frustrating too. Maybe I should use type=?TimeSensor? in the interface? The time triggers inside the Proto pretty much require the use of outputOnly. Suggestions for other options would be helpful. These lines look problematic: Since I can?t ?input? triggerTime, it requires that I use outputOnly. > Regards, > Michalis > > wt., 4 lut 2025 o 21:55 John Carlson napisa?(a): > > > > I have added default values in the ProtoDeclare for outputOnly fields, > reverting back to passing out startTime, stopTime and enabled. > > > > Referring to this repository: > > > > https://github.com/coderextreme/ci2had/ > > > > I primarily wish to get this working: > https://github.com/coderextreme/ci2had/blob/main/resources/CleanedYouClocks.x3d, > but first, I want to get ManyClocks.x3d working, because it precedes > CleanedYouClocks.x3d, but feel free to get it working first (it's a cleaned > up version). > > > > If all else fails, I'll probably strip out the Proto (ugh!). > > -------------------------------------------------------------- > > I have confirmed that this doesn't animate: > > > > > https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/ManyClocks.x3d > > -------------------------------------------------------------- > > This does animate: > > > > > https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/ManyClocks.x3d > > --------------------------------------------------------------- > > Castle Model Converter produces errors. The viewer doesn't animate, > probably because I use HAnimDisplacers. There are no scripts, in an attempt > to appease people who don't like scripts. We now have a good example that > has HAnimDisplacers, but no scripts. > > > > $ > ~/Downloads/castle-model-viewer-5.3.0-win64-x86_64/castle-model-viewer/castle-model-converter.exe > --validate resources/ManyClocks.x3d 2>&1 |sort -u > > castle-model-converter: Warning: X3D: X3D XML: element > references unknown field name "enabled" > > castle-model-converter: Warning: X3D: X3D XML: element > references unknown field name "startTime" > > castle-model-converter: Warning: X3D: X3D XML: element > references unknown field name "stopTime" > > Exception "Exception": > > Validation failed (consult the warnings above), exiting with non-zero > status > > --------------------------------------------------------------- > > FreeWRL kills JavaScript for some reason (there's no Script), but still > doesn;'t animate (try pressing Fear). > > > > $ /c/Program\ Files\ \(x86\)/freeWRL/freeWRL.6.7/freeWRL.exe > resources/ManyClocks.x3d > > > > MidiInWinMM::initialize: no MIDI input devices currently available. > > > > libfreewrl version 6.7.0 > > -h for commandline use > > openGL version 4.6.0 NVIDIA 560.94 > > GLSL shader max version 4.60 NVIDIA 460 > > maximum texture size system/gpu: 32768 runtime/freewrl: 16384 > > processor architecture x64 > > maxiumum image texture units 32 > > depth bits 24 > > Skinning Method: GPU > > calling kill_javascript() > > done kill_javascript > > Ending texture load thread gracefully > > finalizeRenderSceneUpdateScene > > > --------------------------------------------------------------------------------------------------- > > Schematron reports a bunch of problems, all of which I ignore. See > attached. log and build.xml > > > --------------------------------------------------------------------------------------------------- > > There are many info issues when validating with X3DJSAIL, but I'm not > sure about this one: > > $ java -cp ~/Downloads/X3DJSAIL.4.0.full.jar > org.web3d.x3d.jsail.CommandLine -validate resources/ManyClocks.x3d|grep -v > > info > > [snip] > > org.web3d.x3d.sai.InvalidFieldException: IndexedFaceSet containing > TextureCoordinate node with 295 values must also include texCoordIndex or > coordIndex field > > at > org.web3d.x3d.jsail.Geometry3D.IndexedFaceSet.validate(IndexedFaceSet.java:3756) > > at org.web3d.x3d.jsail.Shape.Shape.validate(Shape.java:2060) > > at > org.web3d.x3d.jsail.Grouping.Transform.validate(Transform.java:2556) > > at > org.web3d.x3d.jsail.HAnim.HAnimSegment.validate(HAnimSegment.java:6175) > > at > org.web3d.x3d.jsail.HAnim.HAnimJoint.validate(HAnimJoint.java:7476) > > at > org.web3d.x3d.jsail.HAnim.HAnimJoint.validate(HAnimJoint.java:7476) > > at > org.web3d.x3d.jsail.HAnim.HAnimHumanoid.validate(HAnimHumanoid.java:6317) > > at > org.web3d.x3d.jsail.Grouping.Transform.validate(Transform.java:2556) > > at org.web3d.x3d.jsail.Core.Scene.validate(Scene.java:869) > > at org.web3d.x3d.jsail.Core.X3D.validate(X3D.java:4549) > > at org.web3d.x3d.jsail.CommandLine.run(CommandLine.java:1098) > > at org.web3d.x3d.jsail.CommandLine.main(CommandLine.java:242) > > > > I don't have a recent version of X3DJSAIL > > > > On Tue, Feb 4, 2025 at 2:22?PM Andreas Plesch > wrote: > >> > >> Thanks, exactly what I was looking for. > >> > >> Best, Andreas > >> > >> > >> On Tue, Feb 4, 2025, 2:01?PM Holger Seelig > wrote: > >>> > >>> The default value for a field is either specified for each node type > or the default value for Script or ComposedShader node custom fields is > defined in > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/fieldTypes.html. > Mostly false, 0, ??, identity, ... > >>> > >>> A proto instance will inherit its default values from the proto > declaration its fields. Fields such as outputOnly will normally have a > default value from fieldTypes.html. > >>> > >>> There is an exception with X3DInterpolatorNode.value_changed: > >>> > >>> > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/interpolators.html#X3DInterpolatorNode > >>> > >>> If an X3DInterpolatorNode value_changed outputOnly field is read > before it receives any inputs, keyValue[0] is returned if keyValue is not > empty... > >>> > >>> Best regards, > >>> Holger > >>> > >>> -- > >>> Holger Seelig > >>> Leipzig, Germany > >>> > >>> holger.seelig at yahoo.de > >>> https://create3000.github.io/x_ite/ > >>> > >>> Am 04.02.2025 um 19:26 schrieb Andreas Plesch via x3d-public < > x3d-public at web3d.org>: > >>> > >>> Hi John, all, > >>> > >>> It turns out that x3dom currently expects a default value for Proto > fields even for outputOnly fields. This is due to how Proto fields are > initialized. They always need to have a value. While the spec. does not > require this, it seems still good practice to always define a default value > in the ProtoInterface. There may be a case where an outputOnly field is > used in ISing where a valid value would be expected. There may be other > corner cases. > >>> > >>> Here is your example with added default values for outputOnly fields: > >>> > >>> > https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/af5ff3148c1159f71d34fb78c1f63024/raw/b3d4470107ab74e301ed48448ab2a4f4154672e0/ManyClocks_John.x3d > >>> > >>> This could be fixed in x3dom, by always setting some default value. Is > there a list of recommended defaults for each data type if no other source > of defaults is available? For SFTime it seems to be -1. > >>> > >>> -Andreas > >>> > >>> > >>> On Mon, Feb 3, 2025 at 7:39?AM Andreas Plesch > wrote: > >>>> > >>>> Hi John, > >>>> > >>>> On Mon, Feb 3, 2025 at 12:48?AM John Carlson > wrote: > >>>>> > >>>>> Andreas, "startTime" is an accessType outputOnly field, so why do I > need to provide a value attribute in fieldValue? I'm kind of confused. > I'm probably missing something in the spec. > >>>> > >>>> > >>>> You are right, I only outlined scenarios where the accessType allows > input or initialization.. > >>>> In the outputOnly case it is not necessary to provide a fieldValue > node at all since there is no value which can be provided. Providing the > node would indeed be confusing, to both the user code reader and any X3D > browser. > >>>> I believe the spec. is silent on this case in any encoding. > >>>> > >>>> Best, Andreas > >>>> > >>>>> Thanks for any clarification. > >>>>> > >>>>> I have finally enabled schematron on the project, but I'm finding it > hard to understand the messages, and modifications that I make, while > removing the immediate problems, seem to move the problems elsewhere. > >>>>> > >>>>> Explaining why I need a "startTime" fieldValue value is my main lack > of understanding, but perhaps I need a whole review of accessType. > >>>>> > >>>>> Castle Model Converter reports: > >>>>> > >>>>> castle-model-converter: Warning: X3D: X3D XML: element > references unknown field name "enabled" > >>>>> castle-model-converter: Warning: X3D: X3D XML: element > references unknown field name "startTime" > >>>>> castle-model-converter: Warning: X3D: X3D XML: element > references unknown field name "stopTime" > >>>>> > >>>>> I will try providing a field value in the ProtoInterface > >>>>> > >>>>> If I "cleanup" enabled, startTime and stopTime, I get: > >>>>> > >>>>> castle-model-converter: Warning: VRML/X3D: Within prototype > "MenuItem", event "inputTrue" references (by "IS" clause) non-existing > event "enabled" > >>>>> castle-model-converter: Warning: VRML/X3D: Within prototype > "MenuItem", event "triggerTime" references (by "IS" clause) non-existing > event "startTime" > >>>>> castle-model-converter: Warning: VRML/X3D: Within prototype > "MenuItem", event "triggerTime" references (by "IS" clause) non-existing > event "stopTime" > >>>>> > >>>>> I guess what I conclude at this point is, startTime and stopTime are > bad DEF names, but what about enabled as a field? The dominoes are falling. > >>>>> > >>>>> About your two scenarios in the other message, perhaps this is > revealing. > >>>>> > >>>>> See attached attempt to fix original issue, which resulted in the > above. > >>>>> > >>>>> John > >>>>> > >>>>> On Sun, Feb 2, 2025 at 3:59?PM Andreas Plesch < > andreasplesch at gmail.com> wrote: > >>>>>> > >>>>>> I think x3dom, reasonably, expects a value for the fieldValue nodes: > >>>>>> > >>>>>> For example: > >>>>>> > >>>>>> > >>>>>> > >>>>>> and others. > >>>>>> > >>>>>> On Sun, Feb 2, 2025 at 5:42?AM John Carlson > wrote: > >>>>>>> > >>>>>>> Andreas, Joe, > >>>>>>> > >>>>>>> Reset Button, Reset_Clock added. > >>>>>>> > >>>>>>> See attached zip for details, or visit link; > >>>>>>> > >>>>>>> > https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d > >>>>>>> > >>>>>>> For some reason, this link doesn't show the live scene? > >>>>>>> > >>>>>>> > https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d > >>>>>>> > >>>>>>> Puzzled, haven't researched it yet. Looks good in Sunrize and > X_ITE, will try FreeWRL next. > >>>>>>> > >>>>>>> John > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Andreas Plesch > >>>>>> Waltham, MA 02453 > >>>> > >>>> > >>>> > >>>> -- > >>>> Andreas Plesch > >>>> Waltham, MA 02453 > >>> > >>> > >>> > >>> -- > >>> Andreas Plesch > >>> Waltham, MA 02453 > >>> _______________________________________________ > >>> x3d-public mailing list > >>> x3d-public at web3d.org > >>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org > >>> > >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Tue Feb 4 14:30:55 2025 From: yottzumm at gmail.com (John Carlson) Date: Tue, 4 Feb 2025 16:30:55 -0600 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: <2572A7BF-F34E-480C-9DB1-25F51D84AA61@yahoo.de> Message-ID: Soon for not including a reference to ProtoInstance source code: https://github.com/coderextreme/ci2had/blob/ed5b5cc3d586dce3e697d17a45a2a66c71a9fb28/python/manyclocks.py#L451 This is a pointer to the emotions loop, the Reset MenuItem and FACS action units (AU in ProtoInstance MenuItem DEF) loop are below. Note how the ROUTEs involving startTime, stopTime and enabled events are below the ProtoInstance. I hope this clears things up that the associated s are actually required. John On Tue, Feb 4, 2025 at 3:23?PM Michalis Kamburelis wrote: > Hi, > > Sorry for not following this thread from the start, I just saw a > mention of castle-model-converter making warnings on the testcase. I > confirm they also occur with latest Castle Model Viewer. > > Looking at the testcase, I think Castle Model Viewer/Converter > warnings are right. They say: > > """ > X3D: X3D XML: element references unknown field name > "startTime" > X3D: X3D XML: element references unknown field name "stopTime" > X3D: X3D XML: element references unknown field name "enabled" > """ > > because you have XML elements > > > > > > inside the prototype instance of MenuItem ( name="MenuItem">). > > But the prototype declaration () says > these are "output only" events. They are "events", not fields, so > strictly speaking they have no "persistent" value, at least that's how > X3D specification treats them. (And that's how CGE implements them, > events really hold no persistent value, they only pass values.) > > """ > value='0' /> > value='0'/> > value='false'/> > """ > > I understand that for JS scripts, it may make sense to specify a value > even for outputOnly field (if one accesses from JS Script a value of > output event that wasn't yet generated, which I understand is possible > from standard JS API), but that's X3DOM extension, as Andreas pointed > out. > > I don't think spec allows to specify values for such output events -- > again, they are not even "fields" using spec terminology, so > "fieldValue" would be confusing :) The spec specifies "default value > of an uninitialized xxx field" in > > https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/fieldTypes.html > to serve as a fallback in edge-cases, like above. > > Moreover, note that in this specific case, these do not seem to serve > any purpose. XML elements > > > > > > .... do not actually contain any value :) ( Again, sorry for not > following this thread from start -- I do not know how the file was > generated/created. ) I looks like they should just be removed. > > Regards, > Michalis > > wt., 4 lut 2025 o 21:55 John Carlson napisa?(a): > > > > I have added default values in the ProtoDeclare for outputOnly fields, > reverting back to passing out startTime, stopTime and enabled. > > > > Referring to this repository: > > > > https://github.com/coderextreme/ci2had/ > > > > I primarily wish to get this working: > https://github.com/coderextreme/ci2had/blob/main/resources/CleanedYouClocks.x3d, > but first, I want to get ManyClocks.x3d working, because it precedes > CleanedYouClocks.x3d, but feel free to get it working first (it's a cleaned > up version). > > > > If all else fails, I'll probably strip out the Proto (ugh!). > > -------------------------------------------------------------- > > I have confirmed that this doesn't animate: > > > > > https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/ManyClocks.x3d > > -------------------------------------------------------------- > > This does animate: > > > > > https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/ManyClocks.x3d > > --------------------------------------------------------------- > > Castle Model Converter produces errors. The viewer doesn't animate, > probably because I use HAnimDisplacers. There are no scripts, in an attempt > to appease people who don't like scripts. We now have a good example that > has HAnimDisplacers, but no scripts. > > > > $ > ~/Downloads/castle-model-viewer-5.3.0-win64-x86_64/castle-model-viewer/castle-model-converter.exe > --validate resources/ManyClocks.x3d 2>&1 |sort -u > > castle-model-converter: Warning: X3D: X3D XML: element > references unknown field name "enabled" > > castle-model-converter: Warning: X3D: X3D XML: element > references unknown field name "startTime" > > castle-model-converter: Warning: X3D: X3D XML: element > references unknown field name "stopTime" > > Exception "Exception": > > Validation failed (consult the warnings above), exiting with non-zero > status > > --------------------------------------------------------------- > > FreeWRL kills JavaScript for some reason (there's no Script), but still > doesn;'t animate (try pressing Fear). > > > > $ /c/Program\ Files\ \(x86\)/freeWRL/freeWRL.6.7/freeWRL.exe > resources/ManyClocks.x3d > > > > MidiInWinMM::initialize: no MIDI input devices currently available. > > > > libfreewrl version 6.7.0 > > -h for commandline use > > openGL version 4.6.0 NVIDIA 560.94 > > GLSL shader max version 4.60 NVIDIA 460 > > maximum texture size system/gpu: 32768 runtime/freewrl: 16384 > > processor architecture x64 > > maxiumum image texture units 32 > > depth bits 24 > > Skinning Method: GPU > > calling kill_javascript() > > done kill_javascript > > Ending texture load thread gracefully > > finalizeRenderSceneUpdateScene > > > --------------------------------------------------------------------------------------------------- > > Schematron reports a bunch of problems, all of which I ignore. See > attached. log and build.xml > > > --------------------------------------------------------------------------------------------------- > > There are many info issues when validating with X3DJSAIL, but I'm not > sure about this one: > > $ java -cp ~/Downloads/X3DJSAIL.4.0.full.jar > org.web3d.x3d.jsail.CommandLine -validate resources/ManyClocks.x3d|grep -v > > info > > [snip] > > org.web3d.x3d.sai.InvalidFieldException: IndexedFaceSet containing > TextureCoordinate node with 295 values must also include texCoordIndex or > coordIndex field > > at > org.web3d.x3d.jsail.Geometry3D.IndexedFaceSet.validate(IndexedFaceSet.java:3756) > > at org.web3d.x3d.jsail.Shape.Shape.validate(Shape.java:2060) > > at > org.web3d.x3d.jsail.Grouping.Transform.validate(Transform.java:2556) > > at > org.web3d.x3d.jsail.HAnim.HAnimSegment.validate(HAnimSegment.java:6175) > > at > org.web3d.x3d.jsail.HAnim.HAnimJoint.validate(HAnimJoint.java:7476) > > at > org.web3d.x3d.jsail.HAnim.HAnimJoint.validate(HAnimJoint.java:7476) > > at > org.web3d.x3d.jsail.HAnim.HAnimHumanoid.validate(HAnimHumanoid.java:6317) > > at > org.web3d.x3d.jsail.Grouping.Transform.validate(Transform.java:2556) > > at org.web3d.x3d.jsail.Core.Scene.validate(Scene.java:869) > > at org.web3d.x3d.jsail.Core.X3D.validate(X3D.java:4549) > > at org.web3d.x3d.jsail.CommandLine.run(CommandLine.java:1098) > > at org.web3d.x3d.jsail.CommandLine.main(CommandLine.java:242) > > > > I don't have a recent version of X3DJSAIL > > > > On Tue, Feb 4, 2025 at 2:22?PM Andreas Plesch > wrote: > >> > >> Thanks, exactly what I was looking for. > >> > >> Best, Andreas > >> > >> > >> On Tue, Feb 4, 2025, 2:01?PM Holger Seelig > wrote: > >>> > >>> The default value for a field is either specified for each node type > or the default value for Script or ComposedShader node custom fields is > defined in > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/fieldTypes.html. > Mostly false, 0, ??, identity, ... > >>> > >>> A proto instance will inherit its default values from the proto > declaration its fields. Fields such as outputOnly will normally have a > default value from fieldTypes.html. > >>> > >>> There is an exception with X3DInterpolatorNode.value_changed: > >>> > >>> > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/interpolators.html#X3DInterpolatorNode > >>> > >>> If an X3DInterpolatorNode value_changed outputOnly field is read > before it receives any inputs, keyValue[0] is returned if keyValue is not > empty... > >>> > >>> Best regards, > >>> Holger > >>> > >>> -- > >>> Holger Seelig > >>> Leipzig, Germany > >>> > >>> holger.seelig at yahoo.de > >>> https://create3000.github.io/x_ite/ > >>> > >>> Am 04.02.2025 um 19:26 schrieb Andreas Plesch via x3d-public < > x3d-public at web3d.org>: > >>> > >>> Hi John, all, > >>> > >>> It turns out that x3dom currently expects a default value for Proto > fields even for outputOnly fields. This is due to how Proto fields are > initialized. They always need to have a value. While the spec. does not > require this, it seems still good practice to always define a default value > in the ProtoInterface. There may be a case where an outputOnly field is > used in ISing where a valid value would be expected. There may be other > corner cases. > >>> > >>> Here is your example with added default values for outputOnly fields: > >>> > >>> > https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/af5ff3148c1159f71d34fb78c1f63024/raw/b3d4470107ab74e301ed48448ab2a4f4154672e0/ManyClocks_John.x3d > >>> > >>> This could be fixed in x3dom, by always setting some default value. Is > there a list of recommended defaults for each data type if no other source > of defaults is available? For SFTime it seems to be -1. > >>> > >>> -Andreas > >>> > >>> > >>> On Mon, Feb 3, 2025 at 7:39?AM Andreas Plesch > wrote: > >>>> > >>>> Hi John, > >>>> > >>>> On Mon, Feb 3, 2025 at 12:48?AM John Carlson > wrote: > >>>>> > >>>>> Andreas, "startTime" is an accessType outputOnly field, so why do I > need to provide a value attribute in fieldValue? I'm kind of confused. > I'm probably missing something in the spec. > >>>> > >>>> > >>>> You are right, I only outlined scenarios where the accessType allows > input or initialization.. > >>>> In the outputOnly case it is not necessary to provide a fieldValue > node at all since there is no value which can be provided. Providing the > node would indeed be confusing, to both the user code reader and any X3D > browser. > >>>> I believe the spec. is silent on this case in any encoding. > >>>> > >>>> Best, Andreas > >>>> > >>>>> Thanks for any clarification. > >>>>> > >>>>> I have finally enabled schematron on the project, but I'm finding it > hard to understand the messages, and modifications that I make, while > removing the immediate problems, seem to move the problems elsewhere. > >>>>> > >>>>> Explaining why I need a "startTime" fieldValue value is my main lack > of understanding, but perhaps I need a whole review of accessType. > >>>>> > >>>>> Castle Model Converter reports: > >>>>> > >>>>> castle-model-converter: Warning: X3D: X3D XML: element > references unknown field name "enabled" > >>>>> castle-model-converter: Warning: X3D: X3D XML: element > references unknown field name "startTime" > >>>>> castle-model-converter: Warning: X3D: X3D XML: element > references unknown field name "stopTime" > >>>>> > >>>>> I will try providing a field value in the ProtoInterface > >>>>> > >>>>> If I "cleanup" enabled, startTime and stopTime, I get: > >>>>> > >>>>> castle-model-converter: Warning: VRML/X3D: Within prototype > "MenuItem", event "inputTrue" references (by "IS" clause) non-existing > event "enabled" > >>>>> castle-model-converter: Warning: VRML/X3D: Within prototype > "MenuItem", event "triggerTime" references (by "IS" clause) non-existing > event "startTime" > >>>>> castle-model-converter: Warning: VRML/X3D: Within prototype > "MenuItem", event "triggerTime" references (by "IS" clause) non-existing > event "stopTime" > >>>>> > >>>>> I guess what I conclude at this point is, startTime and stopTime are > bad DEF names, but what about enabled as a field? The dominoes are falling. > >>>>> > >>>>> About your two scenarios in the other message, perhaps this is > revealing. > >>>>> > >>>>> See attached attempt to fix original issue, which resulted in the > above. > >>>>> > >>>>> John > >>>>> > >>>>> On Sun, Feb 2, 2025 at 3:59?PM Andreas Plesch < > andreasplesch at gmail.com> wrote: > >>>>>> > >>>>>> I think x3dom, reasonably, expects a value for the fieldValue nodes: > >>>>>> > >>>>>> For example: > >>>>>> > >>>>>> > >>>>>> > >>>>>> and others. > >>>>>> > >>>>>> On Sun, Feb 2, 2025 at 5:42?AM John Carlson > wrote: > >>>>>>> > >>>>>>> Andreas, Joe, > >>>>>>> > >>>>>>> Reset Button, Reset_Clock added. > >>>>>>> > >>>>>>> See attached zip for details, or visit link; > >>>>>>> > >>>>>>> > https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d > >>>>>>> > >>>>>>> For some reason, this link doesn't show the live scene? > >>>>>>> > >>>>>>> > https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d > >>>>>>> > >>>>>>> Puzzled, haven't researched it yet. Looks good in Sunrize and > X_ITE, will try FreeWRL next. > >>>>>>> > >>>>>>> John > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Andreas Plesch > >>>>>> Waltham, MA 02453 > >>>> > >>>> > >>>> > >>>> -- > >>>> Andreas Plesch > >>>> Waltham, MA 02453 > >>> > >>> > >>> > >>> -- > >>> Andreas Plesch > >>> Waltham, MA 02453 > >>> _______________________________________________ > >>> x3d-public mailing list > >>> x3d-public at web3d.org > >>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org > >>> > >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Tue Feb 4 14:45:57 2025 From: yottzumm at gmail.com (John Carlson) Date: Tue, 4 Feb 2025 16:45:57 -0600 Subject: [x3d-public] Fwd: Turning on and off simultaneous animations individually In-Reply-To: References: Message-ID: Michalis, here?s a different approach I took, and hit a brick wall with all browsers. I did provide a simple initializer, which didn?t appear to change anything. John ---------- Forwarded message --------- From: John Carlson Date: Tue, Feb 4, 2025 at 12:56?AM Subject: Re: Turning on and off simultaneous animations individually To: Andreas Plesch , Michalis Kamburelis < michalis.kambi at gmail.com>, Holger Seelig , GPU Group CC: X3D Graphics public mailing list , Joe D Williams Indeed, moving the TimeSensor USE to a fieldValue makes Castle report this: castle-model-converter: Warning: X3D: Route destination node name "clock" not found castle-model-converter: Warning: X3D: Route destination node name "clock" not found castle-model-converter: Warning: X3D: Route destination node name "clock" not found Seems like I've made a full circle. Now I can't get anything to work. So option B) sounds really good, and I'll just recommend Sunrize, or do scripting. What I can try to do is provide an initializer value to clock in ProtoInterface. see attachment. John On Mon, Feb 3, 2025 at 12:11?AM John Carlson wrote: > I have no problems with your thinking Andreas. My only questions are 1) > Why am I chosen to find these corner cases? 2) Can Castle Model Viewer > support ECMAScript soon, perhaps in an Electron or better WebView? 3) It > would seem like ProtoInterface field accessType="outputOnly" needs to be > treated specially. > > Primarily, I am concerned that A) alone will not solve 3) above and B) may > be required. Castle Model Viewer already has A), which is helpful, but I > don't have a workaround yet. > > On Sun, Feb 2, 2025 at 10:40?PM Andreas Plesch > wrote: > >> Apologies in advance if the following comes across as a bit of >> rigid thinking for a corner case but unfortunately there is now an example. >> A larger standard question is how to correctly process a fieldValue >> statement with a default value for the value attribute. >> The XML schema for fieldValue says that the default value for the value >> attribute is "", the empty string. Relying on that default is rarely, >> perhaps never, a useful use of fieldValue but is allowed. >> >> Scenario A) >> In the case the field for which such a fieldValue is given is of type >> SFTime, this would strictly mean that the value is invalid since the "" is >> not an encoding of a floating point number and does not pass the regex >> test. Therefore processing could become undefined and should be halted. >> >> Scenario B) >> Another, perhaps less strict but more useful interpretation is that the >> empty string for SFTime signals the lack of a value and that therefore a >> default value for the SFTime field should be adopted. This default could be >> an initial -1 as the Tooltips suggest, and would likely be overwritten. >> >> A) is stricter and follows the rules more literally. B) is perhaps >> more often what authors intend but may need some clarification in the >> specification. >> >> This applies only to the XML encoding. >> >> I think the XML encoding for fieldValue should require one of: an >> existing value attribute, or at least one child node (as a XFNode value). >> Not sure if the XML schema could handle that. >> >> Would you prefer A) or B) ? >> >> Personally A) with some error messages but some X3D browsers accept B). >> >> Thanks, Andreas >> >> >> On Sun, Feb 2, 2025 at 4:58?PM Andreas Plesch >> wrote: >> >>> I think x3dom, reasonably, expects a value for the fieldValue nodes: >>> >>> For example: >>> >>> >>> >>> and others. >>> >>> On Sun, Feb 2, 2025 at 5:42?AM John Carlson wrote: >>> >>>> Andreas, Joe, >>>> >>>> Reset Button, Reset_Clock added. >>>> >>>> See attached zip for details, or visit link; >>>> >>>> >>>> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>> >>>> For some reason, this link doesn't show the live scene? >>>> >>>> >>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>> >>>> Puzzled, haven't researched it yet. Looks good in Sunrize and X_ITE, >>>> will try FreeWRL next. >>>> >>>> John >>>> >>>>> >>> >>> -- >>> Andreas Plesch >>> Waltham, MA 02453 >>> >> >> >> -- >> Andreas Plesch >> Waltham, MA 02453 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Clocks5.zip Type: application/zip Size: 249729 bytes Desc: not available URL: From yottzumm at gmail.com Tue Feb 4 14:49:31 2025 From: yottzumm at gmail.com (John Carlson) Date: Tue, 4 Feb 2025 16:49:31 -0600 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: Message-ID: But probably the issue could have been I didn?t use a DEF in the in the initializer. John On Tue, Feb 4, 2025 at 4:45?PM John Carlson wrote: > Michalis, here?s a different approach I took, and hit a brick wall with > all browsers. > > I did provide a simple initializer, which didn?t appear to change anything. > > John > ---------- Forwarded message --------- > From: John Carlson > Date: Tue, Feb 4, 2025 at 12:56?AM > Subject: Re: Turning on and off simultaneous animations individually > To: Andreas Plesch , Michalis Kamburelis < > michalis.kambi at gmail.com>, Holger Seelig , GPU > Group > CC: X3D Graphics public mailing list , Joe D > Williams > > > Indeed, moving the TimeSensor USE to a fieldValue makes Castle report > this: > > castle-model-converter: Warning: X3D: Route destination node name "clock" > not found > castle-model-converter: Warning: X3D: Route destination node name "clock" > not found > castle-model-converter: Warning: X3D: Route destination node name "clock" > not found > > > Seems like I've made a full circle. Now I can't get anything to work. > > So option B) sounds really good, and I'll just recommend Sunrize, or do > scripting. > > What I can try to do is provide an initializer value to clock in > ProtoInterface. > > see attachment. > > John > > On Mon, Feb 3, 2025 at 12:11?AM John Carlson wrote: > >> I have no problems with your thinking Andreas. My only questions are 1) >> Why am I chosen to find these corner cases? 2) Can Castle Model Viewer >> support ECMAScript soon, perhaps in an Electron or better WebView? 3) It >> would seem like ProtoInterface field accessType="outputOnly" needs to be >> treated specially. >> >> Primarily, I am concerned that A) alone will not solve 3) above and B) >> may be required. Castle Model Viewer already has A), which is helpful, but >> I don't have a workaround yet. >> >> On Sun, Feb 2, 2025 at 10:40?PM Andreas Plesch >> wrote: >> >>> Apologies in advance if the following comes across as a bit of >>> rigid thinking for a corner case but unfortunately there is now an example. >>> A larger standard question is how to correctly process a fieldValue >>> statement with a default value for the value attribute. >>> The XML schema for fieldValue says that the default value for the value >>> attribute is "", the empty string. Relying on that default is rarely, >>> perhaps never, a useful use of fieldValue but is allowed. >>> >>> Scenario A) >>> In the case the field for which such a fieldValue is given is of type >>> SFTime, this would strictly mean that the value is invalid since the "" is >>> not an encoding of a floating point number and does not pass the regex >>> test. Therefore processing could become undefined and should be halted. >>> >>> Scenario B) >>> Another, perhaps less strict but more useful interpretation is that the >>> empty string for SFTime signals the lack of a value and that therefore a >>> default value for the SFTime field should be adopted. This default could be >>> an initial -1 as the Tooltips suggest, and would likely be overwritten. >>> >>> A) is stricter and follows the rules more literally. B) is perhaps >>> more often what authors intend but may need some clarification in the >>> specification. >>> >>> This applies only to the XML encoding. >>> >>> I think the XML encoding for fieldValue should require one of: an >>> existing value attribute, or at least one child node (as a XFNode value). >>> Not sure if the XML schema could handle that. >>> >>> Would you prefer A) or B) ? >>> >>> Personally A) with some error messages but some X3D browsers accept B). >>> >>> Thanks, Andreas >>> >>> >>> On Sun, Feb 2, 2025 at 4:58?PM Andreas Plesch >>> wrote: >>> >>>> I think x3dom, reasonably, expects a value for the fieldValue nodes: >>>> >>>> For example: >>>> >>>> >>>> >>>> and others. >>>> >>>> On Sun, Feb 2, 2025 at 5:42?AM John Carlson wrote: >>>> >>>>> Andreas, Joe, >>>>> >>>>> Reset Button, Reset_Clock added. >>>>> >>>>> See attached zip for details, or visit link; >>>>> >>>>> >>>>> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>> >>>>> For some reason, this link doesn't show the live scene? >>>>> >>>>> >>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>> >>>>> Puzzled, haven't researched it yet. Looks good in Sunrize and X_ITE, >>>>> will try FreeWRL next. >>>>> >>>>> John >>>>> >>>>>> >>>> >>>> -- >>>> Andreas Plesch >>>> Waltham, MA 02453 >>>> >>> >>> >>> -- >>> Andreas Plesch >>> Waltham, MA 02453 >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Tue Feb 4 15:51:09 2025 From: yottzumm at gmail.com (John Carlson) Date: Tue, 4 Feb 2025 17:51:09 -0600 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: Message-ID: Applying a DEF in the name=?clock? SFNode field instead of a referring to ?clock? in a ROUTE just seems super weird unless all TimeSensors somehow become identical. But I?m at wits end currently. Just grasping at anything. Does someone have an example of IMPORT/EXPORT with my example or some equivalent with Inline which might work? Much of my example is based on Andreas work. Maybe we could start from Andreas work and add buttons which start and stop multiple animations? On Tue, Feb 4, 2025 at 4:49?PM John Carlson wrote: > But probably the issue could have been I didn?t use a DEF in the in the > initializer. > > John > On Tue, Feb 4, 2025 at 4:45?PM John Carlson wrote: > >> Michalis, here?s a different approach I took, and hit a brick wall with >> all browsers. >> >> I did provide a simple initializer, which didn?t appear to change >> anything. >> >> John >> ---------- Forwarded message --------- >> From: John Carlson >> Date: Tue, Feb 4, 2025 at 12:56?AM >> Subject: Re: Turning on and off simultaneous animations individually >> To: Andreas Plesch , Michalis Kamburelis < >> michalis.kambi at gmail.com>, Holger Seelig , GPU >> Group >> CC: X3D Graphics public mailing list , Joe D >> Williams >> >> >> Indeed, moving the TimeSensor USE to a fieldValue makes Castle report >> this: >> >> castle-model-converter: Warning: X3D: Route destination node name "clock" >> not found >> castle-model-converter: Warning: X3D: Route destination node name "clock" >> not found >> castle-model-converter: Warning: X3D: Route destination node name "clock" >> not found >> >> >> Seems like I've made a full circle. Now I can't get anything to work. >> >> So option B) sounds really good, and I'll just recommend Sunrize, or do >> scripting. >> >> What I can try to do is provide an initializer value to clock in >> ProtoInterface. >> >> see attachment. >> >> John >> >> On Mon, Feb 3, 2025 at 12:11?AM John Carlson wrote: >> >>> I have no problems with your thinking Andreas. My only questions are 1) >>> Why am I chosen to find these corner cases? 2) Can Castle Model Viewer >>> support ECMAScript soon, perhaps in an Electron or better WebView? 3) It >>> would seem like ProtoInterface field accessType="outputOnly" needs to be >>> treated specially. >>> >>> Primarily, I am concerned that A) alone will not solve 3) above and B) >>> may be required. Castle Model Viewer already has A), which is helpful, but >>> I don't have a workaround yet. >>> >>> On Sun, Feb 2, 2025 at 10:40?PM Andreas Plesch >>> wrote: >>> >>>> Apologies in advance if the following comes across as a bit of >>>> rigid thinking for a corner case but unfortunately there is now an example. >>>> A larger standard question is how to correctly process a fieldValue >>>> statement with a default value for the value attribute. >>>> The XML schema for fieldValue says that the default value for the value >>>> attribute is "", the empty string. Relying on that default is rarely, >>>> perhaps never, a useful use of fieldValue but is allowed. >>>> >>>> Scenario A) >>>> In the case the field for which such a fieldValue is given is of type >>>> SFTime, this would strictly mean that the value is invalid since the "" is >>>> not an encoding of a floating point number and does not pass the regex >>>> test. Therefore processing could become undefined and should be halted. >>>> >>>> Scenario B) >>>> Another, perhaps less strict but more useful interpretation is that the >>>> empty string for SFTime signals the lack of a value and that therefore a >>>> default value for the SFTime field should be adopted. This default could be >>>> an initial -1 as the Tooltips suggest, and would likely be overwritten. >>>> >>>> A) is stricter and follows the rules more literally. B) is perhaps >>>> more often what authors intend but may need some clarification in the >>>> specification. >>>> >>>> This applies only to the XML encoding. >>>> >>>> I think the XML encoding for fieldValue should require one of: an >>>> existing value attribute, or at least one child node (as a XFNode value). >>>> Not sure if the XML schema could handle that. >>>> >>>> Would you prefer A) or B) ? >>>> >>>> Personally A) with some error messages but some X3D browsers accept B). >>>> >>>> Thanks, Andreas >>>> >>>> >>>> On Sun, Feb 2, 2025 at 4:58?PM Andreas Plesch >>>> wrote: >>>> >>>>> I think x3dom, reasonably, expects a value for the fieldValue nodes: >>>>> >>>>> For example: >>>>> >>>>> >>>>> >>>>> and others. >>>>> >>>>> On Sun, Feb 2, 2025 at 5:42?AM John Carlson >>>>> wrote: >>>>> >>>>>> Andreas, Joe, >>>>>> >>>>>> Reset Button, Reset_Clock added. >>>>>> >>>>>> See attached zip for details, or visit link; >>>>>> >>>>>> >>>>>> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>> >>>>>> For some reason, this link doesn't show the live scene? >>>>>> >>>>>> >>>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>> >>>>>> Puzzled, haven't researched it yet. Looks good in Sunrize and X_ITE, >>>>>> will try FreeWRL next. >>>>>> >>>>>> John >>>>>> >>>>>>> >>>>> >>>>> -- >>>>> Andreas Plesch >>>>> Waltham, MA 02453 >>>>> >>>> >>>> >>>> -- >>>> Andreas Plesch >>>> Waltham, MA 02453 >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From michalis.kambi at gmail.com Wed Feb 5 03:01:04 2025 From: michalis.kambi at gmail.com (Michalis Kamburelis) Date: Wed, 5 Feb 2025 12:01:04 +0100 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: <2572A7BF-F34E-480C-9DB1-25F51D84AA61@yahoo.de> Message-ID: Hello, Again, sorry for not following this thread as a whole -- I'm admittedly commenting only on a subset of this thread mentioning castle-model-xxx tools :) As for this statement "These s are mentioned in ROUTEs outside the Proto. Search for Reset and Reset_Clock, for example.": This is not necessary. That is, your sentence suggests that you think you *need* to list all fields/events using inside ProtoInstance to later refer to them using ROUTE. But that's not true. All the fields/events that you declared in ProtoDeclare are automatically available in every prototype instance and are available to be used to ROUTEs. There's no need to list them using inside ProtoInstance. The inside ProtoInstance shall be necessary only when you want to customize some field's value, i.e. specify a different value than the default ("default value" meaning here "value specified at ProtoDeclare"). Here I speak about what I believe specification says, and how CGE implementation works . I do not have experience using PROTOs in X3DOM or X_ITE. Regards, Michalis wt., 4 lut 2025 o 23:16 John Carlson napisa?(a): > > Comments inline. > On Tue, Feb 4, 2025 at 3:23?PM Michalis Kamburelis wrote: >> >> Hi, >> >> Sorry for not following this thread from the start, I just saw a >> mention of castle-model-converter making warnings on the testcase. I >> confirm they also occur with latest Castle Model Viewer. >> >> Looking at the testcase, I think Castle Model Viewer/Converter >> warnings are right. They say: >> >> """ >> X3D: X3D XML: element references unknown field name "startTime" >> X3D: X3D XML: element references unknown field name "stopTime" >> X3D: X3D XML: element references unknown field name "enabled" >> """ >> >> because you have XML elements >> >> >> >> >> >> inside the prototype instance of MenuItem (> name="MenuItem">). >> >> But the prototype declaration () says >> these are "output only" events. They are "events", not fields, so >> strictly speaking they have no "persistent" value, at least that's how >> X3D specification treats them. (And that's how CGE implements them, >> events really hold no persistent value, they only pass values.) >> >> """ >> > value='0' /> >> >> > value='false'/> >> """ >> >> I understand that for JS scripts, it may make sense to specify a value >> even for outputOnly field (if one accesses from JS Script a value of >> output event that wasn't yet generated, which I understand is possible >> from standard JS API), but that's X3DOM extension, as Andreas pointed >> out. > > > More recent versions have not included any Script nodes. That?s the main current requirement. >> >> >> >> I don't think spec allows to specify values for such output events -- >> again, they are not even "fields" using spec terminology, so >> "fieldValue" would be confusing :) The spec specifies "default value >> of an uninitialized xxx field" in >> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/fieldTypes.html >> to serve as a fallback in edge-cases, like above. > > > Interesting take on events versus fields. >> >> >> >> Moreover, note that in this specific case, these do not seem to serve >> any purpose. XML elements >> >> >> >> >> >> .... do not actually contain any value :) ( Again, sorry for not >> following this thread from start -- I do not know how the file was >> generated/created. ) I looks like they should just be removed. > > > These s are mentioned in ROUTEs outside the Proto. Search for Reset and Reset_Clock, for example. > > I will try to create a simple example, but this is super frustrating to get anything beyond Sunrize and X_ITE working. Sunrize won?t allow me to pass a TimeSensor USE into a Proto, and ROUTE to the TimeSensor inside the Proto, so that?s super frustrating too. Maybe I should use type=?TimeSensor? in the interface? > > The time triggers inside the Proto pretty much require the use of outputOnly. Suggestions for other options would be helpful. These lines look problematic: > > > > > > > > > > Since I can?t ?input? triggerTime, it requires that I use outputOnly. > > > >> >> Regards, >> Michalis >> >> wt., 4 lut 2025 o 21:55 John Carlson napisa?(a): >> > >> > I have added default values in the ProtoDeclare for outputOnly fields, reverting back to passing out startTime, stopTime and enabled. >> > >> > Referring to this repository: >> > >> > https://github.com/coderextreme/ci2had/ >> > >> > I primarily wish to get this working: https://github.com/coderextreme/ci2had/blob/main/resources/CleanedYouClocks.x3d, but first, I want to get ManyClocks.x3d working, because it precedes CleanedYouClocks.x3d, but feel free to get it working first (it's a cleaned up version). >> > >> > If all else fails, I'll probably strip out the Proto (ugh!). >> > -------------------------------------------------------------- >> > I have confirmed that this doesn't animate: >> > >> > https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/ManyClocks.x3d >> > -------------------------------------------------------------- >> > This does animate: >> > >> > https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/ManyClocks.x3d >> > --------------------------------------------------------------- >> > Castle Model Converter produces errors. The viewer doesn't animate, probably because I use HAnimDisplacers. There are no scripts, in an attempt to appease people who don't like scripts. We now have a good example that has HAnimDisplacers, but no scripts. >> > >> > $ ~/Downloads/castle-model-viewer-5.3.0-win64-x86_64/castle-model-viewer/castle-model-converter.exe --validate resources/ManyClocks.x3d 2>&1 |sort -u >> > castle-model-converter: Warning: X3D: X3D XML: element references unknown field name "enabled" >> > castle-model-converter: Warning: X3D: X3D XML: element references unknown field name "startTime" >> > castle-model-converter: Warning: X3D: X3D XML: element references unknown field name "stopTime" >> > Exception "Exception": >> > Validation failed (consult the warnings above), exiting with non-zero status >> > --------------------------------------------------------------- >> > FreeWRL kills JavaScript for some reason (there's no Script), but still doesn;'t animate (try pressing Fear). >> > >> > $ /c/Program\ Files\ \(x86\)/freeWRL/freeWRL.6.7/freeWRL.exe resources/ManyClocks.x3d >> > >> > MidiInWinMM::initialize: no MIDI input devices currently available. >> > >> > libfreewrl version 6.7.0 >> > -h for commandline use >> > openGL version 4.6.0 NVIDIA 560.94 >> > GLSL shader max version 4.60 NVIDIA 460 >> > maximum texture size system/gpu: 32768 runtime/freewrl: 16384 >> > processor architecture x64 >> > maxiumum image texture units 32 >> > depth bits 24 >> > Skinning Method: GPU >> > calling kill_javascript() >> > done kill_javascript >> > Ending texture load thread gracefully >> > finalizeRenderSceneUpdateScene >> > --------------------------------------------------------------------------------------------------- >> > Schematron reports a bunch of problems, all of which I ignore. See attached. log and build.xml >> > --------------------------------------------------------------------------------------------------- >> > There are many info issues when validating with X3DJSAIL, but I'm not sure about this one: >> > $ java -cp ~/Downloads/X3DJSAIL.4.0.full.jar org.web3d.x3d.jsail.CommandLine -validate resources/ManyClocks.x3d|grep -v >> > info >> > [snip] >> > org.web3d.x3d.sai.InvalidFieldException: IndexedFaceSet containing TextureCoordinate node with 295 values must also include texCoordIndex or coordIndex field >> > at org.web3d.x3d.jsail.Geometry3D.IndexedFaceSet.validate(IndexedFaceSet.java:3756) >> > at org.web3d.x3d.jsail.Shape.Shape.validate(Shape.java:2060) >> > at org.web3d.x3d.jsail.Grouping.Transform.validate(Transform.java:2556) >> > at org.web3d.x3d.jsail.HAnim.HAnimSegment.validate(HAnimSegment.java:6175) >> > at org.web3d.x3d.jsail.HAnim.HAnimJoint.validate(HAnimJoint.java:7476) >> > at org.web3d.x3d.jsail.HAnim.HAnimJoint.validate(HAnimJoint.java:7476) >> > at org.web3d.x3d.jsail.HAnim.HAnimHumanoid.validate(HAnimHumanoid.java:6317) >> > at org.web3d.x3d.jsail.Grouping.Transform.validate(Transform.java:2556) >> > at org.web3d.x3d.jsail.Core.Scene.validate(Scene.java:869) >> > at org.web3d.x3d.jsail.Core.X3D.validate(X3D.java:4549) >> > at org.web3d.x3d.jsail.CommandLine.run(CommandLine.java:1098) >> > at org.web3d.x3d.jsail.CommandLine.main(CommandLine.java:242) >> > >> > I don't have a recent version of X3DJSAIL >> > >> > On Tue, Feb 4, 2025 at 2:22?PM Andreas Plesch wrote: >> >> >> >> Thanks, exactly what I was looking for. >> >> >> >> Best, Andreas >> >> >> >> >> >> On Tue, Feb 4, 2025, 2:01?PM Holger Seelig wrote: >> >>> >> >>> The default value for a field is either specified for each node type or the default value for Script or ComposedShader node custom fields is defined in https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/fieldTypes.html. Mostly false, 0, ??, identity, ... >> >>> >> >>> A proto instance will inherit its default values from the proto declaration its fields. Fields such as outputOnly will normally have a default value from fieldTypes.html. >> >>> >> >>> There is an exception with X3DInterpolatorNode.value_changed: >> >>> >> >>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/interpolators.html#X3DInterpolatorNode >> >>> >> >>> If an X3DInterpolatorNode value_changed outputOnly field is read before it receives any inputs, keyValue[0] is returned if keyValue is not empty... >> >>> >> >>> Best regards, >> >>> Holger >> >>> >> >>> -- >> >>> Holger Seelig >> >>> Leipzig, Germany >> >>> >> >>> holger.seelig at yahoo.de >> >>> https://create3000.github.io/x_ite/ >> >>> >> >>> Am 04.02.2025 um 19:26 schrieb Andreas Plesch via x3d-public : >> >>> >> >>> Hi John, all, >> >>> >> >>> It turns out that x3dom currently expects a default value for Proto fields even for outputOnly fields. This is due to how Proto fields are initialized. They always need to have a value. While the spec. does not require this, it seems still good practice to always define a default value in the ProtoInterface. There may be a case where an outputOnly field is used in ISing where a valid value would be expected. There may be other corner cases. >> >>> >> >>> Here is your example with added default values for outputOnly fields: >> >>> >> >>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/af5ff3148c1159f71d34fb78c1f63024/raw/b3d4470107ab74e301ed48448ab2a4f4154672e0/ManyClocks_John.x3d >> >>> >> >>> This could be fixed in x3dom, by always setting some default value. Is there a list of recommended defaults for each data type if no other source of defaults is available? For SFTime it seems to be -1. >> >>> >> >>> -Andreas >> >>> >> >>> >> >>> On Mon, Feb 3, 2025 at 7:39?AM Andreas Plesch wrote: >> >>>> >> >>>> Hi John, >> >>>> >> >>>> On Mon, Feb 3, 2025 at 12:48?AM John Carlson wrote: >> >>>>> >> >>>>> Andreas, "startTime" is an accessType outputOnly field, so why do I need to provide a value attribute in fieldValue? I'm kind of confused. I'm probably missing something in the spec. >> >>>> >> >>>> >> >>>> You are right, I only outlined scenarios where the accessType allows input or initialization.. >> >>>> In the outputOnly case it is not necessary to provide a fieldValue node at all since there is no value which can be provided. Providing the node would indeed be confusing, to both the user code reader and any X3D browser. >> >>>> I believe the spec. is silent on this case in any encoding. >> >>>> >> >>>> Best, Andreas >> >>>> >> >>>>> Thanks for any clarification. >> >>>>> >> >>>>> I have finally enabled schematron on the project, but I'm finding it hard to understand the messages, and modifications that I make, while removing the immediate problems, seem to move the problems elsewhere. >> >>>>> >> >>>>> Explaining why I need a "startTime" fieldValue value is my main lack of understanding, but perhaps I need a whole review of accessType. >> >>>>> >> >>>>> Castle Model Converter reports: >> >>>>> >> >>>>> castle-model-converter: Warning: X3D: X3D XML: element references unknown field name "enabled" >> >>>>> castle-model-converter: Warning: X3D: X3D XML: element references unknown field name "startTime" >> >>>>> castle-model-converter: Warning: X3D: X3D XML: element references unknown field name "stopTime" >> >>>>> >> >>>>> I will try providing a field value in the ProtoInterface >> >>>>> >> >>>>> If I "cleanup" enabled, startTime and stopTime, I get: >> >>>>> >> >>>>> castle-model-converter: Warning: VRML/X3D: Within prototype "MenuItem", event "inputTrue" references (by "IS" clause) non-existing event "enabled" >> >>>>> castle-model-converter: Warning: VRML/X3D: Within prototype "MenuItem", event "triggerTime" references (by "IS" clause) non-existing event "startTime" >> >>>>> castle-model-converter: Warning: VRML/X3D: Within prototype "MenuItem", event "triggerTime" references (by "IS" clause) non-existing event "stopTime" >> >>>>> >> >>>>> I guess what I conclude at this point is, startTime and stopTime are bad DEF names, but what about enabled as a field? The dominoes are falling. >> >>>>> >> >>>>> About your two scenarios in the other message, perhaps this is revealing. >> >>>>> >> >>>>> See attached attempt to fix original issue, which resulted in the above. >> >>>>> >> >>>>> John >> >>>>> >> >>>>> On Sun, Feb 2, 2025 at 3:59?PM Andreas Plesch wrote: >> >>>>>> >> >>>>>> I think x3dom, reasonably, expects a value for the fieldValue nodes: >> >>>>>> >> >>>>>> For example: >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> and others. >> >>>>>> >> >>>>>> On Sun, Feb 2, 2025 at 5:42?AM John Carlson wrote: >> >>>>>>> >> >>>>>>> Andreas, Joe, >> >>>>>>> >> >>>>>>> Reset Button, Reset_Clock added. >> >>>>>>> >> >>>>>>> See attached zip for details, or visit link; >> >>>>>>> >> >>>>>>> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >> >>>>>>> >> >>>>>>> For some reason, this link doesn't show the live scene? >> >>>>>>> >> >>>>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >> >>>>>>> >> >>>>>>> Puzzled, haven't researched it yet. Looks good in Sunrize and X_ITE, will try FreeWRL next. >> >>>>>>> >> >>>>>>> John >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> -- >> >>>>>> Andreas Plesch >> >>>>>> Waltham, MA 02453 >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> Andreas Plesch >> >>>> Waltham, MA 02453 >> >>> >> >>> >> >>> >> >>> -- >> >>> Andreas Plesch >> >>> Waltham, MA 02453 >> >>> _______________________________________________ >> >>> x3d-public mailing list >> >>> x3d-public at web3d.org >> >>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >> >>> >> >>> From yottzumm at gmail.com Wed Feb 5 08:16:38 2025 From: yottzumm at gmail.com (John Carlson) Date: Wed, 5 Feb 2025 10:16:38 -0600 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: <2572A7BF-F34E-480C-9DB1-25F51D84AA61@yahoo.de> Message-ID: Okay, that?s much clearer. Hopefully others can weigh in. I?ll try removing the offending s. John On Wed, Feb 5, 2025 at 5:01?AM Michalis Kamburelis wrote: > Hello, > > Again, sorry for not following this thread as a whole -- I'm > admittedly commenting only on a subset of this thread mentioning > castle-model-xxx tools :) > > As for this statement "These s are mentioned in ROUTEs > outside the Proto. Search for Reset and Reset_Clock, for example.": > This is not necessary. That is, your sentence suggests that you think > you *need* to list all fields/events using inside > ProtoInstance to later refer to them using ROUTE. But that's not true. > All the fields/events that you declared in ProtoDeclare are > automatically available in every prototype instance and are available > to be used to ROUTEs. There's no need to list them using > inside ProtoInstance. The inside ProtoInstance shall be > necessary only when you want to customize some field's value, i.e. > specify a different value than the default ("default value" meaning > here "value specified at ProtoDeclare"). > > Here I speak about what I believe specification says, and how CGE > implementation works . I do not have experience using PROTOs in X3DOM > or X_ITE. > > Regards, > Michalis > > wt., 4 lut 2025 o 23:16 John Carlson napisa?(a): > > > > Comments inline. > > On Tue, Feb 4, 2025 at 3:23?PM Michalis Kamburelis < > michalis.kambi at gmail.com> wrote: > >> > >> Hi, > >> > >> Sorry for not following this thread from the start, I just saw a > >> mention of castle-model-converter making warnings on the testcase. I > >> confirm they also occur with latest Castle Model Viewer. > >> > >> Looking at the testcase, I think Castle Model Viewer/Converter > >> warnings are right. They say: > >> > >> """ > >> X3D: X3D XML: element references unknown field name > "startTime" > >> X3D: X3D XML: element references unknown field name > "stopTime" > >> X3D: X3D XML: element references unknown field name > "enabled" > >> """ > >> > >> because you have XML elements > >> > >> > >> > >> > >> > >> inside the prototype instance of MenuItem ( >> name="MenuItem">). > >> > >> But the prototype declaration () says > >> these are "output only" events. They are "events", not fields, so > >> strictly speaking they have no "persistent" value, at least that's how > >> X3D specification treats them. (And that's how CGE implements them, > >> events really hold no persistent value, they only pass values.) > >> > >> """ > >> >> value='0' /> > >> value='0'/> > >> >> value='false'/> > >> """ > >> > >> I understand that for JS scripts, it may make sense to specify a value > >> even for outputOnly field (if one accesses from JS Script a value of > >> output event that wasn't yet generated, which I understand is possible > >> from standard JS API), but that's X3DOM extension, as Andreas pointed > >> out. > > > > > > More recent versions have not included any Script nodes. That?s the > main current requirement. > >> > >> > >> > >> I don't think spec allows to specify values for such output events -- > >> again, they are not even "fields" using spec terminology, so > >> "fieldValue" would be confusing :) The spec specifies "default value > >> of an uninitialized xxx field" in > >> > https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/fieldTypes.html > >> to serve as a fallback in edge-cases, like above. > > > > > > Interesting take on events versus fields. > >> > >> > >> > >> Moreover, note that in this specific case, these do not seem to serve > >> any purpose. XML elements > >> > >> > >> > >> > >> > >> .... do not actually contain any value :) ( Again, sorry for not > >> following this thread from start -- I do not know how the file was > >> generated/created. ) I looks like they should just be removed. > > > > > > These s are mentioned in ROUTEs outside the Proto. Search > for Reset and Reset_Clock, for example. > > > > I will try to create a simple example, but this is super frustrating to > get anything beyond Sunrize and X_ITE working. Sunrize won?t allow me to > pass a TimeSensor USE into a Proto, and ROUTE to the TimeSensor inside the > Proto, so that?s super frustrating too. Maybe I should use > type=?TimeSensor? in the interface? > > > > The time triggers inside the Proto pretty much require the use of > outputOnly. Suggestions for other options would be helpful. These lines > look problematic: > > > > > > > > > > > > > protoField='stopTime'/> > > > > protoField='enabled'/> > > > > Since I can?t ?input? triggerTime, it requires that I use outputOnly. > > > > > > > >> > >> Regards, > >> Michalis > >> > >> wt., 4 lut 2025 o 21:55 John Carlson napisa?(a): > >> > > >> > I have added default values in the ProtoDeclare for outputOnly > fields, reverting back to passing out startTime, stopTime and enabled. > >> > > >> > Referring to this repository: > >> > > >> > https://github.com/coderextreme/ci2had/ > >> > > >> > I primarily wish to get this working: > https://github.com/coderextreme/ci2had/blob/main/resources/CleanedYouClocks.x3d, > but first, I want to get ManyClocks.x3d working, because it precedes > CleanedYouClocks.x3d, but feel free to get it working first (it's a cleaned > up version). > >> > > >> > If all else fails, I'll probably strip out the Proto (ugh!). > >> > -------------------------------------------------------------- > >> > I have confirmed that this doesn't animate: > >> > > >> > > https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/ManyClocks.x3d > >> > -------------------------------------------------------------- > >> > This does animate: > >> > > >> > > https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/ManyClocks.x3d > >> > --------------------------------------------------------------- > >> > Castle Model Converter produces errors. The viewer doesn't animate, > probably because I use HAnimDisplacers. There are no scripts, in an attempt > to appease people who don't like scripts. We now have a good example that > has HAnimDisplacers, but no scripts. > >> > > >> > $ > ~/Downloads/castle-model-viewer-5.3.0-win64-x86_64/castle-model-viewer/castle-model-converter.exe > --validate resources/ManyClocks.x3d 2>&1 |sort -u > >> > castle-model-converter: Warning: X3D: X3D XML: element > references unknown field name "enabled" > >> > castle-model-converter: Warning: X3D: X3D XML: element > references unknown field name "startTime" > >> > castle-model-converter: Warning: X3D: X3D XML: element > references unknown field name "stopTime" > >> > Exception "Exception": > >> > Validation failed (consult the warnings above), exiting with non-zero > status > >> > --------------------------------------------------------------- > >> > FreeWRL kills JavaScript for some reason (there's no Script), but > still doesn;'t animate (try pressing Fear). > >> > > >> > $ /c/Program\ Files\ \(x86\)/freeWRL/freeWRL.6.7/freeWRL.exe > resources/ManyClocks.x3d > >> > > >> > MidiInWinMM::initialize: no MIDI input devices currently available. > >> > > >> > libfreewrl version 6.7.0 > >> > -h for commandline use > >> > openGL version 4.6.0 NVIDIA 560.94 > >> > GLSL shader max version 4.60 NVIDIA 460 > >> > maximum texture size system/gpu: 32768 runtime/freewrl: 16384 > >> > processor architecture x64 > >> > maxiumum image texture units 32 > >> > depth bits 24 > >> > Skinning Method: GPU > >> > calling kill_javascript() > >> > done kill_javascript > >> > Ending texture load thread gracefully > >> > finalizeRenderSceneUpdateScene > >> > > --------------------------------------------------------------------------------------------------- > >> > Schematron reports a bunch of problems, all of which I ignore. See > attached. log and build.xml > >> > > --------------------------------------------------------------------------------------------------- > >> > There are many info issues when validating with X3DJSAIL, but I'm not > sure about this one: > >> > $ java -cp ~/Downloads/X3DJSAIL.4.0.full.jar > org.web3d.x3d.jsail.CommandLine -validate resources/ManyClocks.x3d|grep -v > >> > info > >> > [snip] > >> > org.web3d.x3d.sai.InvalidFieldException: IndexedFaceSet containing > TextureCoordinate node with 295 values must also include texCoordIndex or > coordIndex field > >> > at > org.web3d.x3d.jsail.Geometry3D.IndexedFaceSet.validate(IndexedFaceSet.java:3756) > >> > at org.web3d.x3d.jsail.Shape.Shape.validate(Shape.java:2060) > >> > at > org.web3d.x3d.jsail.Grouping.Transform.validate(Transform.java:2556) > >> > at > org.web3d.x3d.jsail.HAnim.HAnimSegment.validate(HAnimSegment.java:6175) > >> > at > org.web3d.x3d.jsail.HAnim.HAnimJoint.validate(HAnimJoint.java:7476) > >> > at > org.web3d.x3d.jsail.HAnim.HAnimJoint.validate(HAnimJoint.java:7476) > >> > at > org.web3d.x3d.jsail.HAnim.HAnimHumanoid.validate(HAnimHumanoid.java:6317) > >> > at > org.web3d.x3d.jsail.Grouping.Transform.validate(Transform.java:2556) > >> > at org.web3d.x3d.jsail.Core.Scene.validate(Scene.java:869) > >> > at org.web3d.x3d.jsail.Core.X3D.validate(X3D.java:4549) > >> > at org.web3d.x3d.jsail.CommandLine.run(CommandLine.java:1098) > >> > at org.web3d.x3d.jsail.CommandLine.main(CommandLine.java:242) > >> > > >> > I don't have a recent version of X3DJSAIL > >> > > >> > On Tue, Feb 4, 2025 at 2:22?PM Andreas Plesch < > andreasplesch at gmail.com> wrote: > >> >> > >> >> Thanks, exactly what I was looking for. > >> >> > >> >> Best, Andreas > >> >> > >> >> > >> >> On Tue, Feb 4, 2025, 2:01?PM Holger Seelig > wrote: > >> >>> > >> >>> The default value for a field is either specified for each node > type or the default value for Script or ComposedShader node custom fields > is defined in > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/fieldTypes.html. > Mostly false, 0, ??, identity, ... > >> >>> > >> >>> A proto instance will inherit its default values from the proto > declaration its fields. Fields such as outputOnly will normally have a > default value from fieldTypes.html. > >> >>> > >> >>> There is an exception with X3DInterpolatorNode.value_changed: > >> >>> > >> >>> > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/interpolators.html#X3DInterpolatorNode > >> >>> > >> >>> If an X3DInterpolatorNode value_changed outputOnly field is read > before it receives any inputs, keyValue[0] is returned if keyValue is not > empty... > >> >>> > >> >>> Best regards, > >> >>> Holger > >> >>> > >> >>> -- > >> >>> Holger Seelig > >> >>> Leipzig, Germany > >> >>> > >> >>> holger.seelig at yahoo.de > >> >>> https://create3000.github.io/x_ite/ > >> >>> > >> >>> Am 04.02.2025 um 19:26 schrieb Andreas Plesch via x3d-public < > x3d-public at web3d.org>: > >> >>> > >> >>> Hi John, all, > >> >>> > >> >>> It turns out that x3dom currently expects a default value for Proto > fields even for outputOnly fields. This is due to how Proto fields are > initialized. They always need to have a value. While the spec. does not > require this, it seems still good practice to always define a default value > in the ProtoInterface. There may be a case where an outputOnly field is > used in ISing where a valid value would be expected. There may be other > corner cases. > >> >>> > >> >>> Here is your example with added default values for outputOnly > fields: > >> >>> > >> >>> > https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/af5ff3148c1159f71d34fb78c1f63024/raw/b3d4470107ab74e301ed48448ab2a4f4154672e0/ManyClocks_John.x3d > >> >>> > >> >>> This could be fixed in x3dom, by always setting some default value. > Is there a list of recommended defaults for each data type if no other > source of defaults is available? For SFTime it seems to be -1. > >> >>> > >> >>> -Andreas > >> >>> > >> >>> > >> >>> On Mon, Feb 3, 2025 at 7:39?AM Andreas Plesch < > andreasplesch at gmail.com> wrote: > >> >>>> > >> >>>> Hi John, > >> >>>> > >> >>>> On Mon, Feb 3, 2025 at 12:48?AM John Carlson > wrote: > >> >>>>> > >> >>>>> Andreas, "startTime" is an accessType outputOnly field, so why do > I need to provide a value attribute in fieldValue? I'm kind of confused. > I'm probably missing something in the spec. > >> >>>> > >> >>>> > >> >>>> You are right, I only outlined scenarios where the accessType > allows input or initialization.. > >> >>>> In the outputOnly case it is not necessary to provide a fieldValue > node at all since there is no value which can be provided. Providing the > node would indeed be confusing, to both the user code reader and any X3D > browser. > >> >>>> I believe the spec. is silent on this case in any encoding. > >> >>>> > >> >>>> Best, Andreas > >> >>>> > >> >>>>> Thanks for any clarification. > >> >>>>> > >> >>>>> I have finally enabled schematron on the project, but I'm finding > it hard to understand the messages, and modifications that I make, while > removing the immediate problems, seem to move the problems elsewhere. > >> >>>>> > >> >>>>> Explaining why I need a "startTime" fieldValue value is my main > lack of understanding, but perhaps I need a whole review of accessType. > >> >>>>> > >> >>>>> Castle Model Converter reports: > >> >>>>> > >> >>>>> castle-model-converter: Warning: X3D: X3D XML: > element references unknown field name "enabled" > >> >>>>> castle-model-converter: Warning: X3D: X3D XML: > element references unknown field name "startTime" > >> >>>>> castle-model-converter: Warning: X3D: X3D XML: > element references unknown field name "stopTime" > >> >>>>> > >> >>>>> I will try providing a field value in the ProtoInterface > >> >>>>> > >> >>>>> If I "cleanup" enabled, startTime and stopTime, I get: > >> >>>>> > >> >>>>> castle-model-converter: Warning: VRML/X3D: Within prototype > "MenuItem", event "inputTrue" references (by "IS" clause) non-existing > event "enabled" > >> >>>>> castle-model-converter: Warning: VRML/X3D: Within prototype > "MenuItem", event "triggerTime" references (by "IS" clause) non-existing > event "startTime" > >> >>>>> castle-model-converter: Warning: VRML/X3D: Within prototype > "MenuItem", event "triggerTime" references (by "IS" clause) non-existing > event "stopTime" > >> >>>>> > >> >>>>> I guess what I conclude at this point is, startTime and stopTime > are bad DEF names, but what about enabled as a field? The dominoes are > falling. > >> >>>>> > >> >>>>> About your two scenarios in the other message, perhaps this is > revealing. > >> >>>>> > >> >>>>> See attached attempt to fix original issue, which resulted in the > above. > >> >>>>> > >> >>>>> John > >> >>>>> > >> >>>>> On Sun, Feb 2, 2025 at 3:59?PM Andreas Plesch < > andreasplesch at gmail.com> wrote: > >> >>>>>> > >> >>>>>> I think x3dom, reasonably, expects a value for the fieldValue > nodes: > >> >>>>>> > >> >>>>>> For example: > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> and others. > >> >>>>>> > >> >>>>>> On Sun, Feb 2, 2025 at 5:42?AM John Carlson > wrote: > >> >>>>>>> > >> >>>>>>> Andreas, Joe, > >> >>>>>>> > >> >>>>>>> Reset Button, Reset_Clock added. > >> >>>>>>> > >> >>>>>>> See attached zip for details, or visit link; > >> >>>>>>> > >> >>>>>>> > https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d > >> >>>>>>> > >> >>>>>>> For some reason, this link doesn't show the live scene? > >> >>>>>>> > >> >>>>>>> > https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d > >> >>>>>>> > >> >>>>>>> Puzzled, haven't researched it yet. Looks good in Sunrize and > X_ITE, will try FreeWRL next. > >> >>>>>>> > >> >>>>>>> John > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> -- > >> >>>>>> Andreas Plesch > >> >>>>>> Waltham, MA 02453 > >> >>>> > >> >>>> > >> >>>> > >> >>>> -- > >> >>>> Andreas Plesch > >> >>>> Waltham, MA 02453 > >> >>> > >> >>> > >> >>> > >> >>> -- > >> >>> Andreas Plesch > >> >>> Waltham, MA 02453 > >> >>> _______________________________________________ > >> >>> x3d-public mailing list > >> >>> x3d-public at web3d.org > >> >>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org > >> >>> > >> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Wed Feb 5 09:08:01 2025 From: yottzumm at gmail.com (John Carlson) Date: Wed, 5 Feb 2025 11:08:01 -0600 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: <2572A7BF-F34E-480C-9DB1-25F51D84AA61@yahoo.de> Message-ID: Cleaning up the s that didn't have a value indeed removed the errors found in Castle tools. But the animations still didn't work in X3DOM, Castle or FreeWRL. Thankfully, the animations still worked in Sunrize and X_ITE Playground. Whew! Also, there's no animation here that I can see, as previously reported https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d There appears to be some kind of event loop in log using the following URL, which I couldn't capture yet, when using FreeWRL launcher, using the following URL: https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d Later attempts did not produce any repeated log messages. Hopefully, with this example of HAnimDisplacers that doesn't throw errors, we can soon see HAnimDisplacers in Castle. Further issues found in my example are welcome! John On Wed, Feb 5, 2025 at 10:16?AM John Carlson wrote: > Okay, that?s much clearer. Hopefully others can weigh in. > > I?ll try removing the offending s. > > John > On Wed, Feb 5, 2025 at 5:01?AM Michalis Kamburelis < > michalis.kambi at gmail.com> wrote: > >> Hello, >> >> Again, sorry for not following this thread as a whole -- I'm >> admittedly commenting only on a subset of this thread mentioning >> castle-model-xxx tools :) >> >> As for this statement "These s are mentioned in ROUTEs >> outside the Proto. Search for Reset and Reset_Clock, for example.": >> This is not necessary. That is, your sentence suggests that you think >> you *need* to list all fields/events using inside >> ProtoInstance to later refer to them using ROUTE. But that's not true. >> All the fields/events that you declared in ProtoDeclare are >> automatically available in every prototype instance and are available >> to be used to ROUTEs. There's no need to list them using >> inside ProtoInstance. The inside ProtoInstance shall be >> necessary only when you want to customize some field's value, i.e. >> specify a different value than the default ("default value" meaning >> here "value specified at ProtoDeclare"). >> >> Here I speak about what I believe specification says, and how CGE >> implementation works . I do not have experience using PROTOs in X3DOM >> or X_ITE. >> >> Regards, >> Michalis >> >> wt., 4 lut 2025 o 23:16 John Carlson napisa?(a): >> > >> > Comments inline. >> > On Tue, Feb 4, 2025 at 3:23?PM Michalis Kamburelis < >> michalis.kambi at gmail.com> wrote: >> >> >> >> Hi, >> >> >> >> Sorry for not following this thread from the start, I just saw a >> >> mention of castle-model-converter making warnings on the testcase. I >> >> confirm they also occur with latest Castle Model Viewer. >> >> >> >> Looking at the testcase, I think Castle Model Viewer/Converter >> >> warnings are right. They say: >> >> >> >> """ >> >> X3D: X3D XML: element references unknown field name >> "startTime" >> >> X3D: X3D XML: element references unknown field name >> "stopTime" >> >> X3D: X3D XML: element references unknown field name >> "enabled" >> >> """ >> >> >> >> because you have XML elements >> >> >> >> >> >> >> >> >> >> >> >> inside the prototype instance of MenuItem (> >> name="MenuItem">). >> >> >> >> But the prototype declaration () says >> >> these are "output only" events. They are "events", not fields, so >> >> strictly speaking they have no "persistent" value, at least that's how >> >> X3D specification treats them. (And that's how CGE implements them, >> >> events really hold no persistent value, they only pass values.) >> >> >> >> """ >> >> > >> value='0' /> >> >> > value='0'/> >> >> > >> value='false'/> >> >> """ >> >> >> >> I understand that for JS scripts, it may make sense to specify a value >> >> even for outputOnly field (if one accesses from JS Script a value of >> >> output event that wasn't yet generated, which I understand is possible >> >> from standard JS API), but that's X3DOM extension, as Andreas pointed >> >> out. >> > >> > >> > More recent versions have not included any Script nodes. That?s the >> main current requirement. >> >> >> >> >> >> >> >> I don't think spec allows to specify values for such output events -- >> >> again, they are not even "fields" using spec terminology, so >> >> "fieldValue" would be confusing :) The spec specifies "default value >> >> of an uninitialized xxx field" in >> >> >> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/fieldTypes.html >> >> to serve as a fallback in edge-cases, like above. >> > >> > >> > Interesting take on events versus fields. >> >> >> >> >> >> >> >> Moreover, note that in this specific case, these do not seem to serve >> >> any purpose. XML elements >> >> >> >> >> >> >> >> >> >> >> >> .... do not actually contain any value :) ( Again, sorry for not >> >> following this thread from start -- I do not know how the file was >> >> generated/created. ) I looks like they should just be removed. >> > >> > >> > These s are mentioned in ROUTEs outside the Proto. Search >> for Reset and Reset_Clock, for example. >> > >> > I will try to create a simple example, but this is super frustrating to >> get anything beyond Sunrize and X_ITE working. Sunrize won?t allow me to >> pass a TimeSensor USE into a Proto, and ROUTE to the TimeSensor inside the >> Proto, so that?s super frustrating too. Maybe I should use >> type=?TimeSensor? in the interface? >> > >> > The time triggers inside the Proto pretty much require the use of >> outputOnly. Suggestions for other options would be helpful. These lines >> look problematic: >> > >> > >> > >> > >> >> > >> > > protoField='stopTime'/> >> > >> > > protoField='enabled'/> >> > >> > Since I can?t ?input? triggerTime, it requires that I use outputOnly. >> > >> > >> > >> >> >> >> Regards, >> >> Michalis >> >> >> >> wt., 4 lut 2025 o 21:55 John Carlson napisa?(a): >> >> > >> >> > I have added default values in the ProtoDeclare for outputOnly >> fields, reverting back to passing out startTime, stopTime and enabled. >> >> > >> >> > Referring to this repository: >> >> > >> >> > https://github.com/coderextreme/ci2had/ >> >> > >> >> > I primarily wish to get this working: >> https://github.com/coderextreme/ci2had/blob/main/resources/CleanedYouClocks.x3d, >> but first, I want to get ManyClocks.x3d working, because it precedes >> CleanedYouClocks.x3d, but feel free to get it working first (it's a cleaned >> up version). >> >> > >> >> > If all else fails, I'll probably strip out the Proto (ugh!). >> >> > -------------------------------------------------------------- >> >> > I have confirmed that this doesn't animate: >> >> > >> >> > >> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/ManyClocks.x3d >> >> > -------------------------------------------------------------- >> >> > This does animate: >> >> > >> >> > >> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/ManyClocks.x3d >> >> > --------------------------------------------------------------- >> >> > Castle Model Converter produces errors. The viewer doesn't animate, >> probably because I use HAnimDisplacers. There are no scripts, in an attempt >> to appease people who don't like scripts. We now have a good example that >> has HAnimDisplacers, but no scripts. >> >> > >> >> > $ >> ~/Downloads/castle-model-viewer-5.3.0-win64-x86_64/castle-model-viewer/castle-model-converter.exe >> --validate resources/ManyClocks.x3d 2>&1 |sort -u >> >> > castle-model-converter: Warning: X3D: X3D XML: element >> references unknown field name "enabled" >> >> > castle-model-converter: Warning: X3D: X3D XML: element >> references unknown field name "startTime" >> >> > castle-model-converter: Warning: X3D: X3D XML: element >> references unknown field name "stopTime" >> >> > Exception "Exception": >> >> > Validation failed (consult the warnings above), exiting with >> non-zero status >> >> > --------------------------------------------------------------- >> >> > FreeWRL kills JavaScript for some reason (there's no Script), but >> still doesn;'t animate (try pressing Fear). >> >> > >> >> > $ /c/Program\ Files\ \(x86\)/freeWRL/freeWRL.6.7/freeWRL.exe >> resources/ManyClocks.x3d >> >> > >> >> > MidiInWinMM::initialize: no MIDI input devices currently available. >> >> > >> >> > libfreewrl version 6.7.0 >> >> > -h for commandline use >> >> > openGL version 4.6.0 NVIDIA 560.94 >> >> > GLSL shader max version 4.60 NVIDIA 460 >> >> > maximum texture size system/gpu: 32768 runtime/freewrl: 16384 >> >> > processor architecture x64 >> >> > maxiumum image texture units 32 >> >> > depth bits 24 >> >> > Skinning Method: GPU >> >> > calling kill_javascript() >> >> > done kill_javascript >> >> > Ending texture load thread gracefully >> >> > finalizeRenderSceneUpdateScene >> >> > >> --------------------------------------------------------------------------------------------------- >> >> > Schematron reports a bunch of problems, all of which I ignore. See >> attached. log and build.xml >> >> > >> --------------------------------------------------------------------------------------------------- >> >> > There are many info issues when validating with X3DJSAIL, but I'm >> not sure about this one: >> >> > $ java -cp ~/Downloads/X3DJSAIL.4.0.full.jar >> org.web3d.x3d.jsail.CommandLine -validate resources/ManyClocks.x3d|grep -v >> >> > info >> >> > [snip] >> >> > org.web3d.x3d.sai.InvalidFieldException: IndexedFaceSet containing >> TextureCoordinate node with 295 values must also include texCoordIndex or >> coordIndex field >> >> > at >> org.web3d.x3d.jsail.Geometry3D.IndexedFaceSet.validate(IndexedFaceSet.java:3756) >> >> > at org.web3d.x3d.jsail.Shape.Shape.validate(Shape.java:2060) >> >> > at >> org.web3d.x3d.jsail.Grouping.Transform.validate(Transform.java:2556) >> >> > at >> org.web3d.x3d.jsail.HAnim.HAnimSegment.validate(HAnimSegment.java:6175) >> >> > at >> org.web3d.x3d.jsail.HAnim.HAnimJoint.validate(HAnimJoint.java:7476) >> >> > at >> org.web3d.x3d.jsail.HAnim.HAnimJoint.validate(HAnimJoint.java:7476) >> >> > at >> org.web3d.x3d.jsail.HAnim.HAnimHumanoid.validate(HAnimHumanoid.java:6317) >> >> > at >> org.web3d.x3d.jsail.Grouping.Transform.validate(Transform.java:2556) >> >> > at org.web3d.x3d.jsail.Core.Scene.validate(Scene.java:869) >> >> > at org.web3d.x3d.jsail.Core.X3D.validate(X3D.java:4549) >> >> > at org.web3d.x3d.jsail.CommandLine.run(CommandLine.java:1098) >> >> > at org.web3d.x3d.jsail.CommandLine.main(CommandLine.java:242) >> >> > >> >> > I don't have a recent version of X3DJSAIL >> >> > >> >> > On Tue, Feb 4, 2025 at 2:22?PM Andreas Plesch < >> andreasplesch at gmail.com> wrote: >> >> >> >> >> >> Thanks, exactly what I was looking for. >> >> >> >> >> >> Best, Andreas >> >> >> >> >> >> >> >> >> On Tue, Feb 4, 2025, 2:01?PM Holger Seelig >> wrote: >> >> >>> >> >> >>> The default value for a field is either specified for each node >> type or the default value for Script or ComposedShader node custom fields >> is defined in >> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/fieldTypes.html. >> Mostly false, 0, ??, identity, ... >> >> >>> >> >> >>> A proto instance will inherit its default values from the proto >> declaration its fields. Fields such as outputOnly will normally have a >> default value from fieldTypes.html. >> >> >>> >> >> >>> There is an exception with X3DInterpolatorNode.value_changed: >> >> >>> >> >> >>> >> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/interpolators.html#X3DInterpolatorNode >> >> >>> >> >> >>> If an X3DInterpolatorNode value_changed outputOnly field is read >> before it receives any inputs, keyValue[0] is returned if keyValue is not >> empty... >> >> >>> >> >> >>> Best regards, >> >> >>> Holger >> >> >>> >> >> >>> -- >> >> >>> Holger Seelig >> >> >>> Leipzig, Germany >> >> >>> >> >> >>> holger.seelig at yahoo.de >> >> >>> https://create3000.github.io/x_ite/ >> >> >>> >> >> >>> Am 04.02.2025 um 19:26 schrieb Andreas Plesch via x3d-public < >> x3d-public at web3d.org>: >> >> >>> >> >> >>> Hi John, all, >> >> >>> >> >> >>> It turns out that x3dom currently expects a default value for >> Proto fields even for outputOnly fields. This is due to how Proto fields >> are initialized. They always need to have a value. While the spec. does not >> require this, it seems still good practice to always define a default value >> in the ProtoInterface. There may be a case where an outputOnly field is >> used in ISing where a valid value would be expected. There may be other >> corner cases. >> >> >>> >> >> >>> Here is your example with added default values for outputOnly >> fields: >> >> >>> >> >> >>> >> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/af5ff3148c1159f71d34fb78c1f63024/raw/b3d4470107ab74e301ed48448ab2a4f4154672e0/ManyClocks_John.x3d >> >> >>> >> >> >>> This could be fixed in x3dom, by always setting some default >> value. Is there a list of recommended defaults for each data type if no >> other source of defaults is available? For SFTime it seems to be -1. >> >> >>> >> >> >>> -Andreas >> >> >>> >> >> >>> >> >> >>> On Mon, Feb 3, 2025 at 7:39?AM Andreas Plesch < >> andreasplesch at gmail.com> wrote: >> >> >>>> >> >> >>>> Hi John, >> >> >>>> >> >> >>>> On Mon, Feb 3, 2025 at 12:48?AM John Carlson >> wrote: >> >> >>>>> >> >> >>>>> Andreas, "startTime" is an accessType outputOnly field, so why >> do I need to provide a value attribute in fieldValue? I'm kind of >> confused. I'm probably missing something in the spec. >> >> >>>> >> >> >>>> >> >> >>>> You are right, I only outlined scenarios where the accessType >> allows input or initialization.. >> >> >>>> In the outputOnly case it is not necessary to provide a >> fieldValue node at all since there is no value which can be provided. >> Providing the node would indeed be confusing, to both the user code reader >> and any X3D browser. >> >> >>>> I believe the spec. is silent on this case in any encoding. >> >> >>>> >> >> >>>> Best, Andreas >> >> >>>> >> >> >>>>> Thanks for any clarification. >> >> >>>>> >> >> >>>>> I have finally enabled schematron on the project, but I'm >> finding it hard to understand the messages, and modifications that I make, >> while removing the immediate problems, seem to move the problems elsewhere. >> >> >>>>> >> >> >>>>> Explaining why I need a "startTime" fieldValue value is my main >> lack of understanding, but perhaps I need a whole review of accessType. >> >> >>>>> >> >> >>>>> Castle Model Converter reports: >> >> >>>>> >> >> >>>>> castle-model-converter: Warning: X3D: X3D XML: >> element references unknown field name "enabled" >> >> >>>>> castle-model-converter: Warning: X3D: X3D XML: >> element references unknown field name "startTime" >> >> >>>>> castle-model-converter: Warning: X3D: X3D XML: >> element references unknown field name "stopTime" >> >> >>>>> >> >> >>>>> I will try providing a field value in the ProtoInterface >> >> >>>>> >> >> >>>>> If I "cleanup" enabled, startTime and stopTime, I get: >> >> >>>>> >> >> >>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >> "MenuItem", event "inputTrue" references (by "IS" clause) non-existing >> event "enabled" >> >> >>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >> "MenuItem", event "triggerTime" references (by "IS" clause) non-existing >> event "startTime" >> >> >>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >> "MenuItem", event "triggerTime" references (by "IS" clause) non-existing >> event "stopTime" >> >> >>>>> >> >> >>>>> I guess what I conclude at this point is, startTime and stopTime >> are bad DEF names, but what about enabled as a field? The dominoes are >> falling. >> >> >>>>> >> >> >>>>> About your two scenarios in the other message, perhaps this is >> revealing. >> >> >>>>> >> >> >>>>> See attached attempt to fix original issue, which resulted in >> the above. >> >> >>>>> >> >> >>>>> John >> >> >>>>> >> >> >>>>> On Sun, Feb 2, 2025 at 3:59?PM Andreas Plesch < >> andreasplesch at gmail.com> wrote: >> >> >>>>>> >> >> >>>>>> I think x3dom, reasonably, expects a value for the fieldValue >> nodes: >> >> >>>>>> >> >> >>>>>> For example: >> >> >>>>>> >> >> >>>>>> >> >> >>>>>> >> >> >>>>>> and others. >> >> >>>>>> >> >> >>>>>> On Sun, Feb 2, 2025 at 5:42?AM John Carlson >> wrote: >> >> >>>>>>> >> >> >>>>>>> Andreas, Joe, >> >> >>>>>>> >> >> >>>>>>> Reset Button, Reset_Clock added. >> >> >>>>>>> >> >> >>>>>>> See attached zip for details, or visit link; >> >> >>>>>>> >> >> >>>>>>> >> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >> >> >>>>>>> >> >> >>>>>>> For some reason, this link doesn't show the live scene? >> >> >>>>>>> >> >> >>>>>>> >> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >> >> >>>>>>> >> >> >>>>>>> Puzzled, haven't researched it yet. Looks good in Sunrize and >> X_ITE, will try FreeWRL next. >> >> >>>>>>> >> >> >>>>>>> John >> >> >>>>>> >> >> >>>>>> >> >> >>>>>> >> >> >>>>>> -- >> >> >>>>>> Andreas Plesch >> >> >>>>>> Waltham, MA 02453 >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> -- >> >> >>>> Andreas Plesch >> >> >>>> Waltham, MA 02453 >> >> >>> >> >> >>> >> >> >>> >> >> >>> -- >> >> >>> Andreas Plesch >> >> >>> Waltham, MA 02453 >> >> >>> _______________________________________________ >> >> >>> x3d-public mailing list >> >> >>> x3d-public at web3d.org >> >> >>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >> >> >>> >> >> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreasplesch at gmail.com Wed Feb 5 10:00:30 2025 From: andreasplesch at gmail.com (Andreas Plesch) Date: Wed, 5 Feb 2025 13:00:30 -0500 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: Message-ID: Hi John, The reason is that Displacers are currently implemented in x3dom only for Joints, but not for Segments, unfortunately. Do you know of a simple but instructive test case of Segments with Displacers ? Andreas On Tue, Feb 4, 2025, 2:33?PM John Carlson wrote: > I will try to test this in castle model converter. > > I did try setting a value for the outputOnly fields, but the converter > wouldn?t shut up. > > The model below doesn?t seem to animate when one presses the menu items. > Did you get it to animate? > > On Tue, Feb 4, 2025 at 12:27?PM Andreas Plesch > wrote: > >> Hi John, all, >> >> It turns out that x3dom currently expects a default value for Proto >> fields even for outputOnly fields. This is due to how Proto fields are >> initialized. They always need to have a value. While the spec. does not >> require this, it seems still good practice to always define a default value >> in the ProtoInterface. There may be a case where an outputOnly field is >> used in ISing where a valid value would be expected. There may be other >> corner cases. >> >> Here is your example with added default values for outputOnly fields: >> >> >> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/af5ff3148c1159f71d34fb78c1f63024/raw/b3d4470107ab74e301ed48448ab2a4f4154672e0/ManyClocks_John.x3d >> >> This could be fixed in x3dom, by always setting some default value. Is >> there a list of recommended defaults for each data type if no other source >> of defaults is available? For SFTime it seems to be -1. >> >> >> -Andreas >> >> >> On Mon, Feb 3, 2025 at 7:39?AM Andreas Plesch >> wrote: >> >>> Hi John, >>> >>> On Mon, Feb 3, 2025 at 12:48?AM John Carlson wrote: >>> >>>> Andreas, "startTime" is an accessType outputOnly field, so why do I >>>> need to provide a value attribute in fieldValue? I'm kind of confused. >>>> I'm probably missing something in the spec. >>>> >>> >>> You are right, I only outlined scenarios where the accessType allows >>> input or initialization.. >>> In the outputOnly case it is not necessary to provide a fieldValue node >>> at all since there is no value which can be provided. Providing the node >>> would indeed be confusing, to both the user code reader and any X3D browser. >>> I believe the spec. is silent on this case in any encoding. >>> >>> Best, Andreas >>> >>> Thanks for any clarification. >>>> >>>> I have finally enabled schematron on the project, but I'm finding it >>>> hard to understand the messages, and modifications that I make, while >>>> removing the immediate problems, seem to move the problems elsewhere. >>>> >>>> Explaining why I need a "startTime" fieldValue value is my main lack of >>>> understanding, but perhaps I need a whole review of accessType. >>>> >>>> Castle Model Converter reports: >>>> >>>> castle-model-converter: Warning: X3D: X3D XML: element >>>> references unknown field name "enabled" >>>> castle-model-converter: Warning: X3D: X3D XML: element >>>> references unknown field name "startTime" >>>> castle-model-converter: Warning: X3D: X3D XML: element >>>> references unknown field name "stopTime" >>>> >>>> I will try providing a field value in the ProtoInterface >>>> >>>> If I "cleanup" enabled, startTime and stopTime, I get: >>>> >>>> castle-model-converter: Warning: VRML/X3D: Within prototype "MenuItem", >>>> event "inputTrue" references (by "IS" clause) non-existing event "enabled" >>>> castle-model-converter: Warning: VRML/X3D: Within prototype "MenuItem", >>>> event "triggerTime" references (by "IS" clause) non-existing event >>>> "startTime" >>>> castle-model-converter: Warning: VRML/X3D: Within prototype "MenuItem", >>>> event "triggerTime" references (by "IS" clause) non-existing event >>>> "stopTime" >>>> >>>> I guess what I conclude at this point is, startTime and stopTime are >>>> bad DEF names, but what about enabled as a field? The dominoes are falling. >>>> >>>> About your two scenarios in the other message, perhaps this is >>>> revealing. >>>> >>>> See attached attempt to fix original issue, which resulted in the above. >>>> >>>> John >>>> >>>> On Sun, Feb 2, 2025 at 3:59?PM Andreas Plesch >>>> wrote: >>>> >>>>> I think x3dom, reasonably, expects a value for the fieldValue nodes: >>>>> >>>>> For example: >>>>> >>>>> >>>>> >>>>> and others. >>>>> >>>>> On Sun, Feb 2, 2025 at 5:42?AM John Carlson >>>>> wrote: >>>>> >>>>>> Andreas, Joe, >>>>>> >>>>>> Reset Button, Reset_Clock added. >>>>>> >>>>>> See attached zip for details, or visit link; >>>>>> >>>>>> >>>>>> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>> >>>>>> For some reason, this link doesn't show the live scene? >>>>>> >>>>>> >>>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>> >>>>>> Puzzled, haven't researched it yet. Looks good in Sunrize and X_ITE, >>>>>> will try FreeWRL next. >>>>>> >>>>>> John >>>>>> >>>>>>> >>>>> >>>>> -- >>>>> Andreas Plesch >>>>> Waltham, MA 02453 >>>>> >>>> >>> >>> -- >>> Andreas Plesch >>> Waltham, MA 02453 >>> >> >> >> -- >> Andreas Plesch >> Waltham, MA 02453 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Wed Feb 5 10:31:23 2025 From: yottzumm at gmail.com (John Carlson) Date: Wed, 5 Feb 2025 12:31:23 -0600 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: Message-ID: I had one I sent to Holger, probably derived from this one: https://github.com/coderextreme/ci2had/blob/main/resources/JinMouthStretch.x3d What I would do (again) is take out all the segments but the tongue. There?s no menus involved in this one. If you need further assistance, like a smaller example, I can help. Also all the Jin*.x3d FACS action units can also provide examples. I?ll be pretty unbusy today. I can allocate some time for creating a model, make sure it animates, etc. If you?re able to allocate some time today, great, we have an HAnim meeting tomorrow and showing off X3DOM editor using Displacers would be fantastic! Remember there?s a coord field in HAnimSegment that the HAnimDisplacer operates on! John On Wed, Feb 5, 2025 at 12:01?PM Andreas Plesch wrote: > Hi John, > > The reason is that Displacers are currently implemented in x3dom only for > Joints, but not for Segments, unfortunately. Do you know of a simple but > instructive test case of Segments with Displacers ? > > Andreas > > > On Tue, Feb 4, 2025, 2:33?PM John Carlson wrote: > >> I will try to test this in castle model converter. >> >> I did try setting a value for the outputOnly fields, but the converter >> wouldn?t shut up. >> >> The model below doesn?t seem to animate when one presses the menu items. >> Did you get it to animate? >> >> On Tue, Feb 4, 2025 at 12:27?PM Andreas Plesch >> wrote: >> >>> Hi John, all, >>> >>> It turns out that x3dom currently expects a default value for Proto >>> fields even for outputOnly fields. This is due to how Proto fields are >>> initialized. They always need to have a value. While the spec. does not >>> require this, it seems still good practice to always define a default value >>> in the ProtoInterface. There may be a case where an outputOnly field is >>> used in ISing where a valid value would be expected. There may be other >>> corner cases. >>> >>> Here is your example with added default values for outputOnly fields: >>> >>> >>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/af5ff3148c1159f71d34fb78c1f63024/raw/b3d4470107ab74e301ed48448ab2a4f4154672e0/ManyClocks_John.x3d >>> >>> This could be fixed in x3dom, by always setting some default value. Is >>> there a list of recommended defaults for each data type if no other source >>> of defaults is available? For SFTime it seems to be -1. >>> >>> >>> -Andreas >>> >>> >>> On Mon, Feb 3, 2025 at 7:39?AM Andreas Plesch >>> wrote: >>> >>>> Hi John, >>>> >>>> On Mon, Feb 3, 2025 at 12:48?AM John Carlson >>>> wrote: >>>> >>>>> Andreas, "startTime" is an accessType outputOnly field, so why do I >>>>> need to provide a value attribute in fieldValue? I'm kind of confused. >>>>> I'm probably missing something in the spec. >>>>> >>>> >>>> You are right, I only outlined scenarios where the accessType allows >>>> input or initialization.. >>>> In the outputOnly case it is not necessary to provide a fieldValue node >>>> at all since there is no value which can be provided. Providing the node >>>> would indeed be confusing, to both the user code reader and any X3D browser. >>>> I believe the spec. is silent on this case in any encoding. >>>> >>>> Best, Andreas >>>> >>>> Thanks for any clarification. >>>>> >>>>> I have finally enabled schematron on the project, but I'm finding it >>>>> hard to understand the messages, and modifications that I make, while >>>>> removing the immediate problems, seem to move the problems elsewhere. >>>>> >>>>> Explaining why I need a "startTime" fieldValue value is my main lack >>>>> of understanding, but perhaps I need a whole review of accessType. >>>>> >>>>> Castle Model Converter reports: >>>>> >>>>> castle-model-converter: Warning: X3D: X3D XML: element >>>>> references unknown field name "enabled" >>>>> castle-model-converter: Warning: X3D: X3D XML: element >>>>> references unknown field name "startTime" >>>>> castle-model-converter: Warning: X3D: X3D XML: element >>>>> references unknown field name "stopTime" >>>>> >>>>> I will try providing a field value in the ProtoInterface >>>>> >>>>> If I "cleanup" enabled, startTime and stopTime, I get: >>>>> >>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>> "MenuItem", event "inputTrue" references (by "IS" clause) non-existing >>>>> event "enabled" >>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>> "MenuItem", event "triggerTime" references (by "IS" clause) non-existing >>>>> event "startTime" >>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>> "MenuItem", event "triggerTime" references (by "IS" clause) non-existing >>>>> event "stopTime" >>>>> >>>>> I guess what I conclude at this point is, startTime and stopTime are >>>>> bad DEF names, but what about enabled as a field? The dominoes are falling. >>>>> >>>>> About your two scenarios in the other message, perhaps this is >>>>> revealing. >>>>> >>>>> See attached attempt to fix original issue, which resulted in the >>>>> above. >>>>> >>>>> John >>>>> >>>>> On Sun, Feb 2, 2025 at 3:59?PM Andreas Plesch >>>>> wrote: >>>>> >>>>>> I think x3dom, reasonably, expects a value for the fieldValue nodes: >>>>>> >>>>>> For example: >>>>>> >>>>>> >>>>>> >>>>>> and others. >>>>>> >>>>>> On Sun, Feb 2, 2025 at 5:42?AM John Carlson >>>>>> wrote: >>>>>> >>>>>>> Andreas, Joe, >>>>>>> >>>>>>> Reset Button, Reset_Clock added. >>>>>>> >>>>>>> See attached zip for details, or visit link; >>>>>>> >>>>>>> >>>>>>> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>>> >>>>>>> For some reason, this link doesn't show the live scene? >>>>>>> >>>>>>> >>>>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>>> >>>>>>> Puzzled, haven't researched it yet. Looks good in Sunrize and >>>>>>> X_ITE, will try FreeWRL next. >>>>>>> >>>>>>> John >>>>>>> >>>>>>>> >>>>>> >>>>>> -- >>>>>> Andreas Plesch >>>>>> Waltham, MA 02453 >>>>>> >>>>> >>>> >>>> -- >>>> Andreas Plesch >>>> Waltham, MA 02453 >>>> >>> >>> >>> -- >>> Andreas Plesch >>> Waltham, MA 02453 >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Wed Feb 5 10:41:02 2025 From: yottzumm at gmail.com (John Carlson) Date: Wed, 5 Feb 2025 12:41:02 -0600 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: Message-ID: Here's a small example, Tongue.x3d. Your efforts are appreciated! John On Wed, Feb 5, 2025 at 12:01?PM Andreas Plesch wrote: > Hi John, > > The reason is that Displacers are currently implemented in x3dom only for > Joints, but not for Segments, unfortunately. Do you know of a simple but > instructive test case of Segments with Displacers ? > > Andreas > > > On Tue, Feb 4, 2025, 2:33?PM John Carlson wrote: > >> I will try to test this in castle model converter. >> >> I did try setting a value for the outputOnly fields, but the converter >> wouldn?t shut up. >> >> The model below doesn?t seem to animate when one presses the menu items. >> Did you get it to animate? >> >> On Tue, Feb 4, 2025 at 12:27?PM Andreas Plesch >> wrote: >> >>> Hi John, all, >>> >>> It turns out that x3dom currently expects a default value for Proto >>> fields even for outputOnly fields. This is due to how Proto fields are >>> initialized. They always need to have a value. While the spec. does not >>> require this, it seems still good practice to always define a default value >>> in the ProtoInterface. There may be a case where an outputOnly field is >>> used in ISing where a valid value would be expected. There may be other >>> corner cases. >>> >>> Here is your example with added default values for outputOnly fields: >>> >>> >>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/af5ff3148c1159f71d34fb78c1f63024/raw/b3d4470107ab74e301ed48448ab2a4f4154672e0/ManyClocks_John.x3d >>> >>> This could be fixed in x3dom, by always setting some default value. Is >>> there a list of recommended defaults for each data type if no other source >>> of defaults is available? For SFTime it seems to be -1. >>> >>> >>> -Andreas >>> >>> >>> On Mon, Feb 3, 2025 at 7:39?AM Andreas Plesch >>> wrote: >>> >>>> Hi John, >>>> >>>> On Mon, Feb 3, 2025 at 12:48?AM John Carlson >>>> wrote: >>>> >>>>> Andreas, "startTime" is an accessType outputOnly field, so why do I >>>>> need to provide a value attribute in fieldValue? I'm kind of confused. >>>>> I'm probably missing something in the spec. >>>>> >>>> >>>> You are right, I only outlined scenarios where the accessType allows >>>> input or initialization.. >>>> In the outputOnly case it is not necessary to provide a fieldValue node >>>> at all since there is no value which can be provided. Providing the node >>>> would indeed be confusing, to both the user code reader and any X3D browser. >>>> I believe the spec. is silent on this case in any encoding. >>>> >>>> Best, Andreas >>>> >>>> Thanks for any clarification. >>>>> >>>>> I have finally enabled schematron on the project, but I'm finding it >>>>> hard to understand the messages, and modifications that I make, while >>>>> removing the immediate problems, seem to move the problems elsewhere. >>>>> >>>>> Explaining why I need a "startTime" fieldValue value is my main lack >>>>> of understanding, but perhaps I need a whole review of accessType. >>>>> >>>>> Castle Model Converter reports: >>>>> >>>>> castle-model-converter: Warning: X3D: X3D XML: element >>>>> references unknown field name "enabled" >>>>> castle-model-converter: Warning: X3D: X3D XML: element >>>>> references unknown field name "startTime" >>>>> castle-model-converter: Warning: X3D: X3D XML: element >>>>> references unknown field name "stopTime" >>>>> >>>>> I will try providing a field value in the ProtoInterface >>>>> >>>>> If I "cleanup" enabled, startTime and stopTime, I get: >>>>> >>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>> "MenuItem", event "inputTrue" references (by "IS" clause) non-existing >>>>> event "enabled" >>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>> "MenuItem", event "triggerTime" references (by "IS" clause) non-existing >>>>> event "startTime" >>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>> "MenuItem", event "triggerTime" references (by "IS" clause) non-existing >>>>> event "stopTime" >>>>> >>>>> I guess what I conclude at this point is, startTime and stopTime are >>>>> bad DEF names, but what about enabled as a field? The dominoes are falling. >>>>> >>>>> About your two scenarios in the other message, perhaps this is >>>>> revealing. >>>>> >>>>> See attached attempt to fix original issue, which resulted in the >>>>> above. >>>>> >>>>> John >>>>> >>>>> On Sun, Feb 2, 2025 at 3:59?PM Andreas Plesch >>>>> wrote: >>>>> >>>>>> I think x3dom, reasonably, expects a value for the fieldValue nodes: >>>>>> >>>>>> For example: >>>>>> >>>>>> >>>>>> >>>>>> and others. >>>>>> >>>>>> On Sun, Feb 2, 2025 at 5:42?AM John Carlson >>>>>> wrote: >>>>>> >>>>>>> Andreas, Joe, >>>>>>> >>>>>>> Reset Button, Reset_Clock added. >>>>>>> >>>>>>> See attached zip for details, or visit link; >>>>>>> >>>>>>> >>>>>>> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>>> >>>>>>> For some reason, this link doesn't show the live scene? >>>>>>> >>>>>>> >>>>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>>> >>>>>>> Puzzled, haven't researched it yet. Looks good in Sunrize and >>>>>>> X_ITE, will try FreeWRL next. >>>>>>> >>>>>>> John >>>>>>> >>>>>>>> >>>>>> >>>>>> -- >>>>>> Andreas Plesch >>>>>> Waltham, MA 02453 >>>>>> >>>>> >>>> >>>> -- >>>> Andreas Plesch >>>> Waltham, MA 02453 >>>> >>> >>> >>> -- >>> Andreas Plesch >>> Waltham, MA 02453 >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Tongue.x3d Type: model/x3d+xml Size: 16252 bytes Desc: not available URL: From yottzumm at gmail.com Wed Feb 5 11:07:29 2025 From: yottzumm at gmail.com (John Carlson) Date: Wed, 5 Feb 2025 13:07:29 -0600 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: Message-ID: Here?s the associated image: https://github.com/coderextreme/ci2had/blob/main/resources/JinImageAtlas.jpg It?s in the FacialAnimation archives under HumanoidAnimation if you want to pick it up from there. Perhaps a simple diffuseColor would work too. John On Wed, Feb 5, 2025 at 12:41?PM John Carlson wrote: > Here's a small example, Tongue.x3d. > > Your efforts are appreciated! > > > John > > On Wed, Feb 5, 2025 at 12:01?PM Andreas Plesch > wrote: > >> Hi John, >> >> The reason is that Displacers are currently implemented in x3dom only for >> Joints, but not for Segments, unfortunately. Do you know of a simple but >> instructive test case of Segments with Displacers ? >> >> Andreas >> >> >> On Tue, Feb 4, 2025, 2:33?PM John Carlson wrote: >> >>> I will try to test this in castle model converter. >>> >>> I did try setting a value for the outputOnly fields, but the converter >>> wouldn?t shut up. >>> >>> The model below doesn?t seem to animate when one presses the menu >>> items. Did you get it to animate? >>> >>> On Tue, Feb 4, 2025 at 12:27?PM Andreas Plesch >>> wrote: >>> >>>> Hi John, all, >>>> >>>> It turns out that x3dom currently expects a default value for Proto >>>> fields even for outputOnly fields. This is due to how Proto fields are >>>> initialized. They always need to have a value. While the spec. does not >>>> require this, it seems still good practice to always define a default value >>>> in the ProtoInterface. There may be a case where an outputOnly field is >>>> used in ISing where a valid value would be expected. There may be other >>>> corner cases. >>>> >>>> Here is your example with added default values for outputOnly fields: >>>> >>>> >>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/af5ff3148c1159f71d34fb78c1f63024/raw/b3d4470107ab74e301ed48448ab2a4f4154672e0/ManyClocks_John.x3d >>>> >>>> This could be fixed in x3dom, by always setting some default value. Is >>>> there a list of recommended defaults for each data type if no other source >>>> of defaults is available? For SFTime it seems to be -1. >>>> >>>> >>>> -Andreas >>>> >>>> >>>> On Mon, Feb 3, 2025 at 7:39?AM Andreas Plesch >>>> wrote: >>>> >>>>> Hi John, >>>>> >>>>> On Mon, Feb 3, 2025 at 12:48?AM John Carlson >>>>> wrote: >>>>> >>>>>> Andreas, "startTime" is an accessType outputOnly field, so why do I >>>>>> need to provide a value attribute in fieldValue? I'm kind of confused. >>>>>> I'm probably missing something in the spec. >>>>>> >>>>> >>>>> You are right, I only outlined scenarios where the accessType allows >>>>> input or initialization.. >>>>> In the outputOnly case it is not necessary to provide a fieldValue >>>>> node at all since there is no value which can be provided. Providing the >>>>> node would indeed be confusing, to both the user code reader and any X3D >>>>> browser. >>>>> I believe the spec. is silent on this case in any encoding. >>>>> >>>>> Best, Andreas >>>>> >>>>> Thanks for any clarification. >>>>>> >>>>>> I have finally enabled schematron on the project, but I'm finding it >>>>>> hard to understand the messages, and modifications that I make, while >>>>>> removing the immediate problems, seem to move the problems elsewhere. >>>>>> >>>>>> Explaining why I need a "startTime" fieldValue value is my main lack >>>>>> of understanding, but perhaps I need a whole review of accessType. >>>>>> >>>>>> Castle Model Converter reports: >>>>>> >>>>>> castle-model-converter: Warning: X3D: X3D XML: element >>>>>> references unknown field name "enabled" >>>>>> castle-model-converter: Warning: X3D: X3D XML: element >>>>>> references unknown field name "startTime" >>>>>> castle-model-converter: Warning: X3D: X3D XML: element >>>>>> references unknown field name "stopTime" >>>>>> >>>>>> I will try providing a field value in the ProtoInterface >>>>>> >>>>>> If I "cleanup" enabled, startTime and stopTime, I get: >>>>>> >>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>> "MenuItem", event "inputTrue" references (by "IS" clause) non-existing >>>>>> event "enabled" >>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) non-existing >>>>>> event "startTime" >>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) non-existing >>>>>> event "stopTime" >>>>>> >>>>>> I guess what I conclude at this point is, startTime and stopTime are >>>>>> bad DEF names, but what about enabled as a field? The dominoes are falling. >>>>>> >>>>>> About your two scenarios in the other message, perhaps this is >>>>>> revealing. >>>>>> >>>>>> See attached attempt to fix original issue, which resulted in the >>>>>> above. >>>>>> >>>>>> John >>>>>> >>>>>> On Sun, Feb 2, 2025 at 3:59?PM Andreas Plesch < >>>>>> andreasplesch at gmail.com> wrote: >>>>>> >>>>>>> I think x3dom, reasonably, expects a value for the fieldValue nodes: >>>>>>> >>>>>>> For example: >>>>>>> >>>>>>> >>>>>>> >>>>>>> and others. >>>>>>> >>>>>>> On Sun, Feb 2, 2025 at 5:42?AM John Carlson >>>>>>> wrote: >>>>>>> >>>>>>>> Andreas, Joe, >>>>>>>> >>>>>>>> Reset Button, Reset_Clock added. >>>>>>>> >>>>>>>> See attached zip for details, or visit link; >>>>>>>> >>>>>>>> >>>>>>>> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>>>> >>>>>>>> For some reason, this link doesn't show the live scene? >>>>>>>> >>>>>>>> >>>>>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>>>> >>>>>>>> Puzzled, haven't researched it yet. Looks good in Sunrize and >>>>>>>> X_ITE, will try FreeWRL next. >>>>>>>> >>>>>>>> John >>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Andreas Plesch >>>>>>> Waltham, MA 02453 >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> Andreas Plesch >>>>> Waltham, MA 02453 >>>>> >>>> >>>> >>>> -- >>>> Andreas Plesch >>>> Waltham, MA 02453 >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron.bergstrom at und.edu Wed Feb 5 11:39:48 2025 From: aaron.bergstrom at und.edu (Bergstrom, Aaron) Date: Wed, 5 Feb 2025 19:39:48 +0000 Subject: [x3d-public] RawKee Python update - Export with PBR Textures for Export Testing Message-ID: All, I just thought I send out an update on the RawKee Python X3D exporter for Maya. No pictures or code examples this time though. Last night I wrote a good chunk of the code necessary for exporting PBR textures/materials from Maya to X3D using the PhysicalMaterial node. I expect that RawKee export will support the following Maya material types: As X3D "Material" nodes: - phong, phongE, blinn, and lambert - (Maya basic material) As X3D "PhysicalMaterial" nodes: - standardSurface (Maya basic material with support for PBR textures generated by Adobe Substance 3D Painter) - aiStandardSurface (Maya Arnold renderer material with support for PBR textures generated by Adobe Substance 3D Painter) - usdPreviewSurface (Maya USD plugin material with support for PBR textures) - StingrayPBS (Maya Shaderfx plugin material with support for PBR textures) These are material types that lend themselves well for export to the PhysicalMaterial node, and for which I have found PBR texturing tutorials online that are easily understood by Maya users. This will enable Maya users to incorporate these PBR texturing practices into their workflows, if they are not already doing so. This doesn't rule out support for additional Maya material types in the future, including custom Shaderfx GSLS shaders. But for now, I think that's a good starter pack for exporting high quality models/materials from Maya. I'm hoping that RawKee Python will start generating X3D Shape nodes that utilize IndexedFaceSet/PhysicalMaterial nodes sometime within the next two weeks. Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Wed Feb 5 11:44:10 2025 From: yottzumm at gmail.com (John Carlson) Date: Wed, 5 Feb 2025 13:44:10 -0600 Subject: [x3d-public] Retire X3DJSONLD website? Message-ID: I am thinking of retiring or modifying the X3DJSONLD website, since tools like X3DOM editor and X_ITE playground are available now. Here?s where the services are migrating: Converting X3D JSON Script nodes to HTML script: https://github.com/coderextreme/ScriptPreprocessor X3D JSON validator: Use npm?s x3dvalidate, like: npx x3dvalidate file.json XML to JSON to XML: Use Holger?s x3d-tidy npm package, or X_ITE playground. XML to STL: Use castle-model-converter. ???- What I plan to do is focus more on X3D JSON preview and translations to various programming languages, and between EXI, and .stl and ply. This will free up space occupied by XML previews and editors. I will also work on supporting JSON URIs supplied in the web address, moving away from copy/paste and file access. If someone wants additional X3DOM capabilities in X3DJSONLD, like converting X3D script to HTML script, speak up. John -------------- next part -------------- An HTML attachment was scrubbed... URL: From joedwil at earthlink.net Wed Feb 5 11:57:36 2025 From: joedwil at earthlink.net (Joe D Williams) Date: Wed, 05 Feb 2025 19:57:36 +0000 Subject: [x3d-public] displacers in Segment Turning on and off simultaneous animations individually Message-ID: <4720aa4e-6e8b-26f8-d0fa-665b23be7c88@earthlink.net> > The reason is that Displacers are currently implemented in x3dom only for Joints, but not for Segments, unfortunately. Please fix because we need to show this working everywhere, level 1 and Level 2. https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Segment So we have several shapes that produce this face and thus several Displacer nodes to control the various shapes to produce the motion and target pose. . Most all individual shapes of this face, except those associated with other Joints of the skull like eyes and jaw, are children of skullbase Joint. If all Displacer nodes and all the shapes that produce the face are placed under the skullbase Joint then there is no way to tell each Displacer which Shape to work on. So, since both Joint and Segment can contain Displacer nodes we just made up a Segment that holds the the geometry and placed the Displacer there. I think the general rule is for Level 1 is that a Displacer associated with geometry of a Segment is to be placed as first child of the Segment node. For Level 2, continuous mesh there may also be be several Displacer nodes operating at various times so those Displacer nodes are placed as first children of an appropriate Joint, or the first Joint. Since in this case that Level 1 hierarchy results in several shapes and displacers all under a single Joint, the skullbase, we decided to try adding a Segment to skullbase to hold each geometry and the associated Displacers for the various poses. This seemed to work that I think I saw somewhere, and, to me, if done consistenty, should work everywhere. Notice joekick works fine for Level 2 with displacers in Joint. Thanks for Fun with HAnim Displacer, Joe -----Original Message----- From: John Carlson Sent: Feb 5, 2025 10:31 AM To: Andreas Plesch , Holger Seelig , X3D Graphics public mailing list Cc: Joe D Williams Subject: Re: Turning on and off simultaneous animations individually I had one I sent to Holger, probably derived from this one: https://github.com/coderextreme/ci2had/blob/main/resources/JinMouthStretch.x3d What I would do (again) is take out all the segments but the tongue. There’s no menus involved in this one. If you need further assistance, like a smaller example, I can help. Also all the Jin*.x3d FACS action units can also provide examples. I’ll be pretty unbusy today. I can allocate some time for creating a model, make sure it animates, etc. If you’re able to allocate some time today, great, we have an HAnim meeting tomorrow and showing off X3DOM editor using Displacers would be fantastic! Remember there’s a coord field in HAnimSegment that the HAnimDisplacer operates on! John On Wed, Feb 5, 2025 at 12:01?PM Andreas Plesch wrote: Hi John, The reason is that Displacers are currently implemented in x3dom only for Joints, but not for Segments, unfortunately. Do you know of a simple but instructive test case of Segments with Displacers ? Andreas On Tue, Feb 4, 2025, 2:33?PM John Carlson wrote: I will try to test this in castle model converter. I did try setting a value for the outputOnly fields, but the converter wouldn’t shut up. The model below doesn’t seem to animate when one presses the menu items. Did you get it to animate? On Tue, Feb 4, 2025 at 12:27?PM Andreas Plesch wrote: Hi John, all, It turns out that x3dom currently expects a default value for Proto fields even for outputOnly fields. This is due to how Proto fields are initialized. They always need to have a value. While the spec. does not require this, it seems still good practice to always define a default value in the ProtoInterface. There may be a case where an outputOnly field is used in ISing where a valid value would be expected. There may be other corner cases. Here is your example with added default values for outputOnly fields: https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/af5ff3148c1159f71d34fb78c1f63024/raw/b3d4470107ab74e301ed48448ab2a4f4154672e0/ManyClocks_John.x3d This could be fixed in x3dom, by always setting some default value. Is there a list of recommended defaults for each data type if no other source of defaults is available? For SFTime it seems to be -1. -Andreas On Mon, Feb 3, 2025 at 7:39?AM Andreas Plesch wrote: Hi John, On Mon, Feb 3, 2025 at 12:48?AM John Carlson wrote: Andreas, "startTime" is an accessType outputOnly field, so why do I need to provide a value attribute in fieldValue? I'm kind of confused. I'm probably missing something in the spec. You are right, I only outlined scenarios where the accessType allows input or initialization.. In the outputOnly case it is not necessary to provide a fieldValue node at all since there is no value which can be provided. Providing the node would indeed be confusing, to both the user code reader and any X3D browser. I believe the spec. is silent on this case in any encoding. Best, Andreas Thanks for any clarification. I have finally enabled schematron on the project, but I'm finding it hard to understand the messages, and modifications that I make, while removing the immediate problems, seem to move the problems elsewhere. Explaining why I need a "startTime" fieldValue value is my main lack of understanding, but perhaps I need a whole review of accessType. Castle Model Converter reports: castle-model-converter: Warning: X3D: X3D XML: element references unknown field name "enabled" castle-model-converter: Warning: X3D: X3D XML: element references unknown field name "startTime" castle-model-converter: Warning: X3D: X3D XML: element references unknown field name "stopTime" I will try providing a field value in the ProtoInterface If I "cleanup" enabled, startTime and stopTime, I get: castle-model-converter: Warning: VRML/X3D: Within prototype "MenuItem", event "inputTrue" references (by "IS" clause) non-existing event "enabled" castle-model-converter: Warning: VRML/X3D: Within prototype "MenuItem", event "triggerTime" references (by "IS" clause) non-existing event "startTime" castle-model-converter: Warning: VRML/X3D: Within prototype "MenuItem", event "triggerTime" references (by "IS" clause) non-existing event "stopTime" I guess what I conclude at this point is, startTime and stopTime are bad DEF names, but what about enabled as a field? The dominoes are falling. About your two scenarios in the other message, perhaps this is revealing. See attached attempt to fix original issue, which resulted in the above. John On Sun, Feb 2, 2025 at 3:59?PM Andreas Plesch wrote: I think x3dom, reasonably, expects a value for the fieldValue nodes: For example: and others. On Sun, Feb 2, 2025 at 5:42?AM John Carlson wrote: Andreas, Joe, Reset Button, Reset_Clock added. See attached zip for details, or visit link; https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d For some reason, this link doesn't show the live scene? https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d Puzzled, haven't researched it yet. Looks good in Sunrize and X_ITE, will try FreeWRL next. John -- Andreas Plesch Waltham, MA 02453 -- Andreas Plesch Waltham, MA 02453 -- Andreas Plesch Waltham, MA 02453 -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Wed Feb 5 12:14:53 2025 From: yottzumm at gmail.com (John Carlson) Date: Wed, 5 Feb 2025 14:14:53 -0600 Subject: [x3d-public] displacers in Segment Turning on and off simultaneous animations individually In-Reply-To: <4720aa4e-6e8b-26f8-d0fa-665b23be7c88@earthlink.net> References: <4720aa4e-6e8b-26f8-d0fa-665b23be7c88@earthlink.net> Message-ID: What I?m hearing is HAnimDisplacer should be the first node under HAnimSegment. What I will do in cleanup.py is delete the HAnimDisplacer in HAnimSegment and insert it back at position 0 in the segment. John On Wed, Feb 5, 2025 at 1:57?PM Joe D Williams wrote: > > The reason is that Displacers are currently implemented in x3dom only > for Joints, but not for Segments, unfortunately. > > > > Please fix because we need to show this working everywhere, level 1 and > Level 2. > > > > > https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Segment > > > > So we have several shapes that produce this face and thus several > Displacer nodes > > to control the various shapes to produce the motion and target pose. > > . > > Most all individual shapes of this face, except those associated with > other > > Joints of the skull like eyes and jaw, are children of skullbase Joint. > > If all Displacer nodes and all the shapes that produce the face are placed > under the > > skullbase Joint then there is no way to tell each Displacer which Shape to > work on. > > So, since both Joint and Segment can contain Displacer nodes we just made > up a > > Segment that holds the the geometry and placed the Displacer there. > > > > I think the general rule is for Level 1 is that a Displacer associated > with geometry > > of a Segment is to be placed as first child of the Segment node. > > For Level 2, continuous mesh there may also be be several Displacer nodes > > operating at various times so those Displacer nodes are placed as first > children > > of an appropriate Joint, or the first Joint. > > > > Since in this case that Level 1 hierarchy results in several shapes and > displacers all under > > a single Joint, the skullbase, we decided to try adding a Segment to > skullbase to hold > > each geometry and the associated Displacers for the various poses. > > This seemed to work that I think I saw somewhere, and, to me, if done > consistenty, > > should work everywhere. > > Notice joekick works fine for Level 2 with displacers in Joint. > > > > Thanks for Fun with HAnim Displacer, > > Joe > > > > > > > > > > > > > > > > > > -----Original Message----- > From: John Carlson > Sent: Feb 5, 2025 10:31 AM > To: Andreas Plesch , Holger Seelig < > holger.seelig at yahoo.de>, X3D Graphics public mailing list < > x3d-public at web3d.org> > Cc: Joe D Williams > Subject: Re: Turning on and off simultaneous animations individually > > > I had one I sent to Holger, probably derived from this one: > > > https://github.com/coderextreme/ci2had/blob/main/resources/JinMouthStretch.x3d > > > What I would do (again) is take out all the segments but the tongue. > > There?s no menus involved in this one. > > If you need further assistance, like a smaller example, I can help. Also > all the Jin*.x3d FACS action units can also provide examples. > > I?ll be pretty unbusy today. I can allocate some time for creating a > model, make sure it animates, etc. > > If you?re able to allocate some time today, great, we have an HAnim > meeting tomorrow and showing off X3DOM editor using Displacers would be > fantastic! > > Remember there?s a coord field in HAnimSegment that the HAnimDisplacer > operates on! > > John > > On Wed, Feb 5, 2025 at 12:01?PM Andreas Plesch > wrote: > >> Hi John, >> >> The reason is that Displacers are currently implemented in x3dom only for >> Joints, but not for Segments, unfortunately. Do you know of a simple but >> instructive test case of Segments with Displacers ? >> >> >> Andreas >> >> >> On Tue, Feb 4, 2025, 2:33?PM John Carlson wrote: >> >>> I will try to test this in castle model converter. >>> >>> I did try setting a value for the outputOnly fields, but the converter >>> wouldn?t shut up. >>> >>> The model below doesn?t seem to animate when one presses the menu >>> items. Did you get it to animate? >>> >>> On Tue, Feb 4, 2025 at 12:27?PM Andreas Plesch >>> wrote: >>> >>>> Hi John, all, >>>> >>>> It turns out that x3dom currently expects a default value for Proto >>>> fields even for outputOnly fields. This is due to how Proto fields are >>>> initialized. They always need to have a value. While the spec. does not >>>> require this, it seems still good practice to always define a default value >>>> in the ProtoInterface. There may be a case where an outputOnly field is >>>> used in ISing where a valid value would be expected. There may be other >>>> corner cases. >>>> >>>> Here is your example with added default values for outputOnly fields: >>>> >>>> >>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/af5ff3148c1159f71d34fb78c1f63024/raw/b3d4470107ab74e301ed48448ab2a4f4154672e0/ManyClocks_John.x3d >>>> >>>> This could be fixed in x3dom, by always setting some default value. Is >>>> there a list of recommended defaults for each data type if no other source >>>> of defaults is available? For SFTime it seems to be -1. >>>> >>>> >>>> -Andreas >>>> >>>> >>>> On Mon, Feb 3, 2025 at 7:39?AM Andreas Plesch >>>> wrote: >>>> >>>>> Hi John, >>>>> >>>>> On Mon, Feb 3, 2025 at 12:48?AM John Carlson >>>>> wrote: >>>>> >>>>>> Andreas, "startTime" is an accessType outputOnly field, so why do I >>>>>> need to provide a value attribute in fieldValue? I'm kind of confused. >>>>>> I'm probably missing something in the spec. >>>>>> >>>>> >>>>> You are right, I only outlined scenarios where the accessType allows >>>>> input or initialization.. >>>>> In the outputOnly case it is not necessary to provide a fieldValue >>>>> node at all since there is no value which can be provided. Providing the >>>>> node would indeed be confusing, to both the user code reader and any X3D >>>>> browser. >>>>> I believe the spec. is silent on this case in any encoding. >>>>> >>>>> Best, Andreas >>>>> >>>>> >>>>>> Thanks for any clarification. >>>>>> >>>>>> I have finally enabled schematron on the project, but I'm finding it >>>>>> hard to understand the messages, and modifications that I make, while >>>>>> removing the immediate problems, seem to move the problems elsewhere. >>>>>> >>>>>> Explaining why I need a "startTime" fieldValue value is my main lack >>>>>> of understanding, but perhaps I need a whole review of accessType. >>>>>> >>>>>> Castle Model Converter reports: >>>>>> >>>>>> castle-model-converter: Warning: X3D: X3D XML: element >>>>>> references unknown field name "enabled" >>>>>> castle-model-converter: Warning: X3D: X3D XML: element >>>>>> references unknown field name "startTime" >>>>>> castle-model-converter: Warning: X3D: X3D XML: element >>>>>> references unknown field name "stopTime" >>>>>> >>>>>> I will try providing a field value in the ProtoInterface >>>>>> >>>>>> If I "cleanup" enabled, startTime and stopTime, I get: >>>>>> >>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>> "MenuItem", event "inputTrue" references (by "IS" clause) non-existing >>>>>> event "enabled" >>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) non-existing >>>>>> event "startTime" >>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) non-existing >>>>>> event "stopTime" >>>>>> >>>>>> I guess what I conclude at this point is, startTime and stopTime are >>>>>> bad DEF names, but what about enabled as a field? The dominoes are falling. >>>>>> >>>>>> About your two scenarios in the other message, perhaps this is >>>>>> revealing. >>>>>> >>>>>> See attached attempt to fix original issue, which resulted in the >>>>>> above. >>>>>> >>>>>> John >>>>>> >>>>>> On Sun, Feb 2, 2025 at 3:59?PM Andreas Plesch < >>>>>> andreasplesch at gmail.com> wrote: >>>>>> >>>>>>> I think x3dom, reasonably, expects a value for the fieldValue nodes: >>>>>>> >>>>>>> For example: >>>>>>> >>>>>>> >>>>>>> >>>>>>> and others. >>>>>>> >>>>>>> On Sun, Feb 2, 2025 at 5:42?AM John Carlson >>>>>>> wrote: >>>>>>> >>>>>>>> Andreas, Joe, >>>>>>>> >>>>>>>> Reset Button, Reset_Clock added. >>>>>>>> >>>>>>>> See attached zip for details, or visit link; >>>>>>>> >>>>>>>> >>>>>>>> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>>>> >>>>>>>> For some reason, this link doesn't show the live scene? >>>>>>>> >>>>>>>> >>>>>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>>>> >>>>>>>> Puzzled, haven't researched it yet. Looks good in Sunrize and >>>>>>>> X_ITE, will try FreeWRL next. >>>>>>>> >>>>>>>> John >>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Andreas Plesch >>>>>>> Waltham, MA 02453 >>>>>>> >>>>>> >>>>> >>>>> >>>> -- >>>>> Andreas Plesch >>>>> Waltham, MA 02453 >>>>> >>>> >>>> >>>> -- >>>> Andreas Plesch >>>> Waltham, MA 02453 >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Wed Feb 5 12:27:13 2025 From: yottzumm at gmail.com (John Carlson) Date: Wed, 5 Feb 2025 14:27:13 -0600 Subject: [x3d-public] displacers in Segment Turning on and off simultaneous animations individually In-Reply-To: References: <4720aa4e-6e8b-26f8-d0fa-665b23be7c88@earthlink.net> Message-ID: Here?s the current cleanup.py code: https://github.com/coderextreme/ci2had/blob/main/python/cleanup.py I should be able to put the displacer remove from parent outside the if, and then add an if for inserting the displacer at position 0 of the parent. I don?t see a specific quote in the spec that displacers should be put first in segment, but it?s an ok convention, especially if one is searching through user code. I will do what I can. John On Wed, Feb 5, 2025 at 2:14?PM John Carlson wrote: > What I?m hearing is HAnimDisplacer should be the first node under > HAnimSegment. > > What I will do in cleanup.py is delete the HAnimDisplacer in HAnimSegment > and insert it back at position 0 in the segment. > > John > On Wed, Feb 5, 2025 at 1:57?PM Joe D Williams > wrote: > >> > The reason is that Displacers are currently implemented in x3dom only >> for Joints, but not for Segments, unfortunately. >> >> >> >> Please fix because we need to show this working everywhere, level 1 and >> Level 2. >> >> >> >> >> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Segment >> >> >> >> So we have several shapes that produce this face and thus several >> Displacer nodes >> >> to control the various shapes to produce the motion and target pose. >> >> . >> >> Most all individual shapes of this face, except those associated with >> other >> >> Joints of the skull like eyes and jaw, are children of skullbase Joint. >> >> If all Displacer nodes and all the shapes that produce the face are >> placed under the >> >> skullbase Joint then there is no way to tell each Displacer which Shape >> to work on. >> >> So, since both Joint and Segment can contain Displacer nodes we just >> made up a >> >> Segment that holds the the geometry and placed the Displacer there. >> >> >> >> I think the general rule is for Level 1 is that a Displacer associated >> with geometry >> >> of a Segment is to be placed as first child of the Segment node. >> >> For Level 2, continuous mesh there may also be be several Displacer nodes >> >> operating at various times so those Displacer nodes are placed as first >> children >> >> of an appropriate Joint, or the first Joint. >> >> >> >> Since in this case that Level 1 hierarchy results in several shapes and >> displacers all under >> >> a single Joint, the skullbase, we decided to try adding a Segment to >> skullbase to hold >> >> each geometry and the associated Displacers for the various poses. >> >> This seemed to work that I think I saw somewhere, and, to me, if done >> consistenty, >> >> should work everywhere. >> >> Notice joekick works fine for Level 2 with displacers in Joint. >> >> >> >> Thanks for Fun with HAnim Displacer, >> >> Joe >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -----Original Message----- >> From: John Carlson >> Sent: Feb 5, 2025 10:31 AM >> To: Andreas Plesch , Holger Seelig < >> holger.seelig at yahoo.de>, X3D Graphics public mailing list < >> x3d-public at web3d.org> >> Cc: Joe D Williams >> Subject: Re: Turning on and off simultaneous animations individually >> >> >> I had one I sent to Holger, probably derived from this one: >> >> >> https://github.com/coderextreme/ci2had/blob/main/resources/JinMouthStretch.x3d >> >> >> What I would do (again) is take out all the segments but the tongue. >> >> There?s no menus involved in this one. >> >> If you need further assistance, like a smaller example, I can help. Also >> all the Jin*.x3d FACS action units can also provide examples. >> >> I?ll be pretty unbusy today. I can allocate some time for creating a >> model, make sure it animates, etc. >> >> If you?re able to allocate some time today, great, we have an HAnim >> meeting tomorrow and showing off X3DOM editor using Displacers would be >> fantastic! >> >> Remember there?s a coord field in HAnimSegment that the HAnimDisplacer >> operates on! >> >> John >> >> On Wed, Feb 5, 2025 at 12:01?PM Andreas Plesch >> wrote: >> >>> Hi John, >>> >>> The reason is that Displacers are currently implemented in x3dom only >>> for Joints, but not for Segments, unfortunately. Do you know of a simple >>> but instructive test case of Segments with Displacers ? >>> >>> >>> Andreas >>> >>> >>> On Tue, Feb 4, 2025, 2:33?PM John Carlson wrote: >>> >>>> I will try to test this in castle model converter. >>>> >>>> I did try setting a value for the outputOnly fields, but the converter >>>> wouldn?t shut up. >>>> >>>> The model below doesn?t seem to animate when one presses the menu >>>> items. Did you get it to animate? >>>> >>>> On Tue, Feb 4, 2025 at 12:27?PM Andreas Plesch >>>> wrote: >>>> >>>>> Hi John, all, >>>>> >>>>> It turns out that x3dom currently expects a default value for Proto >>>>> fields even for outputOnly fields. This is due to how Proto fields are >>>>> initialized. They always need to have a value. While the spec. does not >>>>> require this, it seems still good practice to always define a default value >>>>> in the ProtoInterface. There may be a case where an outputOnly field is >>>>> used in ISing where a valid value would be expected. There may be other >>>>> corner cases. >>>>> >>>>> Here is your example with added default values for outputOnly fields: >>>>> >>>>> >>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/af5ff3148c1159f71d34fb78c1f63024/raw/b3d4470107ab74e301ed48448ab2a4f4154672e0/ManyClocks_John.x3d >>>>> >>>>> This could be fixed in x3dom, by always setting some default value. Is >>>>> there a list of recommended defaults for each data type if no other source >>>>> of defaults is available? For SFTime it seems to be -1. >>>>> >>>>> >>>>> -Andreas >>>>> >>>>> >>>>> On Mon, Feb 3, 2025 at 7:39?AM Andreas Plesch >>>>> wrote: >>>>> >>>>>> Hi John, >>>>>> >>>>>> On Mon, Feb 3, 2025 at 12:48?AM John Carlson >>>>>> wrote: >>>>>> >>>>>>> Andreas, "startTime" is an accessType outputOnly field, so why do I >>>>>>> need to provide a value attribute in fieldValue? I'm kind of confused. >>>>>>> I'm probably missing something in the spec. >>>>>>> >>>>>> >>>>>> You are right, I only outlined scenarios where the accessType allows >>>>>> input or initialization.. >>>>>> In the outputOnly case it is not necessary to provide a fieldValue >>>>>> node at all since there is no value which can be provided. Providing the >>>>>> node would indeed be confusing, to both the user code reader and any X3D >>>>>> browser. >>>>>> I believe the spec. is silent on this case in any encoding. >>>>>> >>>>>> Best, Andreas >>>>>> >>>>>> >>>>>>> Thanks for any clarification. >>>>>>> >>>>>>> I have finally enabled schematron on the project, but I'm finding it >>>>>>> hard to understand the messages, and modifications that I make, while >>>>>>> removing the immediate problems, seem to move the problems elsewhere. >>>>>>> >>>>>>> Explaining why I need a "startTime" fieldValue value is my main lack >>>>>>> of understanding, but perhaps I need a whole review of accessType. >>>>>>> >>>>>>> Castle Model Converter reports: >>>>>>> >>>>>>> castle-model-converter: Warning: X3D: X3D XML: element >>>>>>> references unknown field name "enabled" >>>>>>> castle-model-converter: Warning: X3D: X3D XML: element >>>>>>> references unknown field name "startTime" >>>>>>> castle-model-converter: Warning: X3D: X3D XML: element >>>>>>> references unknown field name "stopTime" >>>>>>> >>>>>>> I will try providing a field value in the ProtoInterface >>>>>>> >>>>>>> If I "cleanup" enabled, startTime and stopTime, I get: >>>>>>> >>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>>> "MenuItem", event "inputTrue" references (by "IS" clause) non-existing >>>>>>> event "enabled" >>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) non-existing >>>>>>> event "startTime" >>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) non-existing >>>>>>> event "stopTime" >>>>>>> >>>>>>> I guess what I conclude at this point is, startTime and stopTime are >>>>>>> bad DEF names, but what about enabled as a field? The dominoes are falling. >>>>>>> >>>>>>> About your two scenarios in the other message, perhaps this is >>>>>>> revealing. >>>>>>> >>>>>>> See attached attempt to fix original issue, which resulted in the >>>>>>> above. >>>>>>> >>>>>>> John >>>>>>> >>>>>>> On Sun, Feb 2, 2025 at 3:59?PM Andreas Plesch < >>>>>>> andreasplesch at gmail.com> wrote: >>>>>>> >>>>>>>> I think x3dom, reasonably, expects a value for the fieldValue nodes: >>>>>>>> >>>>>>>> For example: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> and others. >>>>>>>> >>>>>>>> On Sun, Feb 2, 2025 at 5:42?AM John Carlson >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Andreas, Joe, >>>>>>>>> >>>>>>>>> Reset Button, Reset_Clock added. >>>>>>>>> >>>>>>>>> See attached zip for details, or visit link; >>>>>>>>> >>>>>>>>> >>>>>>>>> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>>>>> >>>>>>>>> For some reason, this link doesn't show the live scene? >>>>>>>>> >>>>>>>>> >>>>>>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>>>>> >>>>>>>>> Puzzled, haven't researched it yet. Looks good in Sunrize and >>>>>>>>> X_ITE, will try FreeWRL next. >>>>>>>>> >>>>>>>>> John >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Andreas Plesch >>>>>>>> Waltham, MA 02453 >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> -- >>>>>> Andreas Plesch >>>>>> Waltham, MA 02453 >>>>>> >>>>> >>>>> >>>>> -- >>>>> Andreas Plesch >>>>> Waltham, MA 02453 >>>>> >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreasplesch at gmail.com Wed Feb 5 13:11:58 2025 From: andreasplesch at gmail.com (Andreas Plesch) Date: Wed, 5 Feb 2025 16:11:58 -0500 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: Message-ID: Hi John, Thanks. I found the tongue.x3d example but if you can create another one that would be helpful in general. You vastly overestimate my ability and availability ;) This would be a longer term project. I have an idea what to do. Andreas On Wed, Feb 5, 2025, 1:31?PM John Carlson wrote: > I had one I sent to Holger, probably derived from this one: > > > https://github.com/coderextreme/ci2had/blob/main/resources/JinMouthStretch.x3d > > > What I would do (again) is take out all the segments but the tongue. > > There?s no menus involved in this one. > > If you need further assistance, like a smaller example, I can help. Also > all the Jin*.x3d FACS action units can also provide examples. > > I?ll be pretty unbusy today. I can allocate some time for creating a > model, make sure it animates, etc. > > If you?re able to allocate some time today, great, we have an HAnim > meeting tomorrow and showing off X3DOM editor using Displacers would be > fantastic! > > Remember there?s a coord field in HAnimSegment that the HAnimDisplacer > operates on! > > John > > On Wed, Feb 5, 2025 at 12:01?PM Andreas Plesch > wrote: > >> Hi John, >> >> The reason is that Displacers are currently implemented in x3dom only for >> Joints, but not for Segments, unfortunately. Do you know of a simple but >> instructive test case of Segments with Displacers ? >> >> Andreas >> >> >> On Tue, Feb 4, 2025, 2:33?PM John Carlson wrote: >> >>> I will try to test this in castle model converter. >>> >>> I did try setting a value for the outputOnly fields, but the converter >>> wouldn?t shut up. >>> >>> The model below doesn?t seem to animate when one presses the menu >>> items. Did you get it to animate? >>> >>> On Tue, Feb 4, 2025 at 12:27?PM Andreas Plesch >>> wrote: >>> >>>> Hi John, all, >>>> >>>> It turns out that x3dom currently expects a default value for Proto >>>> fields even for outputOnly fields. This is due to how Proto fields are >>>> initialized. They always need to have a value. While the spec. does not >>>> require this, it seems still good practice to always define a default value >>>> in the ProtoInterface. There may be a case where an outputOnly field is >>>> used in ISing where a valid value would be expected. There may be other >>>> corner cases. >>>> >>>> Here is your example with added default values for outputOnly fields: >>>> >>>> >>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/af5ff3148c1159f71d34fb78c1f63024/raw/b3d4470107ab74e301ed48448ab2a4f4154672e0/ManyClocks_John.x3d >>>> >>>> This could be fixed in x3dom, by always setting some default value. Is >>>> there a list of recommended defaults for each data type if no other source >>>> of defaults is available? For SFTime it seems to be -1. >>>> >>>> >>>> -Andreas >>>> >>>> >>>> On Mon, Feb 3, 2025 at 7:39?AM Andreas Plesch >>>> wrote: >>>> >>>>> Hi John, >>>>> >>>>> On Mon, Feb 3, 2025 at 12:48?AM John Carlson >>>>> wrote: >>>>> >>>>>> Andreas, "startTime" is an accessType outputOnly field, so why do I >>>>>> need to provide a value attribute in fieldValue? I'm kind of confused. >>>>>> I'm probably missing something in the spec. >>>>>> >>>>> >>>>> You are right, I only outlined scenarios where the accessType allows >>>>> input or initialization.. >>>>> In the outputOnly case it is not necessary to provide a fieldValue >>>>> node at all since there is no value which can be provided. Providing the >>>>> node would indeed be confusing, to both the user code reader and any X3D >>>>> browser. >>>>> I believe the spec. is silent on this case in any encoding. >>>>> >>>>> Best, Andreas >>>>> >>>>> Thanks for any clarification. >>>>>> >>>>>> I have finally enabled schematron on the project, but I'm finding it >>>>>> hard to understand the messages, and modifications that I make, while >>>>>> removing the immediate problems, seem to move the problems elsewhere. >>>>>> >>>>>> Explaining why I need a "startTime" fieldValue value is my main lack >>>>>> of understanding, but perhaps I need a whole review of accessType. >>>>>> >>>>>> Castle Model Converter reports: >>>>>> >>>>>> castle-model-converter: Warning: X3D: X3D XML: element >>>>>> references unknown field name "enabled" >>>>>> castle-model-converter: Warning: X3D: X3D XML: element >>>>>> references unknown field name "startTime" >>>>>> castle-model-converter: Warning: X3D: X3D XML: element >>>>>> references unknown field name "stopTime" >>>>>> >>>>>> I will try providing a field value in the ProtoInterface >>>>>> >>>>>> If I "cleanup" enabled, startTime and stopTime, I get: >>>>>> >>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>> "MenuItem", event "inputTrue" references (by "IS" clause) non-existing >>>>>> event "enabled" >>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) non-existing >>>>>> event "startTime" >>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) non-existing >>>>>> event "stopTime" >>>>>> >>>>>> I guess what I conclude at this point is, startTime and stopTime are >>>>>> bad DEF names, but what about enabled as a field? The dominoes are falling. >>>>>> >>>>>> About your two scenarios in the other message, perhaps this is >>>>>> revealing. >>>>>> >>>>>> See attached attempt to fix original issue, which resulted in the >>>>>> above. >>>>>> >>>>>> John >>>>>> >>>>>> On Sun, Feb 2, 2025 at 3:59?PM Andreas Plesch < >>>>>> andreasplesch at gmail.com> wrote: >>>>>> >>>>>>> I think x3dom, reasonably, expects a value for the fieldValue nodes: >>>>>>> >>>>>>> For example: >>>>>>> >>>>>>> >>>>>>> >>>>>>> and others. >>>>>>> >>>>>>> On Sun, Feb 2, 2025 at 5:42?AM John Carlson >>>>>>> wrote: >>>>>>> >>>>>>>> Andreas, Joe, >>>>>>>> >>>>>>>> Reset Button, Reset_Clock added. >>>>>>>> >>>>>>>> See attached zip for details, or visit link; >>>>>>>> >>>>>>>> >>>>>>>> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>>>> >>>>>>>> For some reason, this link doesn't show the live scene? >>>>>>>> >>>>>>>> >>>>>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>>>> >>>>>>>> Puzzled, haven't researched it yet. Looks good in Sunrize and >>>>>>>> X_ITE, will try FreeWRL next. >>>>>>>> >>>>>>>> John >>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Andreas Plesch >>>>>>> Waltham, MA 02453 >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> Andreas Plesch >>>>> Waltham, MA 02453 >>>>> >>>> >>>> >>>> -- >>>> Andreas Plesch >>>> Waltham, MA 02453 >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Wed Feb 5 13:31:07 2025 From: yottzumm at gmail.com (John Carlson) Date: Wed, 5 Feb 2025 15:31:07 -0600 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: Message-ID: Remember you can probably look at what X_ITE and FreeWRL did. Here?s another example, with a wink. https://github.com/coderextreme/ci2had/blob/main/resources/JinWink.x3d I have not tried to pare it down at all, but perhaps I can also work on that. If it?s okay with you, I will maintain existing geometry, and just take out HAnimDisplacers and ROUTEs we are uninterested in. There are more examples in the same folder. The FACS examples in the HumanoidAnimation/FacialAnimation X3D archives can serve as a guide, but i believe most of them do not use HAnim. There?s one that does, I believe it?s first. When I provide examples, I will try to ensure they will animate in both Sunrize and FreeWRL 6.7 John On Wed, Feb 5, 2025 at 3:12?PM Andreas Plesch wrote: > Hi John, > > Thanks. I found the tongue.x3d example but if you can create another one > that would be helpful in general. > > You vastly overestimate my ability and availability ;) This would be a > longer term project. I have an idea what to do. > > Andreas > > > On Wed, Feb 5, 2025, 1:31?PM John Carlson wrote: > >> I had one I sent to Holger, probably derived from this one: >> >> >> https://github.com/coderextreme/ci2had/blob/main/resources/JinMouthStretch.x3d >> >> >> What I would do (again) is take out all the segments but the tongue. >> >> There?s no menus involved in this one. >> >> If you need further assistance, like a smaller example, I can help. Also >> all the Jin*.x3d FACS action units can also provide examples. >> >> I?ll be pretty unbusy today. I can allocate some time for creating a >> model, make sure it animates, etc. >> >> If you?re able to allocate some time today, great, we have an HAnim >> meeting tomorrow and showing off X3DOM editor using Displacers would be >> fantastic! >> >> Remember there?s a coord field in HAnimSegment that the HAnimDisplacer >> operates on! >> >> John >> >> On Wed, Feb 5, 2025 at 12:01?PM Andreas Plesch >> wrote: >> >>> Hi John, >>> >>> The reason is that Displacers are currently implemented in x3dom only >>> for Joints, but not for Segments, unfortunately. Do you know of a simple >>> but instructive test case of Segments with Displacers ? >>> >>> Andreas >>> >>> >>> On Tue, Feb 4, 2025, 2:33?PM John Carlson wrote: >>> >>>> I will try to test this in castle model converter. >>>> >>>> I did try setting a value for the outputOnly fields, but the converter >>>> wouldn?t shut up. >>>> >>>> The model below doesn?t seem to animate when one presses the menu >>>> items. Did you get it to animate? >>>> >>>> On Tue, Feb 4, 2025 at 12:27?PM Andreas Plesch >>>> wrote: >>>> >>>>> Hi John, all, >>>>> >>>>> It turns out that x3dom currently expects a default value for Proto >>>>> fields even for outputOnly fields. This is due to how Proto fields are >>>>> initialized. They always need to have a value. While the spec. does not >>>>> require this, it seems still good practice to always define a default value >>>>> in the ProtoInterface. There may be a case where an outputOnly field is >>>>> used in ISing where a valid value would be expected. There may be other >>>>> corner cases. >>>>> >>>>> Here is your example with added default values for outputOnly fields: >>>>> >>>>> >>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/af5ff3148c1159f71d34fb78c1f63024/raw/b3d4470107ab74e301ed48448ab2a4f4154672e0/ManyClocks_John.x3d >>>>> >>>>> This could be fixed in x3dom, by always setting some default value. Is >>>>> there a list of recommended defaults for each data type if no other source >>>>> of defaults is available? For SFTime it seems to be -1. >>>>> >>>>> >>>>> -Andreas >>>>> >>>>> >>>>> On Mon, Feb 3, 2025 at 7:39?AM Andreas Plesch >>>>> wrote: >>>>> >>>>>> Hi John, >>>>>> >>>>>> On Mon, Feb 3, 2025 at 12:48?AM John Carlson >>>>>> wrote: >>>>>> >>>>>>> Andreas, "startTime" is an accessType outputOnly field, so why do I >>>>>>> need to provide a value attribute in fieldValue? I'm kind of confused. >>>>>>> I'm probably missing something in the spec. >>>>>>> >>>>>> >>>>>> You are right, I only outlined scenarios where the accessType allows >>>>>> input or initialization.. >>>>>> In the outputOnly case it is not necessary to provide a fieldValue >>>>>> node at all since there is no value which can be provided. Providing the >>>>>> node would indeed be confusing, to both the user code reader and any X3D >>>>>> browser. >>>>>> I believe the spec. is silent on this case in any encoding. >>>>>> >>>>>> Best, Andreas >>>>>> >>>>>> Thanks for any clarification. >>>>>>> >>>>>>> I have finally enabled schematron on the project, but I'm finding it >>>>>>> hard to understand the messages, and modifications that I make, while >>>>>>> removing the immediate problems, seem to move the problems elsewhere. >>>>>>> >>>>>>> Explaining why I need a "startTime" fieldValue value is my main lack >>>>>>> of understanding, but perhaps I need a whole review of accessType. >>>>>>> >>>>>>> Castle Model Converter reports: >>>>>>> >>>>>>> castle-model-converter: Warning: X3D: X3D XML: element >>>>>>> references unknown field name "enabled" >>>>>>> castle-model-converter: Warning: X3D: X3D XML: element >>>>>>> references unknown field name "startTime" >>>>>>> castle-model-converter: Warning: X3D: X3D XML: element >>>>>>> references unknown field name "stopTime" >>>>>>> >>>>>>> I will try providing a field value in the ProtoInterface >>>>>>> >>>>>>> If I "cleanup" enabled, startTime and stopTime, I get: >>>>>>> >>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>>> "MenuItem", event "inputTrue" references (by "IS" clause) non-existing >>>>>>> event "enabled" >>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) non-existing >>>>>>> event "startTime" >>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) non-existing >>>>>>> event "stopTime" >>>>>>> >>>>>>> I guess what I conclude at this point is, startTime and stopTime are >>>>>>> bad DEF names, but what about enabled as a field? The dominoes are falling. >>>>>>> >>>>>>> About your two scenarios in the other message, perhaps this is >>>>>>> revealing. >>>>>>> >>>>>>> See attached attempt to fix original issue, which resulted in the >>>>>>> above. >>>>>>> >>>>>>> John >>>>>>> >>>>>>> On Sun, Feb 2, 2025 at 3:59?PM Andreas Plesch < >>>>>>> andreasplesch at gmail.com> wrote: >>>>>>> >>>>>>>> I think x3dom, reasonably, expects a value for the fieldValue nodes: >>>>>>>> >>>>>>>> For example: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> and others. >>>>>>>> >>>>>>>> On Sun, Feb 2, 2025 at 5:42?AM John Carlson >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Andreas, Joe, >>>>>>>>> >>>>>>>>> Reset Button, Reset_Clock added. >>>>>>>>> >>>>>>>>> See attached zip for details, or visit link; >>>>>>>>> >>>>>>>>> >>>>>>>>> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>>>>> >>>>>>>>> For some reason, this link doesn't show the live scene? >>>>>>>>> >>>>>>>>> >>>>>>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>>>>> >>>>>>>>> Puzzled, haven't researched it yet. Looks good in Sunrize and >>>>>>>>> X_ITE, will try FreeWRL next. >>>>>>>>> >>>>>>>>> John >>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Andreas Plesch >>>>>>>> Waltham, MA 02453 >>>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Andreas Plesch >>>>>> Waltham, MA 02453 >>>>>> >>>>> >>>>> >>>>> -- >>>>> Andreas Plesch >>>>> Waltham, MA 02453 >>>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Wed Feb 5 13:37:30 2025 From: yottzumm at gmail.com (John Carlson) Date: Wed, 5 Feb 2025 15:37:30 -0600 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: Message-ID: I have verified that Tongue.x3d runs in both Sunrize and FreeWRL: Here's what I tried: $ npx sunrize at latest Tongue.x3d $ /c/Program\ Files\ \(x86\)/freeWRL/freeWRL.6.7/freeWRL.exe Tongue.x3d On Wed, Feb 5, 2025 at 12:41?PM John Carlson wrote: > Here's a small example, Tongue.x3d. > > Your efforts are appreciated! > > John > > On Wed, Feb 5, 2025 at 12:01?PM Andreas Plesch > wrote: > >> Hi John, >> >> The reason is that Displacers are currently implemented in x3dom only for >> Joints, but not for Segments, unfortunately. Do you know of a simple but >> instructive test case of Segments with Displacers ? >> >> Andreas >> >> >> On Tue, Feb 4, 2025, 2:33?PM John Carlson wrote: >> >>> I will try to test this in castle model converter. >>> >>> I did try setting a value for the outputOnly fields, but the converter >>> wouldn?t shut up. >>> >>> The model below doesn?t seem to animate when one presses the menu >>> items. Did you get it to animate? >>> >>> On Tue, Feb 4, 2025 at 12:27?PM Andreas Plesch >>> wrote: >>> >>>> Hi John, all, >>>> >>>> It turns out that x3dom currently expects a default value for Proto >>>> fields even for outputOnly fields. This is due to how Proto fields are >>>> initialized. They always need to have a value. While the spec. does not >>>> require this, it seems still good practice to always define a default value >>>> in the ProtoInterface. There may be a case where an outputOnly field is >>>> used in ISing where a valid value would be expected. There may be other >>>> corner cases. >>>> >>>> Here is your example with added default values for outputOnly fields: >>>> >>>> >>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/af5ff3148c1159f71d34fb78c1f63024/raw/b3d4470107ab74e301ed48448ab2a4f4154672e0/ManyClocks_John.x3d >>>> >>>> This could be fixed in x3dom, by always setting some default value. Is >>>> there a list of recommended defaults for each data type if no other source >>>> of defaults is available? For SFTime it seems to be -1. >>>> >>>> >>>> -Andreas >>>> >>>> >>>> On Mon, Feb 3, 2025 at 7:39?AM Andreas Plesch >>>> wrote: >>>> >>>>> Hi John, >>>>> >>>>> On Mon, Feb 3, 2025 at 12:48?AM John Carlson >>>>> wrote: >>>>> >>>>>> Andreas, "startTime" is an accessType outputOnly field, so why do I >>>>>> need to provide a value attribute in fieldValue? I'm kind of confused. >>>>>> I'm probably missing something in the spec. >>>>>> >>>>> >>>>> You are right, I only outlined scenarios where the accessType allows >>>>> input or initialization.. >>>>> In the outputOnly case it is not necessary to provide a fieldValue >>>>> node at all since there is no value which can be provided. Providing the >>>>> node would indeed be confusing, to both the user code reader and any X3D >>>>> browser. >>>>> I believe the spec. is silent on this case in any encoding. >>>>> >>>>> Best, Andreas >>>>> >>>>> Thanks for any clarification. >>>>>> >>>>>> I have finally enabled schematron on the project, but I'm finding it >>>>>> hard to understand the messages, and modifications that I make, while >>>>>> removing the immediate problems, seem to move the problems elsewhere. >>>>>> >>>>>> Explaining why I need a "startTime" fieldValue value is my main lack >>>>>> of understanding, but perhaps I need a whole review of accessType. >>>>>> >>>>>> Castle Model Converter reports: >>>>>> >>>>>> castle-model-converter: Warning: X3D: X3D XML: element >>>>>> references unknown field name "enabled" >>>>>> castle-model-converter: Warning: X3D: X3D XML: element >>>>>> references unknown field name "startTime" >>>>>> castle-model-converter: Warning: X3D: X3D XML: element >>>>>> references unknown field name "stopTime" >>>>>> >>>>>> I will try providing a field value in the ProtoInterface >>>>>> >>>>>> If I "cleanup" enabled, startTime and stopTime, I get: >>>>>> >>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>> "MenuItem", event "inputTrue" references (by "IS" clause) non-existing >>>>>> event "enabled" >>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) non-existing >>>>>> event "startTime" >>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) non-existing >>>>>> event "stopTime" >>>>>> >>>>>> I guess what I conclude at this point is, startTime and stopTime are >>>>>> bad DEF names, but what about enabled as a field? The dominoes are falling. >>>>>> >>>>>> About your two scenarios in the other message, perhaps this is >>>>>> revealing. >>>>>> >>>>>> See attached attempt to fix original issue, which resulted in the >>>>>> above. >>>>>> >>>>>> John >>>>>> >>>>>> On Sun, Feb 2, 2025 at 3:59?PM Andreas Plesch < >>>>>> andreasplesch at gmail.com> wrote: >>>>>> >>>>>>> I think x3dom, reasonably, expects a value for the fieldValue nodes: >>>>>>> >>>>>>> For example: >>>>>>> >>>>>>> >>>>>>> >>>>>>> and others. >>>>>>> >>>>>>> On Sun, Feb 2, 2025 at 5:42?AM John Carlson >>>>>>> wrote: >>>>>>> >>>>>>>> Andreas, Joe, >>>>>>>> >>>>>>>> Reset Button, Reset_Clock added. >>>>>>>> >>>>>>>> See attached zip for details, or visit link; >>>>>>>> >>>>>>>> >>>>>>>> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>>>> >>>>>>>> For some reason, this link doesn't show the live scene? >>>>>>>> >>>>>>>> >>>>>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>>>> >>>>>>>> Puzzled, haven't researched it yet. Looks good in Sunrize and >>>>>>>> X_ITE, will try FreeWRL next. >>>>>>>> >>>>>>>> John >>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Andreas Plesch >>>>>>> Waltham, MA 02453 >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> Andreas Plesch >>>>> Waltham, MA 02453 >>>>> >>>> >>>> >>>> -- >>>> Andreas Plesch >>>> Waltham, MA 02453 >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Wed Feb 5 13:50:20 2025 From: yottzumm at gmail.com (John Carlson) Date: Wed, 5 Feb 2025 15:50:20 -0600 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: Message-ID: Here's another example with 2 HAnimDisplacers that works in FreeWRL 6.7 and the latest Sunrize. I am attaching that cleanup script that was used to clean up JinWink.x3d. You should be able to use a similar script to clean up any of the Jin*.x3d in the ci2had/resources folder previously mentioned! Enjoy! On Wed, Feb 5, 2025 at 3:31?PM John Carlson wrote: > Remember you can probably look at what X_ITE and FreeWRL did. > > Here?s another example, with a wink. > https://github.com/coderextreme/ci2had/blob/main/resources/JinWink.x3d > > I have not tried to pare it down at all, but perhaps I can also work on > that. > > If it?s okay with you, I will maintain existing geometry, and just take > out HAnimDisplacers and ROUTEs we are uninterested in. > > There are more examples in the same folder. > > The FACS examples in the HumanoidAnimation/FacialAnimation X3D archives > can serve as a guide, but i believe most of them do not use HAnim. There?s > one that does, I believe it?s first. > > When I provide examples, I will try to ensure they will animate in both > Sunrize and FreeWRL 6.7 > > John > > On Wed, Feb 5, 2025 at 3:12?PM Andreas Plesch > wrote: > >> Hi John, >> >> Thanks. I found the tongue.x3d example but if you can create another one >> that would be helpful in general. >> >> You vastly overestimate my ability and availability ;) This would be a >> longer term project. I have an idea what to do. >> >> Andreas >> >> >> On Wed, Feb 5, 2025, 1:31?PM John Carlson wrote: >> >>> I had one I sent to Holger, probably derived from this one: >>> >>> >>> https://github.com/coderextreme/ci2had/blob/main/resources/JinMouthStretch.x3d >>> >>> >>> What I would do (again) is take out all the segments but the tongue. >>> >>> There?s no menus involved in this one. >>> >>> If you need further assistance, like a smaller example, I can help. >>> Also all the Jin*.x3d FACS action units can also provide examples. >>> >>> I?ll be pretty unbusy today. I can allocate some time for creating a >>> model, make sure it animates, etc. >>> >>> If you?re able to allocate some time today, great, we have an HAnim >>> meeting tomorrow and showing off X3DOM editor using Displacers would be >>> fantastic! >>> >>> Remember there?s a coord field in HAnimSegment that the HAnimDisplacer >>> operates on! >>> >>> John >>> >>> On Wed, Feb 5, 2025 at 12:01?PM Andreas Plesch >>> wrote: >>> >>>> Hi John, >>>> >>>> The reason is that Displacers are currently implemented in x3dom only >>>> for Joints, but not for Segments, unfortunately. Do you know of a simple >>>> but instructive test case of Segments with Displacers ? >>>> >>>> Andreas >>>> >>>> >>>> On Tue, Feb 4, 2025, 2:33?PM John Carlson wrote: >>>> >>>>> I will try to test this in castle model converter. >>>>> >>>>> I did try setting a value for the outputOnly fields, but the converter >>>>> wouldn?t shut up. >>>>> >>>>> The model below doesn?t seem to animate when one presses the menu >>>>> items. Did you get it to animate? >>>>> >>>>> On Tue, Feb 4, 2025 at 12:27?PM Andreas Plesch < >>>>> andreasplesch at gmail.com> wrote: >>>>> >>>>>> Hi John, all, >>>>>> >>>>>> It turns out that x3dom currently expects a default value for Proto >>>>>> fields even for outputOnly fields. This is due to how Proto fields are >>>>>> initialized. They always need to have a value. While the spec. does not >>>>>> require this, it seems still good practice to always define a default value >>>>>> in the ProtoInterface. There may be a case where an outputOnly field is >>>>>> used in ISing where a valid value would be expected. There may be other >>>>>> corner cases. >>>>>> >>>>>> Here is your example with added default values for outputOnly fields: >>>>>> >>>>>> >>>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/af5ff3148c1159f71d34fb78c1f63024/raw/b3d4470107ab74e301ed48448ab2a4f4154672e0/ManyClocks_John.x3d >>>>>> >>>>>> This could be fixed in x3dom, by always setting some default value. >>>>>> Is there a list of recommended defaults for each data type if no other >>>>>> source of defaults is available? For SFTime it seems to be -1. >>>>>> >>>>>> >>>>>> -Andreas >>>>>> >>>>>> >>>>>> On Mon, Feb 3, 2025 at 7:39?AM Andreas Plesch < >>>>>> andreasplesch at gmail.com> wrote: >>>>>> >>>>>>> Hi John, >>>>>>> >>>>>>> On Mon, Feb 3, 2025 at 12:48?AM John Carlson >>>>>>> wrote: >>>>>>> >>>>>>>> Andreas, "startTime" is an accessType outputOnly field, so why do I >>>>>>>> need to provide a value attribute in fieldValue? I'm kind of confused. >>>>>>>> I'm probably missing something in the spec. >>>>>>>> >>>>>>> >>>>>>> You are right, I only outlined scenarios where the accessType allows >>>>>>> input or initialization.. >>>>>>> In the outputOnly case it is not necessary to provide a fieldValue >>>>>>> node at all since there is no value which can be provided. Providing the >>>>>>> node would indeed be confusing, to both the user code reader and any X3D >>>>>>> browser. >>>>>>> I believe the spec. is silent on this case in any encoding. >>>>>>> >>>>>>> Best, Andreas >>>>>>> >>>>>>> Thanks for any clarification. >>>>>>>> >>>>>>>> I have finally enabled schematron on the project, but I'm finding >>>>>>>> it hard to understand the messages, and modifications that I make, while >>>>>>>> removing the immediate problems, seem to move the problems elsewhere. >>>>>>>> >>>>>>>> Explaining why I need a "startTime" fieldValue value is my main >>>>>>>> lack of understanding, but perhaps I need a whole review of accessType. >>>>>>>> >>>>>>>> Castle Model Converter reports: >>>>>>>> >>>>>>>> castle-model-converter: Warning: X3D: X3D XML: element >>>>>>>> references unknown field name "enabled" >>>>>>>> castle-model-converter: Warning: X3D: X3D XML: element >>>>>>>> references unknown field name "startTime" >>>>>>>> castle-model-converter: Warning: X3D: X3D XML: element >>>>>>>> references unknown field name "stopTime" >>>>>>>> >>>>>>>> I will try providing a field value in the ProtoInterface >>>>>>>> >>>>>>>> If I "cleanup" enabled, startTime and stopTime, I get: >>>>>>>> >>>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>>>> "MenuItem", event "inputTrue" references (by "IS" clause) non-existing >>>>>>>> event "enabled" >>>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) non-existing >>>>>>>> event "startTime" >>>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) non-existing >>>>>>>> event "stopTime" >>>>>>>> >>>>>>>> I guess what I conclude at this point is, startTime and stopTime >>>>>>>> are bad DEF names, but what about enabled as a field? The dominoes are >>>>>>>> falling. >>>>>>>> >>>>>>>> About your two scenarios in the other message, perhaps this is >>>>>>>> revealing. >>>>>>>> >>>>>>>> See attached attempt to fix original issue, which resulted in the >>>>>>>> above. >>>>>>>> >>>>>>>> John >>>>>>>> >>>>>>>> On Sun, Feb 2, 2025 at 3:59?PM Andreas Plesch < >>>>>>>> andreasplesch at gmail.com> wrote: >>>>>>>> >>>>>>>>> I think x3dom, reasonably, expects a value for the fieldValue >>>>>>>>> nodes: >>>>>>>>> >>>>>>>>> For example: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> and others. >>>>>>>>> >>>>>>>>> On Sun, Feb 2, 2025 at 5:42?AM John Carlson >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Andreas, Joe, >>>>>>>>>> >>>>>>>>>> Reset Button, Reset_Clock added. >>>>>>>>>> >>>>>>>>>> See attached zip for details, or visit link; >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>>>>>> >>>>>>>>>> For some reason, this link doesn't show the live scene? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>>>>>> >>>>>>>>>> Puzzled, haven't researched it yet. Looks good in Sunrize and >>>>>>>>>> X_ITE, will try FreeWRL next. >>>>>>>>>> >>>>>>>>>> John >>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Andreas Plesch >>>>>>>>> Waltham, MA 02453 >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Andreas Plesch >>>>>>> Waltham, MA 02453 >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Andreas Plesch >>>>>> Waltham, MA 02453 >>>>>> >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: JinImageAtlas.jpg Type: image/jpeg Size: 50194 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Wink.x3d Type: model/x3d+xml Size: 290422 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cleanwink.py Type: text/x-python Size: 2244 bytes Desc: not available URL: From yottzumm at gmail.com Wed Feb 5 13:53:04 2025 From: yottzumm at gmail.com (John Carlson) Date: Wed, 5 Feb 2025 15:53:04 -0600 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: Message-ID: OOPS, grabbed wrong file. Sorry! On Wed, Feb 5, 2025 at 3:50?PM John Carlson wrote: > Here's another example with 2 HAnimDisplacers that works in FreeWRL 6.7 > and the latest Sunrize. I am attaching that cleanup script that was used > to clean up JinWink.x3d. You should be able to use a similar script to > clean up any of the Jin*.x3d in the ci2had/resources folder previously > mentioned! > > Enjoy! > > On Wed, Feb 5, 2025 at 3:31?PM John Carlson wrote: > >> Remember you can probably look at what X_ITE and FreeWRL did. >> >> Here?s another example, with a wink. >> https://github.com/coderextreme/ci2had/blob/main/resources/JinWink.x3d >> >> I have not tried to pare it down at all, but perhaps I can also work on >> that. >> >> If it?s okay with you, I will maintain existing geometry, and just take >> out HAnimDisplacers and ROUTEs we are uninterested in. >> >> There are more examples in the same folder. >> >> The FACS examples in the HumanoidAnimation/FacialAnimation X3D archives >> can serve as a guide, but i believe most of them do not use HAnim. There?s >> one that does, I believe it?s first. >> >> When I provide examples, I will try to ensure they will animate in both >> Sunrize and FreeWRL 6.7 >> >> John >> >> On Wed, Feb 5, 2025 at 3:12?PM Andreas Plesch >> wrote: >> >>> Hi John, >>> >>> Thanks. I found the tongue.x3d example but if you can create another one >>> that would be helpful in general. >>> >>> You vastly overestimate my ability and availability ;) This would be a >>> longer term project. I have an idea what to do. >>> >>> Andreas >>> >>> >>> On Wed, Feb 5, 2025, 1:31?PM John Carlson wrote: >>> >>>> I had one I sent to Holger, probably derived from this one: >>>> >>>> >>>> https://github.com/coderextreme/ci2had/blob/main/resources/JinMouthStretch.x3d >>>> >>>> >>>> What I would do (again) is take out all the segments but the tongue. >>>> >>>> There?s no menus involved in this one. >>>> >>>> If you need further assistance, like a smaller example, I can help. >>>> Also all the Jin*.x3d FACS action units can also provide examples. >>>> >>>> I?ll be pretty unbusy today. I can allocate some time for creating a >>>> model, make sure it animates, etc. >>>> >>>> If you?re able to allocate some time today, great, we have an HAnim >>>> meeting tomorrow and showing off X3DOM editor using Displacers would be >>>> fantastic! >>>> >>>> Remember there?s a coord field in HAnimSegment that the HAnimDisplacer >>>> operates on! >>>> >>>> John >>>> >>>> On Wed, Feb 5, 2025 at 12:01?PM Andreas Plesch >>>> wrote: >>>> >>>>> Hi John, >>>>> >>>>> The reason is that Displacers are currently implemented in x3dom only >>>>> for Joints, but not for Segments, unfortunately. Do you know of a simple >>>>> but instructive test case of Segments with Displacers ? >>>>> >>>>> Andreas >>>>> >>>>> >>>>> On Tue, Feb 4, 2025, 2:33?PM John Carlson wrote: >>>>> >>>>>> I will try to test this in castle model converter. >>>>>> >>>>>> I did try setting a value for the outputOnly fields, but the >>>>>> converter wouldn?t shut up. >>>>>> >>>>>> The model below doesn?t seem to animate when one presses the menu >>>>>> items. Did you get it to animate? >>>>>> >>>>>> On Tue, Feb 4, 2025 at 12:27?PM Andreas Plesch < >>>>>> andreasplesch at gmail.com> wrote: >>>>>> >>>>>>> Hi John, all, >>>>>>> >>>>>>> It turns out that x3dom currently expects a default value for Proto >>>>>>> fields even for outputOnly fields. This is due to how Proto fields are >>>>>>> initialized. They always need to have a value. While the spec. does not >>>>>>> require this, it seems still good practice to always define a default value >>>>>>> in the ProtoInterface. There may be a case where an outputOnly field is >>>>>>> used in ISing where a valid value would be expected. There may be other >>>>>>> corner cases. >>>>>>> >>>>>>> Here is your example with added default values for outputOnly fields: >>>>>>> >>>>>>> >>>>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/af5ff3148c1159f71d34fb78c1f63024/raw/b3d4470107ab74e301ed48448ab2a4f4154672e0/ManyClocks_John.x3d >>>>>>> >>>>>>> This could be fixed in x3dom, by always setting some default value. >>>>>>> Is there a list of recommended defaults for each data type if no other >>>>>>> source of defaults is available? For SFTime it seems to be -1. >>>>>>> >>>>>>> >>>>>>> -Andreas >>>>>>> >>>>>>> >>>>>>> On Mon, Feb 3, 2025 at 7:39?AM Andreas Plesch < >>>>>>> andreasplesch at gmail.com> wrote: >>>>>>> >>>>>>>> Hi John, >>>>>>>> >>>>>>>> On Mon, Feb 3, 2025 at 12:48?AM John Carlson >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Andreas, "startTime" is an accessType outputOnly field, so why do >>>>>>>>> I need to provide a value attribute in fieldValue? I'm kind of confused. >>>>>>>>> I'm probably missing something in the spec. >>>>>>>>> >>>>>>>> >>>>>>>> You are right, I only outlined scenarios where the accessType >>>>>>>> allows input or initialization.. >>>>>>>> In the outputOnly case it is not necessary to provide a fieldValue >>>>>>>> node at all since there is no value which can be provided. Providing the >>>>>>>> node would indeed be confusing, to both the user code reader and any X3D >>>>>>>> browser. >>>>>>>> I believe the spec. is silent on this case in any encoding. >>>>>>>> >>>>>>>> Best, Andreas >>>>>>>> >>>>>>>> Thanks for any clarification. >>>>>>>>> >>>>>>>>> I have finally enabled schematron on the project, but I'm finding >>>>>>>>> it hard to understand the messages, and modifications that I make, while >>>>>>>>> removing the immediate problems, seem to move the problems elsewhere. >>>>>>>>> >>>>>>>>> Explaining why I need a "startTime" fieldValue value is my main >>>>>>>>> lack of understanding, but perhaps I need a whole review of accessType. >>>>>>>>> >>>>>>>>> Castle Model Converter reports: >>>>>>>>> >>>>>>>>> castle-model-converter: Warning: X3D: X3D XML: >>>>>>>>> element references unknown field name "enabled" >>>>>>>>> castle-model-converter: Warning: X3D: X3D XML: >>>>>>>>> element references unknown field name "startTime" >>>>>>>>> castle-model-converter: Warning: X3D: X3D XML: >>>>>>>>> element references unknown field name "stopTime" >>>>>>>>> >>>>>>>>> I will try providing a field value in the ProtoInterface >>>>>>>>> >>>>>>>>> If I "cleanup" enabled, startTime and stopTime, I get: >>>>>>>>> >>>>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>>>>> "MenuItem", event "inputTrue" references (by "IS" clause) non-existing >>>>>>>>> event "enabled" >>>>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) non-existing >>>>>>>>> event "startTime" >>>>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) non-existing >>>>>>>>> event "stopTime" >>>>>>>>> >>>>>>>>> I guess what I conclude at this point is, startTime and stopTime >>>>>>>>> are bad DEF names, but what about enabled as a field? The dominoes are >>>>>>>>> falling. >>>>>>>>> >>>>>>>>> About your two scenarios in the other message, perhaps this is >>>>>>>>> revealing. >>>>>>>>> >>>>>>>>> See attached attempt to fix original issue, which resulted in the >>>>>>>>> above. >>>>>>>>> >>>>>>>>> John >>>>>>>>> >>>>>>>>> On Sun, Feb 2, 2025 at 3:59?PM Andreas Plesch < >>>>>>>>> andreasplesch at gmail.com> wrote: >>>>>>>>> >>>>>>>>>> I think x3dom, reasonably, expects a value for the fieldValue >>>>>>>>>> nodes: >>>>>>>>>> >>>>>>>>>> For example: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> and others. >>>>>>>>>> >>>>>>>>>> On Sun, Feb 2, 2025 at 5:42?AM John Carlson >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Andreas, Joe, >>>>>>>>>>> >>>>>>>>>>> Reset Button, Reset_Clock added. >>>>>>>>>>> >>>>>>>>>>> See attached zip for details, or visit link; >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>>>>>>> >>>>>>>>>>> For some reason, this link doesn't show the live scene? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>>>>>>> >>>>>>>>>>> Puzzled, haven't researched it yet. Looks good in Sunrize and >>>>>>>>>>> X_ITE, will try FreeWRL next. >>>>>>>>>>> >>>>>>>>>>> John >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Andreas Plesch >>>>>>>>>> Waltham, MA 02453 >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Andreas Plesch >>>>>>>> Waltham, MA 02453 >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Andreas Plesch >>>>>>> Waltham, MA 02453 >>>>>>> >>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: CleanedWink.x3d Type: model/x3d+xml Size: 278474 bytes Desc: not available URL: From yottzumm at gmail.com Wed Feb 5 13:58:49 2025 From: yottzumm at gmail.com (John Carlson) Date: Wed, 5 Feb 2025 15:58:49 -0600 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: Message-ID: Also available here for direct inclusion in X3DOM Editor or X_ITE Playground: https://github.com/coderextreme/ci2had/blob/main/resources/CleanedWink.x3d https://github.com/coderextreme/ci2had/blob/main/resources/Tongue.x3d I realize some of the DEFs and names may not meet spec. Corrections (hopefully with scripts) welcome! John On Wed, Feb 5, 2025 at 3:53?PM John Carlson wrote: > OOPS, grabbed wrong file. > > Sorry! > > On Wed, Feb 5, 2025 at 3:50?PM John Carlson wrote: > >> Here's another example with 2 HAnimDisplacers that works in FreeWRL 6.7 >> and the latest Sunrize. I am attaching that cleanup script that was used >> to clean up JinWink.x3d. You should be able to use a similar script to >> clean up any of the Jin*.x3d in the ci2had/resources folder previously >> mentioned! >> >> Enjoy! >> >> On Wed, Feb 5, 2025 at 3:31?PM John Carlson wrote: >> >>> Remember you can probably look at what X_ITE and FreeWRL did. >>> >>> Here?s another example, with a wink. >>> https://github.com/coderextreme/ci2had/blob/main/resources/JinWink.x3d >>> >>> I have not tried to pare it down at all, but perhaps I can also work on >>> that. >>> >>> If it?s okay with you, I will maintain existing geometry, and just take >>> out HAnimDisplacers and ROUTEs we are uninterested in. >>> >>> There are more examples in the same folder. >>> >>> The FACS examples in the HumanoidAnimation/FacialAnimation X3D archives >>> can serve as a guide, but i believe most of them do not use HAnim. There?s >>> one that does, I believe it?s first. >>> >>> When I provide examples, I will try to ensure they will animate in both >>> Sunrize and FreeWRL 6.7 >>> >>> John >>> >>> On Wed, Feb 5, 2025 at 3:12?PM Andreas Plesch >>> wrote: >>> >>>> Hi John, >>>> >>>> Thanks. I found the tongue.x3d example but if you can create another >>>> one that would be helpful in general. >>>> >>>> You vastly overestimate my ability and availability ;) This would be a >>>> longer term project. I have an idea what to do. >>>> >>>> Andreas >>>> >>>> >>>> On Wed, Feb 5, 2025, 1:31?PM John Carlson wrote: >>>> >>>>> I had one I sent to Holger, probably derived from this one: >>>>> >>>>> >>>>> https://github.com/coderextreme/ci2had/blob/main/resources/JinMouthStretch.x3d >>>>> >>>>> >>>>> What I would do (again) is take out all the segments but the tongue. >>>>> >>>>> There?s no menus involved in this one. >>>>> >>>>> If you need further assistance, like a smaller example, I can help. >>>>> Also all the Jin*.x3d FACS action units can also provide examples. >>>>> >>>>> I?ll be pretty unbusy today. I can allocate some time for creating a >>>>> model, make sure it animates, etc. >>>>> >>>>> If you?re able to allocate some time today, great, we have an HAnim >>>>> meeting tomorrow and showing off X3DOM editor using Displacers would be >>>>> fantastic! >>>>> >>>>> Remember there?s a coord field in HAnimSegment that the HAnimDisplacer >>>>> operates on! >>>>> >>>>> John >>>>> >>>>> On Wed, Feb 5, 2025 at 12:01?PM Andreas Plesch < >>>>> andreasplesch at gmail.com> wrote: >>>>> >>>>>> Hi John, >>>>>> >>>>>> The reason is that Displacers are currently implemented in x3dom only >>>>>> for Joints, but not for Segments, unfortunately. Do you know of a simple >>>>>> but instructive test case of Segments with Displacers ? >>>>>> >>>>>> Andreas >>>>>> >>>>>> >>>>>> On Tue, Feb 4, 2025, 2:33?PM John Carlson wrote: >>>>>> >>>>>>> I will try to test this in castle model converter. >>>>>>> >>>>>>> I did try setting a value for the outputOnly fields, but the >>>>>>> converter wouldn?t shut up. >>>>>>> >>>>>>> The model below doesn?t seem to animate when one presses the menu >>>>>>> items. Did you get it to animate? >>>>>>> >>>>>>> On Tue, Feb 4, 2025 at 12:27?PM Andreas Plesch < >>>>>>> andreasplesch at gmail.com> wrote: >>>>>>> >>>>>>>> Hi John, all, >>>>>>>> >>>>>>>> It turns out that x3dom currently expects a default value for Proto >>>>>>>> fields even for outputOnly fields. This is due to how Proto fields are >>>>>>>> initialized. They always need to have a value. While the spec. does not >>>>>>>> require this, it seems still good practice to always define a default value >>>>>>>> in the ProtoInterface. There may be a case where an outputOnly field is >>>>>>>> used in ISing where a valid value would be expected. There may be other >>>>>>>> corner cases. >>>>>>>> >>>>>>>> Here is your example with added default values for outputOnly >>>>>>>> fields: >>>>>>>> >>>>>>>> >>>>>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/af5ff3148c1159f71d34fb78c1f63024/raw/b3d4470107ab74e301ed48448ab2a4f4154672e0/ManyClocks_John.x3d >>>>>>>> >>>>>>>> This could be fixed in x3dom, by always setting some default value. >>>>>>>> Is there a list of recommended defaults for each data type if no other >>>>>>>> source of defaults is available? For SFTime it seems to be -1. >>>>>>>> >>>>>>>> >>>>>>>> -Andreas >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Feb 3, 2025 at 7:39?AM Andreas Plesch < >>>>>>>> andreasplesch at gmail.com> wrote: >>>>>>>> >>>>>>>>> Hi John, >>>>>>>>> >>>>>>>>> On Mon, Feb 3, 2025 at 12:48?AM John Carlson >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Andreas, "startTime" is an accessType outputOnly field, so why do >>>>>>>>>> I need to provide a value attribute in fieldValue? I'm kind of confused. >>>>>>>>>> I'm probably missing something in the spec. >>>>>>>>>> >>>>>>>>> >>>>>>>>> You are right, I only outlined scenarios where the accessType >>>>>>>>> allows input or initialization.. >>>>>>>>> In the outputOnly case it is not necessary to provide a fieldValue >>>>>>>>> node at all since there is no value which can be provided. Providing the >>>>>>>>> node would indeed be confusing, to both the user code reader and any X3D >>>>>>>>> browser. >>>>>>>>> I believe the spec. is silent on this case in any encoding. >>>>>>>>> >>>>>>>>> Best, Andreas >>>>>>>>> >>>>>>>>> Thanks for any clarification. >>>>>>>>>> >>>>>>>>>> I have finally enabled schematron on the project, but I'm finding >>>>>>>>>> it hard to understand the messages, and modifications that I make, while >>>>>>>>>> removing the immediate problems, seem to move the problems elsewhere. >>>>>>>>>> >>>>>>>>>> Explaining why I need a "startTime" fieldValue value is my main >>>>>>>>>> lack of understanding, but perhaps I need a whole review of accessType. >>>>>>>>>> >>>>>>>>>> Castle Model Converter reports: >>>>>>>>>> >>>>>>>>>> castle-model-converter: Warning: X3D: X3D XML: >>>>>>>>>> element references unknown field name "enabled" >>>>>>>>>> castle-model-converter: Warning: X3D: X3D XML: >>>>>>>>>> element references unknown field name "startTime" >>>>>>>>>> castle-model-converter: Warning: X3D: X3D XML: >>>>>>>>>> element references unknown field name "stopTime" >>>>>>>>>> >>>>>>>>>> I will try providing a field value in the ProtoInterface >>>>>>>>>> >>>>>>>>>> If I "cleanup" enabled, startTime and stopTime, I get: >>>>>>>>>> >>>>>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>>>>>> "MenuItem", event "inputTrue" references (by "IS" clause) non-existing >>>>>>>>>> event "enabled" >>>>>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) non-existing >>>>>>>>>> event "startTime" >>>>>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) non-existing >>>>>>>>>> event "stopTime" >>>>>>>>>> >>>>>>>>>> I guess what I conclude at this point is, startTime and stopTime >>>>>>>>>> are bad DEF names, but what about enabled as a field? The dominoes are >>>>>>>>>> falling. >>>>>>>>>> >>>>>>>>>> About your two scenarios in the other message, perhaps this is >>>>>>>>>> revealing. >>>>>>>>>> >>>>>>>>>> See attached attempt to fix original issue, which resulted in the >>>>>>>>>> above. >>>>>>>>>> >>>>>>>>>> John >>>>>>>>>> >>>>>>>>>> On Sun, Feb 2, 2025 at 3:59?PM Andreas Plesch < >>>>>>>>>> andreasplesch at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> I think x3dom, reasonably, expects a value for the fieldValue >>>>>>>>>>> nodes: >>>>>>>>>>> >>>>>>>>>>> For example: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> and others. >>>>>>>>>>> >>>>>>>>>>> On Sun, Feb 2, 2025 at 5:42?AM John Carlson >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Andreas, Joe, >>>>>>>>>>>> >>>>>>>>>>>> Reset Button, Reset_Clock added. >>>>>>>>>>>> >>>>>>>>>>>> See attached zip for details, or visit link; >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>>>>>>>> >>>>>>>>>>>> For some reason, this link doesn't show the live scene? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>>>>>>>> >>>>>>>>>>>> Puzzled, haven't researched it yet. Looks good in Sunrize and >>>>>>>>>>>> X_ITE, will try FreeWRL next. >>>>>>>>>>>> >>>>>>>>>>>> John >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Andreas Plesch >>>>>>>>>>> Waltham, MA 02453 >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Andreas Plesch >>>>>>>>> Waltham, MA 02453 >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Andreas Plesch >>>>>>>> Waltham, MA 02453 >>>>>>>> >>>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Thu Feb 6 17:57:54 2025 From: yottzumm at gmail.com (John Carlson) Date: Thu, 6 Feb 2025 19:57:54 -0600 Subject: [x3d-public] Changing my version of X3DJSAIL Message-ID: I'm changing one of my versions of X3DJSAIL to accept a negative scale (at least in the HAnimHumanoid class) so I can scale my humanoid by that amount, and then get I'll rid of the scale amount. org.web3d.x3d.sai.InvalidFieldValueException: HAnimHumanoid scale newValue=[F at 245ec1a6 has component value less than (or equal to) restriction minExclusive=0 at org.web3d.x3d.jsail.HAnim.HAnimHumanoid.setScale(HAnimHumanoid.java:2561) at :program(net\coderextreme\data\Gramps8Final.js:34:3006-3157) Perhaps think about this use case for processing programs. Thanks! John -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Thu Feb 6 20:11:50 2025 From: yottzumm at gmail.com (John Carlson) Date: Thu, 6 Feb 2025 22:11:50 -0600 Subject: [x3d-public] X3DJSAIL reverses order of skin and skinCoord fields in HAnimHumanoid Message-ID: Summary. Please make sure input XML and output XML order field in HAnimHumanoid agree in X3DJSAIL. or solve the DEF/USE problem. Most obvious, skinCoord and skin become reversed. We need to make sure all our tools agree on field order. I will work on WinterAndSpring (the original source). $ java -cp ~/Downloads/X3DJSAIL.4.0.full.jar org.web3d.x3d.jsail.CommandLine -toXML Gramps8Final.x3d > Gramps8Final.x3d.out Order switched between input XML and output XML: $ grep GrampsSkinCoord Gramps8Final.x3d* Gramps8Final.x3d: Gramps8Final.x3d.out: Gramps8Final.x3d.out: If you're going to swap the fields, swap the DEF/USE too. ============================================================================================ Less obvious: Original XML: Gramps8Final.x3d: --------------------------------------------------------------------------------------------- Translated JSON: Gramps8Final.json: "@DEF":"GrampsSkinCoord", Gramps8Final.json: "@USE":"GrampsSkinCoord" -------------------------------------------------------------------------------------------------------- My GraalJS code (derived from JSON): .setSkinCoord(new Coordinate().setContainerFieldOverride("skinCoord").setDEF("Gramps .setCoord(new Coordinate().setUSE("GrampsSkinCoord")) ------------------------------------------------------------------------------------------------- My Java code (doesn't compile): .setSkinCoord(((Coordinate)new Coordinate().setContainerFieldOverride("skinCoord")). .setCoord(new Coordinate().setUSE("GrampsSkinCoord")) ------------------------------------------------------------------------------------------------------ Output X3DJSAIL XML (from GraalJS code): Gramps_WS.scaled1.x3d: Gramps_WS.scaled1.x3d: From yottzumm at gmail.com Thu Feb 6 22:11:02 2025 From: yottzumm at gmail.com (John Carlson) Date: Fri, 7 Feb 2025 00:11:02 -0600 Subject: [x3d-public] X3DJSAIL reverses order of skin and skinCoord fields in HAnimHumanoid In-Reply-To: References: Message-ID: Swapping skinCoord and skin field order in my HAnimHumanoid templates solved my issue. I just had to match against both coord (skin IFS) and skinCoord when substituting a point attribute. On Thu, Feb 6, 2025 at 10:11?PM John Carlson wrote: > Summary. Please make sure input XML and output XML order field in > HAnimHumanoid agree in X3DJSAIL. or solve the DEF/USE problem. > > Most obvious, skinCoord and skin become reversed. > > We need to make sure all our tools agree on field order. I will work on > WinterAndSpring (the original source). > > $ java -cp ~/Downloads/X3DJSAIL.4.0.full.jar > org.web3d.x3d.jsail.CommandLine -toXML Gramps8Final.x3d > > Gramps8Final.x3d.out > > Order switched between input XML and output XML: > > $ grep GrampsSkinCoord Gramps8Final.x3d* > Gramps8Final.x3d: DEF="GrampsSkinCoord" containerField="skinCoord" > Gramps8Final.x3d: > > Gramps8Final.x3d.out: > Gramps8Final.x3d.out: containerField='skinCoord'/> > > If you're going to swap the fields, swap the DEF/USE too. > > > ============================================================================================ > Less obvious: > > Original XML: > > Gramps8Final.x3d: DEF="GrampsSkinCoord" containerField="skinCoord" > Gramps8Final.x3d: > > > --------------------------------------------------------------------------------------------- > Translated JSON: > > Gramps8Final.json: > "@DEF":"GrampsSkinCoord", > Gramps8Final.json: > "@USE":"GrampsSkinCoord" > > -------------------------------------------------------------------------------------------------------- > My GraalJS code (derived from JSON): > > .setSkinCoord(new > Coordinate().setContainerFieldOverride("skinCoord").setDEF("Gramps > .setCoord(new Coordinate().setUSE("GrampsSkinCoord")) > > ------------------------------------------------------------------------------------------------- > My Java code (doesn't compile): > > .setSkinCoord(((Coordinate)new > Coordinate().setContainerFieldOverride("skinCoord")). > .setCoord(new Coordinate().setUSE("GrampsSkinCoord")) > > > ------------------------------------------------------------------------------------------------------ > Output X3DJSAIL XML (from GraalJS code): > > Gramps_WS.scaled1.x3d: > Gramps_WS.scaled1.x3d: containerField='skinCoord' point > > This seems to be the problem of DEF/USE in or field order HAnimHumanoid > fields. > > Original too big to attach. See link: > https://coderextreme.net/Gramps8.zip GitHub doesn't like large files. > > John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Fri Feb 7 17:18:24 2025 From: yottzumm at gmail.com (John Carlson) Date: Fri, 7 Feb 2025 19:18:24 -0600 Subject: [x3d-public] Standard Schema for JavaScript/TypeScript validation Message-ID: https://standardschema.dev Maybe it?s worth checking out since there appears to be standard now. If people can review this and approve it, I can start developing a schema to achieve X3D JSON validation. Please let me know what you think. John -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreasplesch at gmail.com Sat Feb 8 03:11:53 2025 From: andreasplesch at gmail.com (Andreas Plesch) Date: Sat, 8 Feb 2025 06:11:53 -0500 Subject: [x3d-public] HAnimDisplacer effect on coord.point Message-ID: https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer does not directly explain what the effect of the displacer on the coord.point field of the containing HAnimSegment is. But it mentions the coord.point field and seems to imply that the coord.point field is involved. So the question is if the Displacer should alter the coord.point field in order to achieve a graphical displacement, or if the Browser should only apply the displacements during rendering without a change in the coord.point field ? This is relevant if the coord.point field is accessed by routes or scripts, in addition to displacers. Thanks for any feedback or ideas, Andreas -- Andreas Plesch Waltham, MA 02453 -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Sat Feb 8 03:20:38 2025 From: yottzumm at gmail.com (John Carlson) Date: Sat, 8 Feb 2025 05:20:38 -0600 Subject: [x3d-public] HAnimDisplacer effect on coord.point In-Reply-To: References: Message-ID: Perhaps there?s more in the HAnim spec? On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public < x3d-public at web3d.org> wrote: > > https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer > > does not directly explain what the effect of the displacer on the > coord.point field of the containing HAnimSegment is. But it mentions the > coord.point field and seems to imply that the coord.point field is involved. > > So the question is if the Displacer should alter the coord.point field in > order to achieve a graphical displacement, or if the Browser should only > apply the displacements during rendering without a change in the > coord.point field ? > > This is relevant if the coord.point field is accessed by routes or > scripts, in addition to displacers. > > Thanks for any feedback or ideas, > > Andreas > > -- > Andreas Plesch > Waltham, MA 02453 > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Sat Feb 8 03:43:30 2025 From: yottzumm at gmail.com (John Carlson) Date: Sat, 8 Feb 2025 05:43:30 -0600 Subject: [x3d-public] HAnimDisplacer effect on coord.point In-Reply-To: References: Message-ID: Here?s what HAnim spec says under Displacer: https://www.web3d.org/documents/specifications/19774/V2.0/index.html ?For the Displacer objects that are contained in the *displacers* field of the Segment objects, the *displacements* are defined and applied in the Segment coordinate system. The base mesh for the morphed Segment is the original mesh defined in the Segment.? And here?s what it says under Segment: ? The *coord* field is used for Segment objects that have deformable meshes and shall contain coordinates referenced from the indexed mesh for the Segment object. The coordinates are given the same name as the Segment object, but with a "_coords" appended (e.g.,"skull_coords").? displacements are an offset from the mesh, with weight from 0 to 1. So weight times displacement is total offset from base mesh. 0 weight = no offset, 1 weight = full displacements offset The Coordinate point is maintained to handle weight = 0. Weight ranges from 0 to 1, but double check. Joe or Carol might know where to find it in the HAnim spec. I believe the answer is, ?during rendering,?. Since weight can vary with animation, and so can displacements, AFAIK. More than one displacer can be applied to the mesh. I have not read the spec. John On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public < x3d-public at web3d.org> wrote: > > https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer > > does not directly explain what the effect of the displacer on the > coord.point field of the containing HAnimSegment is. But it mentions the > coord.point field and seems to imply that the coord.point field is involved. > > So the question is if the Displacer should alter the coord.point field in > order to achieve a graphical displacement, or if the Browser should only > apply the displacements during rendering without a change in the > coord.point field ? > > This is relevant if the coord.point field is accessed by routes or > scripts, in addition to displacers. > > Thanks for any feedback or ideas, > > Andreas > > -- > Andreas Plesch > Waltham, MA 02453 > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joedwil at earthlink.net Sat Feb 8 17:02:12 2025 From: joedwil at earthlink.net (Joe D Williams) Date: Sun, 09 Feb 2025 01:02:12 +0000 Subject: [x3d-public] HAnimDisplacer effect on coord.point in Segments Message-ID: <93ca9735-4d7f-d592-dd0b-63cfbb0855a0@earthlink.net> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer " For the Displacer objects that are contained in the displacers field of the Segment objects, the displacements are defined and applied in the Segment coordinate system. The base mesh for the morphed Segment is the original mesh defined in the Segment. For the Displacer objects that are contained in the displacers field of the Joint objects, the displacements are applied to the deformable mesh specified in the skinCoord field of the Humanoid object. The displacements are defined in the local coordinate system of the Joint object that contains the Displacer. The weighted displacements shall be applied to the skinCoord array in the coordinate system of the Humanoid object. Therefore, the displacements shall be transformed from the Joint object space into the Humanoid object space. The base mesh for the morphed skin is the deformed mesh that results from the bone-based skin deformation. " So, don't need anything extra field for Segment geometry but it seems that limits a Segment to one geometry if displacer is used, although displacer in Segment will probably work with index according to the order the points appear in the coord points field(s) if multiple geometries in Segment. Overall that is the way the skin works. If skin is actually composed of select points of various Segment geometries instead of a single geometry, then the only the points in skinCoord are actually animated, Thanks, Joe -----Original Message----- From: Extensible 3D (X3D) Graphics public discussion Sent: Feb 8, 2025 3:13 AM To: X3D Graphics public mailing list Cc: Andreas Plesch Subject: [x3d-public] HAnimDisplacer effect on coord.point https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer does not directly explain what the effect of the displacer on the coord.point field of the containing HAnimSegment is. But it mentions the coord.point field and seems to imply that the coord.point field is involved. So the question is if the Displacer should alter the coord.point field in order to achieve a graphical displacement, or if the Browser should only apply the displacements during rendering without a change in the coord.point field ? This is relevant if the coord.point field is accessed by routes or scripts, in addition to displacers. Thanks for any feedback or ideas, Andreas -- Andreas Plesch Waltham, MA 02453 -------------- next part -------------- An HTML attachment was scrubbed... URL: From brutzman at nps.edu Sat Feb 8 21:49:53 2025 From: brutzman at nps.edu (Brutzman, Donald (Don) (CIV)) Date: Sun, 9 Feb 2025 05:49:53 +0000 Subject: [x3d-public] HAnimDisplacer effect on coord.point In-Reply-To: References: Message-ID: Thanks for pointing in the right direction John. Direct links to functional requirements for Displacer in HAnim 2.0 specification: * HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, Clause 4 Concepts, 4.7 Displacer object * https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#DisplacerObject * HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, Clause 6 Object interfaces, 6.6 Displacer * https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer and * X3D 4.0 Architecture, Clause 26 Humanoid Animation (HAnim) component, 26.3.1 HAnimDisplacer * https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimDisplacer and informative * X3D Tooltips, HAnimDisplacer * https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimDisplacer Thanks for implementation efforts and careful scrutiny. Questions and potential issues/clarifications/corrections are always welcome. 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 https://faculty.nps.edu/brutzman ________________________________ From: x3d-public on behalf of John Carlson via x3d-public Sent: Saturday, February 8, 2025 3:43 AM To: Extensible 3D (X3D) Graphics public discussion ; Carol McDonald ; Joe D Williams Cc: John Carlson ; Andreas Plesch Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point Here?s what HAnim spec says under Displacer: https://www.web3d.org/documents/specifications/19774/V2.0/index.html ?For the Displacer objects that are contained in the displacers field of the Segment objects, the displacements are defined and applied in the Segment coordinate system. The base mesh for the morphed Segment is the original mesh defined in the Segment.? And here?s what it says under Segment: ? The coord field is used for Segment objects that have deformable meshes and shall contain coordinates referenced from the indexed mesh for the Segment object. The coordinates are given the same name as the Segment object, but with a "_coords" appended (e.g.,"skull_coords").? displacements are an offset from the mesh, with weight from 0 to 1. So weight times displacement is total offset from base mesh. 0 weight = no offset, 1 weight = full displacements offset The Coordinate point is maintained to handle weight = 0. Weight ranges from 0 to 1, but double check. Joe or Carol might know where to find it in the HAnim spec. I believe the answer is, ?during rendering,?. Since weight can vary with animation, and so can displacements, AFAIK. More than one displacer can be applied to the mesh. I have not read the spec. John On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public > wrote: https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer does not directly explain what the effect of the displacer on the coord.point field of the containing HAnimSegment is. But it mentions the coord.point field and seems to imply that the coord.point field is involved. So the question is if the Displacer should alter the coord.point field in order to achieve a graphical displacement, or if the Browser should only apply the displacements during rendering without a change in the coord.point field ? This is relevant if the coord.point field is accessed by routes or scripts, in addition to displacers. Thanks for any feedback or ideas, Andreas -- Andreas Plesch Waltham, MA 02453 _______________________________________________ x3d-public mailing list x3d-public at web3d.org http://web3d.org/mailman/listinfo/x3d-public_web3d.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From joedwil at earthlink.net Sat Feb 8 22:54:03 2025 From: joedwil at earthlink.net (Joe D Williams) Date: Sun, 09 Feb 2025 06:54:03 +0000 Subject: [x3d-public] HAnimDisplacer effect on coord.point Message-ID: <0ed2a614-4f42-fe2c-92f1-036d723d1cc3@earthlink.net> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer this is the clearest reference I know of. Displacers in a Segment use index values for geometry coord points in the order they appear in the Segment even if multiple geometries. No need for added special field. If skin, then the special skinCoords Coordinate points field is used to define the points for the skin Displacer(s). John, the Displacements are added after joint-driven skin animation. If multiple Displacers in Segment(s) or Joint(s), then added in the order of appearance in the user code. Thanks, Joe -----Original Message----- From: Brutzman, Donald (Don) (CIV) Sent: Feb 8, 2025 9:55 PM To: Extensible 3D (X3D) Graphics public discussion , Carol McDonald , Joe D Williams Cc: John Carlson , Andreas Plesch Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point Thanks for pointing in the right direction John. Direct links to functional requirements for Displacer in HAnim 2.0 specification: * HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, Clause 4 Concepts, 4.7 Displacer object * https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#DisplacerObject * HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, Clause 6 Object interfaces, 6.6 Displacer * https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer and * X3D 4.0 Architecture, Clause 26 Humanoid Animation (HAnim) component, 26.3.1 HAnimDisplacer * https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimDisplacer and informative * X3D Tooltips, HAnimDisplacer * https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimDisplacer Thanks for implementation efforts and careful scrutiny. Questions and potential issues/clarifications/corrections are always welcome. 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 https://faculty.nps.edu/brutzman From: x3d-public on behalf of John Carlson via x3d-public Sent: Saturday, February 8, 2025 3:43 AM To: Extensible 3D (X3D) Graphics public discussion ; Carol McDonald ; Joe D Williams Cc: John Carlson ; Andreas Plesch Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point Here’s what HAnim spec says under Displacer: https://www.web3d.org/documents/specifications/19774/V2.0/index.html “For the Displacer objects that are contained in the displacers field of the Segment objects, the displacements are defined and applied in the Segment coordinate system. The base mesh for the morphed Segment is the original mesh defined in the Segment.” And here’s what it says under Segment: “ The coord field is used for Segment objects that have deformable meshes and shall contain coordinates referenced from the indexed mesh for the Segment object. The coordinates are given the same name as the Segment object, but with a "_coords" appended (e.g.,"skull_coords").” displacements are an offset from the mesh, with weight from 0 to 1. So weight times displacement is total offset from base mesh. 0 weight = no offset, 1 weight = full displacements offset The Coordinate point is maintained to handle weight = 0. Weight ranges from 0 to 1, but double check. Joe or Carol might know where to find it in the HAnim spec. I believe the answer is, “during rendering,”. Since weight can vary with animation, and so can displacements, AFAIK. More than one displacer can be applied to the mesh. I have not read the spec. John On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public wrote: https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer does not directly explain what the effect of the displacer on the coord.point field of the containing HAnimSegment is. But it mentions the coord.point field and seems to imply that the coord.point field is involved. So the question is if the Displacer should alter the coord.point field in order to achieve a graphical displacement, or if the Browser should only apply the displacements during rendering without a change in the coord.point field ? This is relevant if the coord.point field is accessed by routes or scripts, in addition to displacers. Thanks for any feedback or ideas, Andreas -- Andreas Plesch Waltham, MA 02453 _______________________________________________ x3d-public mailing list x3d-public at web3d.org (mailto:x3d-public at web3d.org) http://web3d.org/mailman/listinfo/x3d-public_web3d.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Sat Feb 8 23:33:42 2025 From: yottzumm at gmail.com (John Carlson) Date: Sun, 9 Feb 2025 01:33:42 -0600 Subject: [x3d-public] HAnimDisplacer effect on coord.point In-Reply-To: <0ed2a614-4f42-fe2c-92f1-036d723d1cc3@earthlink.net> References: <0ed2a614-4f42-fe2c-92f1-036d723d1cc3@earthlink.net> Message-ID: I believe adding vectors ends up in the same place, no matter the order you put them in. Yes after the Joints. I don?t have any examples with segment displacers that moves joints. On Sun, Feb 9, 2025 at 12:54?AM Joe D Williams wrote: > > https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer > > > > this is the clearest reference I know of. > > Displacers in a Segment use index values for geometry coord points in the > order they appear in the Segment even if multiple geometries. > > No need for added special field. > > > > If skin, then the special skinCoords Coordinate points field is used to > > define the points for the skin Displacer(s). > > > > John, the Displacements are added after joint-driven skin animation. > > If multiple Displacers in Segment(s) or Joint(s), then added in the > > order of appearance in the user code. > > > > > > Thanks, > > Joe > > > > -----Original Message----- > From: Brutzman, Donald (Don) (CIV) > Sent: Feb 8, 2025 9:55 PM > To: Extensible 3D (X3D) Graphics public discussion , > Carol McDonald , Joe D Williams > Cc: John Carlson , Andreas Plesch < > andreasplesch at gmail.com> > Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point > > > Thanks for pointing in the right direction John. > > Direct links to functional requirements for Displacer in HAnim 2.0 > specification: > > - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, > Clause 4 Concepts, 4.7 Displacer object > - > https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#DisplacerObject > > - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, > Clause 6 Object interfaces, 6.6 Displacer > - > https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer > > and > > - X3D 4.0 Architecture, Clause 26 Humanoid Animation (HAnim) > component, 26.3.1 HAnimDisplacer > - > https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimDisplacer > > and informative > > - X3D Tooltips, HAnimDisplacer > - https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimDisplacer > > Thanks for implementation efforts and careful scrutiny. > > Questions and potential issues/clarifications/corrections are always > welcome. > > > 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 > https://faculty.nps.edu/brutzman > > > > ------------------------------ > *From:* x3d-public on behalf of John > Carlson via x3d-public > *Sent:* Saturday, February 8, 2025 3:43 AM > *To:* Extensible 3D (X3D) Graphics public discussion ; > Carol McDonald ; Joe D Williams > *Cc:* John Carlson ; Andreas Plesch < > andreasplesch at gmail.com> > *Subject:* Re: [x3d-public] HAnimDisplacer effect on coord.point > > Here?s what HAnim spec says under Displacer: > > https://www.web3d.org/documents/specifications/19774/V2.0/index.html > > ?For the *Displacer* objects that are contained in the *displacers* field > of the *Segment* objects, the *displacements* are defined and applied in > the *Segment* coordinate system. The base mesh for the morphed *Segment* is > the original mesh defined in the *Segment*.? > > And here?s what it says under Segment: > > ? > > The *coord* field is used for *Segment* objects that have deformable > meshes and shall contain coordinates referenced from the indexed mesh for > the *Segment* object. The coordinates are given the same name as the > *Segment* object, but with a "_coords" appended (e.g.,"skull_coords").? > displacements are an offset from the mesh, with weight from 0 to 1. So > weight times displacement is total offset from base mesh. 0 weight = no > offset, 1 weight = full displacements offset > > The Coordinate point is maintained to handle weight = 0. Weight ranges > from 0 to 1, but double check. > > Joe or Carol might know where to find it in the HAnim spec. > > I believe the answer is, ?during rendering,?. Since weight can vary with > animation, and so can displacements, AFAIK. More than one displacer can be > applied to the mesh. > > I have not read the spec. > > John > > > > On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public < > x3d-public at web3d.org> wrote: > > > https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer > > does not directly explain what the effect of the displacer on the > coord.point field of the containing HAnimSegment is. But it mentions the > coord.point field and seems to imply that the coord.point field is involved. > > So the question is if the Displacer should alter the coord.point field in > order to achieve a graphical displacement, or if the Browser should only > apply the displacements during rendering without a change in the > coord.point field ? > > This is relevant if the coord.point field is accessed by routes or > scripts, in addition to displacers. > > Thanks for any feedback or ideas, > > Andreas > > -- > Andreas Plesch > Waltham, MA 02453 > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreasplesch at gmail.com Sun Feb 9 04:25:04 2025 From: andreasplesch at gmail.com (Andreas Plesch) Date: Sun, 9 Feb 2025 07:25:04 -0500 Subject: [x3d-public] HAnimDisplacer effect on coord.point In-Reply-To: References: Message-ID: Don, Joe and John Thanks for collecting these references. But I am not sure if there is an answer to my original question. Let me rephrase a bit the question: After a Displacer contained in a Segment node receives a set_weight input, should then the coord node emit a point_changed event ? I do not think HAnim is concerned about that, so it is really a X3D question. Thanks, Andreas On Sun, Feb 9, 2025, 12:49?AM Brutzman, Donald (Don) (CIV) wrote: > Thanks for pointing in the right direction John. > > Direct links to functional requirements for Displacer in HAnim 2.0 > specification: > > - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, > Clause 4 Concepts, 4.7 Displacer object > - > https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#DisplacerObject > > - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, > Clause 6 Object interfaces, 6.6 Displacer > - > https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer > > and > > - X3D 4.0 Architecture, Clause 26 Humanoid Animation (HAnim) > component, 26.3.1 HAnimDisplacer > - > https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimDisplacer > > and informative > > - X3D Tooltips, HAnimDisplacer > - https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimDisplacer > > Thanks for implementation efforts and careful scrutiny. > > Questions and potential issues/clarifications/corrections are always > welcome. > > > 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 > https://faculty.nps.edu/brutzman > > > > ------------------------------ > *From:* x3d-public on behalf of John > Carlson via x3d-public > *Sent:* Saturday, February 8, 2025 3:43 AM > *To:* Extensible 3D (X3D) Graphics public discussion ; > Carol McDonald ; Joe D Williams > *Cc:* John Carlson ; Andreas Plesch < > andreasplesch at gmail.com> > *Subject:* Re: [x3d-public] HAnimDisplacer effect on coord.point > > Here?s what HAnim spec says under Displacer: > > https://www.web3d.org/documents/specifications/19774/V2.0/index.html > > ?For the *Displacer* objects that are contained in the *displacers* field > of the *Segment* objects, the *displacements* are defined and applied in > the *Segment* coordinate system. The base mesh for the morphed *Segment* is > the original mesh defined in the *Segment*.? > > And here?s what it says under Segment: > > ? > > The *coord* field is used for *Segment* objects that have deformable > meshes and shall contain coordinates referenced from the indexed mesh for > the *Segment* object. The coordinates are given the same name as the > *Segment* object, but with a "_coords" appended (e.g.,"skull_coords").? > displacements are an offset from the mesh, with weight from 0 to 1. So > weight times displacement is total offset from base mesh. 0 weight = no > offset, 1 weight = full displacements offset > > The Coordinate point is maintained to handle weight = 0. Weight ranges > from 0 to 1, but double check. > > Joe or Carol might know where to find it in the HAnim spec. > > I believe the answer is, ?during rendering,?. Since weight can vary with > animation, and so can displacements, AFAIK. More than one displacer can be > applied to the mesh. > > I have not read the spec. > > John > > > > On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public < > x3d-public at web3d.org> wrote: > > > https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer > > does not directly explain what the effect of the displacer on the > coord.point field of the containing HAnimSegment is. But it mentions the > coord.point field and seems to imply that the coord.point field is involved. > > So the question is if the Displacer should alter the coord.point field in > order to achieve a graphical displacement, or if the Browser should only > apply the displacements during rendering without a change in the > coord.point field ? > > This is relevant if the coord.point field is accessed by routes or > scripts, in addition to displacers. > > Thanks for any feedback or ideas, > > Andreas > > -- > Andreas Plesch > Waltham, MA 02453 > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Sun Feb 9 06:27:07 2025 From: yottzumm at gmail.com (John Carlson) Date: Sun, 9 Feb 2025 08:27:07 -0600 Subject: [x3d-public] HAnimDisplacer effect on coord.point In-Reply-To: References: Message-ID: I tried to answer that I don?t think the point is actually changed. It?s the weight that changes, and the final mesh. I realize the desire to have a final point value visible in the debugger, but I don?t like the backward math to recompute the point, if the weight changes. But yeah, if you want to add the math to compute the final mesh point from a previous final mesh point, each time, go for it. I would batch all the changes into a single event per mesh. I also realize a mesh uses a lot of space, and there?s a desire to optimize space. That?s my best guess. So yes, probably there?s a lot of multiplication and adding done during rendering each frame. Unless you can figure out how to restore the original point values when changing weights. It might be possible, but it sounds possibly more expensive than the above. I prefer simple straightforward solutions to complicated ones, realizing there?s a debugging need, and HTML provides that. I realize one needs to compute the final onscreen point each time, and it?s valuable to retain the final point for debugging. I don?t need an event if the point changes. Maybe we should wait for a use case? How many events would I get if a point changes? Is there any harm in assuming that no event is generated? Does something else need the event? Is there any harm generating the event? Can people listen for when the weight changes? I think more browser vendors should weigh in. Frankly, I?m on the fence, and I don?t have a use case. What did we do for Joint displacers? There shouldn?t be surprises. John On Sun, Feb 9, 2025 at 6:25?AM Andreas Plesch wrote: > Don, Joe and John > > Thanks for collecting these references. > > But I am not sure if there is an answer to my original question. Let me > rephrase a bit the question: > > After a Displacer contained in a Segment node receives a set_weight input, > should then the coord node emit a point_changed event ? > > I do not think HAnim is concerned about that, so it is really a X3D > question. > > Thanks, Andreas > > On Sun, Feb 9, 2025, 12:49?AM Brutzman, Donald (Don) (CIV) < > brutzman at nps.edu> wrote: > >> Thanks for pointing in the right direction John. >> >> Direct links to functional requirements for Displacer in HAnim 2.0 >> specification: >> >> - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, >> Clause 4 Concepts, 4.7 Displacer object >> - >> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#DisplacerObject >> >> - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, >> Clause 6 Object interfaces, 6.6 Displacer >> - >> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer >> >> and >> >> - X3D 4.0 Architecture, Clause 26 Humanoid Animation (HAnim) >> component, 26.3.1 HAnimDisplacer >> - >> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimDisplacer >> >> and informative >> >> - X3D Tooltips, HAnimDisplacer >> - https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimDisplacer >> >> Thanks for implementation efforts and careful scrutiny. >> >> Questions and potential issues/clarifications/corrections are always >> welcome. >> >> >> 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 >> https://faculty.nps.edu/brutzman >> >> >> >> ------------------------------ >> *From:* x3d-public on behalf of John >> Carlson via x3d-public >> *Sent:* Saturday, February 8, 2025 3:43 AM >> *To:* Extensible 3D (X3D) Graphics public discussion < >> x3d-public at web3d.org>; Carol McDonald ; Joe D >> Williams >> *Cc:* John Carlson ; Andreas Plesch < >> andreasplesch at gmail.com> >> *Subject:* Re: [x3d-public] HAnimDisplacer effect on coord.point >> >> Here?s what HAnim spec says under Displacer: >> >> https://www.web3d.org/documents/specifications/19774/V2.0/index.html >> >> ?For the *Displacer* objects that are contained in the *displacers* field >> of the *Segment* objects, the *displacements* are defined and applied in >> the *Segment* coordinate system. The base mesh for the morphed *Segment* is >> the original mesh defined in the *Segment*.? >> >> And here?s what it says under Segment: >> >> ? >> >> The *coord* field is used for *Segment* objects that have deformable >> meshes and shall contain coordinates referenced from the indexed mesh for >> the *Segment* object. The coordinates are given the same name as the >> *Segment* object, but with a "_coords" appended (e.g.,"skull_coords").? >> displacements are an offset from the mesh, with weight from 0 to 1. So >> weight times displacement is total offset from base mesh. 0 weight = no >> offset, 1 weight = full displacements offset >> >> The Coordinate point is maintained to handle weight = 0. Weight ranges >> from 0 to 1, but double check. >> >> Joe or Carol might know where to find it in the HAnim spec. >> >> I believe the answer is, ?during rendering,?. Since weight can vary with >> animation, and so can displacements, AFAIK. More than one displacer can be >> applied to the mesh. >> >> I have not read the spec. >> >> John >> >> >> >> On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public < >> x3d-public at web3d.org> wrote: >> >> >> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer >> >> does not directly explain what the effect of the displacer on the >> coord.point field of the containing HAnimSegment is. But it mentions the >> coord.point field and seems to imply that the coord.point field is involved. >> >> So the question is if the Displacer should alter the coord.point field in >> order to achieve a graphical displacement, or if the Browser should only >> apply the displacements during rendering without a change in the >> coord.point field ? >> >> This is relevant if the coord.point field is accessed by routes or >> scripts, in addition to displacers. >> >> Thanks for any feedback or ideas, >> >> Andreas >> >> -- >> Andreas Plesch >> Waltham, MA 02453 >> _______________________________________________ >> x3d-public mailing list >> x3d-public at web3d.org >> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreasplesch at gmail.com Sun Feb 9 08:35:16 2025 From: andreasplesch at gmail.com (Andreas Plesch) Date: Sun, 9 Feb 2025 11:35:16 -0500 Subject: [x3d-public] HAnimDisplacer effect on coord.point In-Reply-To: References: Message-ID: Good points. The tension is that a Displacer manipulates the points from the coord.point field on the one hand but may not affect the value of the coord.point field on the other hand. This tension may not have to be resolved and left open to browser interpretation and preference. A use case could be a script which wants to use the actual vertex positions of a displaced Segment geometry to further distort the geometry. An implementation of Displacer may consist of an internal route from the weighted displacements added to the resting coordinates to the coord.point field of the parent node(s). -Andreas On Sun, Feb 9, 2025, 9:27?AM John Carlson wrote: > I tried to answer that I don?t think the point is actually changed. It?s > the weight that changes, and the final mesh. I realize the desire to have > a final point value visible in the debugger, but I don?t like the backward > math to recompute the point, if the weight changes. But yeah, if you want > to add the math to compute the final mesh point from a previous final mesh > point, each time, go for it. I would batch all the changes into a single > event per mesh. I also realize a mesh uses a lot of space, and there?s a > desire to optimize space. > > That?s my best guess. > > So yes, probably there?s a lot of multiplication and adding done during > rendering each frame. > > Unless you can figure out how to restore the original point values when > changing weights. It might be possible, but it sounds possibly more > expensive than the above. I prefer simple straightforward solutions to > complicated ones, realizing there?s a debugging need, and HTML provides > that. > > I realize one needs to compute the final onscreen point each time, and > it?s valuable to retain the final point for debugging. > > I don?t need an event if the point changes. Maybe we should wait for a > use case? How many events would I get if a point changes? > > Is there any harm in assuming that no event is generated? Does something > else need the event? Is there any harm generating the event? Can people > listen for when the weight changes? > > I think more browser vendors should weigh in. Frankly, I?m on the fence, > and I don?t have a use case. What did we do for Joint displacers? > There shouldn?t be surprises. > > John > > On Sun, Feb 9, 2025 at 6:25?AM Andreas Plesch > wrote: > >> Don, Joe and John >> >> Thanks for collecting these references. >> >> But I am not sure if there is an answer to my original question. Let me >> rephrase a bit the question: >> >> After a Displacer contained in a Segment node receives a set_weight >> input, should then the coord node emit a point_changed event ? >> >> I do not think HAnim is concerned about that, so it is really a X3D >> question. >> >> Thanks, Andreas >> >> On Sun, Feb 9, 2025, 12:49?AM Brutzman, Donald (Don) (CIV) < >> brutzman at nps.edu> wrote: >> >>> Thanks for pointing in the right direction John. >>> >>> Direct links to functional requirements for Displacer in HAnim 2.0 >>> specification: >>> >>> - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, >>> Clause 4 Concepts, 4.7 Displacer object >>> - >>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#DisplacerObject >>> >>> - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, >>> Clause 6 Object interfaces, 6.6 Displacer >>> - >>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer >>> >>> and >>> >>> - X3D 4.0 Architecture, Clause 26 Humanoid Animation (HAnim) >>> component, 26.3.1 HAnimDisplacer >>> - >>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimDisplacer >>> >>> and informative >>> >>> - X3D Tooltips, HAnimDisplacer >>> - https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimDisplacer >>> >>> Thanks for implementation efforts and careful scrutiny. >>> >>> Questions and potential issues/clarifications/corrections are always >>> welcome. >>> >>> >>> 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 >>> https://faculty.nps.edu/brutzman >>> >>> >>> >>> ------------------------------ >>> *From:* x3d-public on behalf of John >>> Carlson via x3d-public >>> *Sent:* Saturday, February 8, 2025 3:43 AM >>> *To:* Extensible 3D (X3D) Graphics public discussion < >>> x3d-public at web3d.org>; Carol McDonald ; Joe D >>> Williams >>> *Cc:* John Carlson ; Andreas Plesch < >>> andreasplesch at gmail.com> >>> *Subject:* Re: [x3d-public] HAnimDisplacer effect on coord.point >>> >>> Here?s what HAnim spec says under Displacer: >>> >>> https://www.web3d.org/documents/specifications/19774/V2.0/index.html >>> >>> ?For the *Displacer* objects that are contained in the *displacers* field >>> of the *Segment* objects, the *displacements* are defined and applied >>> in the *Segment* coordinate system. The base mesh for the morphed >>> *Segment* is the original mesh defined in the *Segment*.? >>> >>> And here?s what it says under Segment: >>> >>> ? >>> >>> The *coord* field is used for *Segment* objects that have deformable >>> meshes and shall contain coordinates referenced from the indexed mesh for >>> the *Segment* object. The coordinates are given the same name as the >>> *Segment* object, but with a "_coords" appended (e.g.,"skull_coords").? >>> displacements are an offset from the mesh, with weight from 0 to 1. So >>> weight times displacement is total offset from base mesh. 0 weight = no >>> offset, 1 weight = full displacements offset >>> >>> The Coordinate point is maintained to handle weight = 0. Weight ranges >>> from 0 to 1, but double check. >>> >>> Joe or Carol might know where to find it in the HAnim spec. >>> >>> I believe the answer is, ?during rendering,?. Since weight can vary with >>> animation, and so can displacements, AFAIK. More than one displacer can be >>> applied to the mesh. >>> >>> I have not read the spec. >>> >>> John >>> >>> >>> >>> On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public < >>> x3d-public at web3d.org> wrote: >>> >>> >>> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer >>> >>> does not directly explain what the effect of the displacer on the >>> coord.point field of the containing HAnimSegment is. But it mentions the >>> coord.point field and seems to imply that the coord.point field is involved. >>> >>> So the question is if the Displacer should alter the coord.point field >>> in order to achieve a graphical displacement, or if the Browser should only >>> apply the displacements during rendering without a change in the >>> coord.point field ? >>> >>> This is relevant if the coord.point field is accessed by routes or >>> scripts, in addition to displacers. >>> >>> Thanks for any feedback or ideas, >>> >>> Andreas >>> >>> -- >>> Andreas Plesch >>> Waltham, MA 02453 >>> _______________________________________________ >>> x3d-public mailing list >>> x3d-public at web3d.org >>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From joedwil at earthlink.net Sun Feb 9 09:21:59 2025 From: joedwil at earthlink.net (Joe D Williams) Date: Sun, 09 Feb 2025 17:21:59 +0000 Subject: [x3d-public] HAnimDisplacer effect on coord.point Message-ID: > Unless you can figure out how to restore the original point values when changing weight Doesn't the inverse bind matrix give you original values? After joint-weighted animations are done then the displacer-weighted value is added. Joe -----Original Message----- From: Andreas Plesch Sent: Feb 9, 2025 8:35 AM To: John Carlson Cc: Brutzman, Donald (Don) (CIV) , Extensible 3D (X3D) Graphics public discussion , Carol McDonald , Joe D Williams , Holger Seelig , GPU Group Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point Good points. The tension is that a Displacer manipulates the points from the coord.point field on the one hand but may not affect the value of the coord.point field on the other hand. This tension may not have to be resolved and left open to browser interpretation and preference. A use case could be a script which wants to use the actual vertex positions of a displaced Segment geometry to further distort the geometry. An implementation of Displacer may consist of an internal route from the weighted displacements added to the resting coordinates to the coord.point field of the parent node(s). -Andreas On Sun, Feb 9, 2025, 9:27?AM John Carlson wrote: I tried to answer that I don’t think the point is actually changed. It’s the weight that changes, and the final mesh. I realize the desire to have a final point value visible in the debugger, but I don’t like the backward math to recompute the point, if the weight changes. But yeah, if you want to add the math to compute the final mesh point from a previous final mesh point, each time, go for it. I would batch all the changes into a single event per mesh. I also realize a mesh uses a lot of space, and there’s a desire to optimize space. That’s my best guess. So yes, probably there’s a lot of multiplication and adding done during rendering each frame. Unless you can figure out how to restore the original point values when changing weights. It might be possible, but it sounds possibly more expensive than the above. I prefer simple straightforward solutions to complicated ones, realizing there’s a debugging need, and HTML provides that. I realize one needs to compute the final onscreen point each time, and it’s valuable to retain the final point for debugging. I don’t need an event if the point changes. Maybe we should wait for a use case? How many events would I get if a point changes? Is there any harm in assuming that no event is generated? Does something else need the event? Is there any harm generating the event? Can people listen for when the weight changes? I think more browser vendors should weigh in. Frankly, I’m on the fence, and I don’t have a use case. What did we do for Joint displacers? There shouldn’t be surprises. John On Sun, Feb 9, 2025 at 6:25?AM Andreas Plesch wrote: Don, Joe and John Thanks for collecting these references. But I am not sure if there is an answer to my original question. Let me rephrase a bit the question: After a Displacer contained in a Segment node receives a set_weight input, should then the coord node emit a point_changed event ? I do not think HAnim is concerned about that, so it is really a X3D question. Thanks, Andreas On Sun, Feb 9, 2025, 12:49?AM Brutzman, Donald (Don) (CIV) wrote: Thanks for pointing in the right direction John. Direct links to functional requirements for Displacer in HAnim 2.0 specification: * HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, Clause 4 Concepts, 4.7 Displacer object * https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#DisplacerObject * HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, Clause 6 Object interfaces, 6.6 Displacer * https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer and * X3D 4.0 Architecture, Clause 26 Humanoid Animation (HAnim) component, 26.3.1 HAnimDisplacer * https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimDisplacer and informative * X3D Tooltips, HAnimDisplacer * https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimDisplacer Thanks for implementation efforts and careful scrutiny. Questions and potential issues/clarifications/corrections are always welcome. all the best, Don -- Don Brutzman Naval Postgraduate School, Code USW/Br brutzman at nps.edu (mailto:brutzman at nps.edu) Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149 X3D graphics, virtual worlds, navy robotics https://faculty.nps.edu/brutzman From: x3d-public on behalf of John Carlson via x3d-public Sent: Saturday, February 8, 2025 3:43 AM To: Extensible 3D (X3D) Graphics public discussion ; Carol McDonald ; Joe D Williams Cc: John Carlson ; Andreas Plesch Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point Here’s what HAnim spec says under Displacer: https://www.web3d.org/documents/specifications/19774/V2.0/index.html “For the Displacer objects that are contained in the displacers field of the Segment objects, the displacements are defined and applied in the Segment coordinate system. The base mesh for the morphed Segment is the original mesh defined in the Segment.” And here’s what it says under Segment: “ The coord field is used for Segment objects that have deformable meshes and shall contain coordinates referenced from the indexed mesh for the Segment object. The coordinates are given the same name as the Segment object, but with a "_coords" appended (e.g.,"skull_coords").” displacements are an offset from the mesh, with weight from 0 to 1. So weight times displacement is total offset from base mesh. 0 weight = no offset, 1 weight = full displacements offset The Coordinate point is maintained to handle weight = 0. Weight ranges from 0 to 1, but double check. Joe or Carol might know where to find it in the HAnim spec. I believe the answer is, “during rendering,”. Since weight can vary with animation, and so can displacements, AFAIK. More than one displacer can be applied to the mesh. I have not read the spec. John On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public wrote: https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer does not directly explain what the effect of the displacer on the coord.point field of the containing HAnimSegment is. But it mentions the coord.point field and seems to imply that the coord.point field is involved. So the question is if the Displacer should alter the coord.point field in order to achieve a graphical displacement, or if the Browser should only apply the displacements during rendering without a change in the coord.point field ? This is relevant if the coord.point field is accessed by routes or scripts, in addition to displacers. Thanks for any feedback or ideas, Andreas -- Andreas Plesch Waltham, MA 02453 _______________________________________________ x3d-public mailing list x3d-public at web3d.org (mailto:x3d-public at web3d.org) http://web3d.org/mailman/listinfo/x3d-public_web3d.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From joedwil at earthlink.net Sun Feb 9 09:36:03 2025 From: joedwil at earthlink.net (Joe D Williams) Date: Sun, 09 Feb 2025 17:36:03 +0000 Subject: [x3d-public] HAnimDisplacer effect on coord.point Message-ID: <4cddd35a-705f-e6fa-742d-1e2e7f6551d7@earthlink.net> > coord node emit a point_changed event sorry,I don't see a field anywhere with that event. Displacer is likely to change several points when new weight is sent. All part of the cascade to produce the changed mesh? Thanks, Joe -----Original Message----- From: Andreas Plesch Sent: Feb 9, 2025 4:25 AM To: Brutzman, Donald (Don) (CIV) Cc: Extensible 3D (X3D) Graphics public discussion , Carol McDonald , Joe D Williams , John Carlson Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point Don, Joe and John Thanks for collecting these references. But I am not sure if there is an answer to my original question. Let me rephrase a bit the question: After a Displacer contained in a Segment node receives a set_weight input, should then the coord node emit a point_changed event ? I do not think HAnim is concerned about that, so it is really a X3D question. Thanks, Andreas On Sun, Feb 9, 2025, 12:49?AM Brutzman, Donald (Don) (CIV) wrote: Thanks for pointing in the right direction John. Direct links to functional requirements for Displacer in HAnim 2.0 specification: * HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, Clause 4 Concepts, 4.7 Displacer object * https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#DisplacerObject * HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, Clause 6 Object interfaces, 6.6 Displacer * https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer and * X3D 4.0 Architecture, Clause 26 Humanoid Animation (HAnim) component, 26.3.1 HAnimDisplacer * https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimDisplacer and informative * X3D Tooltips, HAnimDisplacer * https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimDisplacer Thanks for implementation efforts and careful scrutiny. Questions and potential issues/clarifications/corrections are always welcome. all the best, Don -- Don Brutzman Naval Postgraduate School, Code USW/Br brutzman at nps.edu (mailto:brutzman at nps.edu) Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149 X3D graphics, virtual worlds, navy robotics https://faculty.nps.edu/brutzman From: x3d-public on behalf of John Carlson via x3d-public Sent: Saturday, February 8, 2025 3:43 AM To: Extensible 3D (X3D) Graphics public discussion ; Carol McDonald ; Joe D Williams Cc: John Carlson ; Andreas Plesch Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point Here’s what HAnim spec says under Displacer: https://www.web3d.org/documents/specifications/19774/V2.0/index.html “For the Displacer objects that are contained in the displacers field of the Segment objects, the displacements are defined and applied in the Segment coordinate system. The base mesh for the morphed Segment is the original mesh defined in the Segment.” And here’s what it says under Segment: “ The coord field is used for Segment objects that have deformable meshes and shall contain coordinates referenced from the indexed mesh for the Segment object. The coordinates are given the same name as the Segment object, but with a "_coords" appended (e.g.,"skull_coords").” displacements are an offset from the mesh, with weight from 0 to 1. So weight times displacement is total offset from base mesh. 0 weight = no offset, 1 weight = full displacements offset The Coordinate point is maintained to handle weight = 0. Weight ranges from 0 to 1, but double check. Joe or Carol might know where to find it in the HAnim spec. I believe the answer is, “during rendering,”. Since weight can vary with animation, and so can displacements, AFAIK. More than one displacer can be applied to the mesh. I have not read the spec. John On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public wrote: https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer does not directly explain what the effect of the displacer on the coord.point field of the containing HAnimSegment is. But it mentions the coord.point field and seems to imply that the coord.point field is involved. So the question is if the Displacer should alter the coord.point field in order to achieve a graphical displacement, or if the Browser should only apply the displacements during rendering without a change in the coord.point field ? This is relevant if the coord.point field is accessed by routes or scripts, in addition to displacers. Thanks for any feedback or ideas, Andreas -- Andreas Plesch Waltham, MA 02453 _______________________________________________ x3d-public mailing list x3d-public at web3d.org (mailto:x3d-public at web3d.org) http://web3d.org/mailman/listinfo/x3d-public_web3d.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreasplesch at gmail.com Sun Feb 9 10:33:35 2025 From: andreasplesch at gmail.com (Andreas Plesch) Date: Sun, 9 Feb 2025 13:33:35 -0500 Subject: [x3d-public] HAnimDisplacer effect on coord.point In-Reply-To: <4cddd35a-705f-e6fa-742d-1e2e7f6551d7@earthlink.net> References: <4cddd35a-705f-e6fa-742d-1e2e7f6551d7@earthlink.net> Message-ID: That would be the point field of a Coordinate node https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/rendering.html#Coordinate which is used by the coord field of https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimSegment Andreas On Sun, Feb 9, 2025, 12:36?PM Joe D Williams wrote: > > coord node emit a point_changed event > > > > sorry,I don't see a field anywhere with that event. Displacer is likely to > change several points when new weight is sent. All part of the cascade to > produce the changed mesh? > > Thanks, > > Joe > > > > > > -----Original Message----- > From: Andreas Plesch > Sent: Feb 9, 2025 4:25 AM > To: Brutzman, Donald (Don) (CIV) > Cc: Extensible 3D (X3D) Graphics public discussion , > Carol McDonald , Joe D Williams , > John Carlson > Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point > > > Don, Joe and John > > Thanks for collecting these references. > > But I am not sure if there is an answer to my original question. Let me > rephrase a bit the question: > > After a Displacer contained in a Segment node receives a set_weight input, > should then the coord node emit a point_changed event ? > > I do not think HAnim is concerned about that, so it is really a X3D > question. > > Thanks, Andreas > > On Sun, Feb 9, 2025, 12:49?AM Brutzman, Donald (Don) (CIV) < > brutzman at nps.edu> wrote: > >> Thanks for pointing in the right direction John. >> >> Direct links to functional requirements for Displacer in HAnim 2.0 >> specification: >> >> - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, >> Clause 4 Concepts, 4.7 Displacer object >> - >> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#DisplacerObject >> >> - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, >> Clause 6 Object interfaces, 6.6 Displacer >> - >> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer >> >> and >> >> - X3D 4.0 Architecture, Clause 26 Humanoid Animation (HAnim) >> component, 26.3.1 HAnimDisplacer >> - >> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimDisplacer >> >> and informative >> >> - X3D Tooltips, HAnimDisplacer >> - https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimDisplacer >> >> Thanks for implementation efforts and careful scrutiny. >> >> Questions and potential issues/clarifications/corrections are always >> welcome. >> >> >> 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 >> https://faculty.nps.edu/brutzman >> >> >> >> ------------------------------ >> *From:* x3d-public on behalf of John >> Carlson via x3d-public >> *Sent:* Saturday, February 8, 2025 3:43 AM >> *To:* Extensible 3D (X3D) Graphics public discussion < >> x3d-public at web3d.org>; Carol McDonald ; Joe D >> Williams >> *Cc:* John Carlson ; Andreas Plesch < >> andreasplesch at gmail.com> >> *Subject:* Re: [x3d-public] HAnimDisplacer effect on coord.point >> >> Here?s what HAnim spec says under Displacer: >> >> https://www.web3d.org/documents/specifications/19774/V2.0/index.html >> >> ?For the *Displacer* objects that are contained in the *displacers* field >> of the *Segment* objects, the *displacements* are defined and applied in >> the *Segment* coordinate system. The base mesh for the morphed *Segment* is >> the original mesh defined in the *Segment*.? >> >> And here?s what it says under Segment: >> >> ? >> >> The *coord* field is used for *Segment* objects that have deformable >> meshes and shall contain coordinates referenced from the indexed mesh for >> the *Segment* object. The coordinates are given the same name as the >> *Segment* object, but with a "_coords" appended (e.g.,"skull_coords").? >> displacements are an offset from the mesh, with weight from 0 to 1. So >> weight times displacement is total offset from base mesh. 0 weight = no >> offset, 1 weight = full displacements offset >> >> The Coordinate point is maintained to handle weight = 0. Weight ranges >> from 0 to 1, but double check. >> >> Joe or Carol might know where to find it in the HAnim spec. >> >> I believe the answer is, ?during rendering,?. Since weight can vary with >> animation, and so can displacements, AFAIK. More than one displacer can be >> applied to the mesh. >> >> I have not read the spec. >> >> John >> >> >> >> On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public < >> x3d-public at web3d.org> wrote: >> >> >> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer >> >> does not directly explain what the effect of the displacer on the >> coord.point field of the containing HAnimSegment is. But it mentions the >> coord.point field and seems to imply that the coord.point field is involved. >> >> So the question is if the Displacer should alter the coord.point field in >> order to achieve a graphical displacement, or if the Browser should only >> apply the displacements during rendering without a change in the >> coord.point field ? >> >> This is relevant if the coord.point field is accessed by routes or >> scripts, in addition to displacers. >> >> Thanks for any feedback or ideas, >> >> Andreas >> >> -- >> Andreas Plesch >> Waltham, MA 02453 >> _______________________________________________ >> x3d-public mailing list >> x3d-public at web3d.org >> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger.seelig at yahoo.de Sun Feb 9 10:40:08 2025 From: holger.seelig at yahoo.de (Holger Seelig) Date: Sun, 9 Feb 2025 19:40:08 +0100 Subject: [x3d-public] HAnimDisplacer effect on coord.point In-Reply-To: References: <4cddd35a-705f-e6fa-742d-1e2e7f6551d7@earthlink.net> Message-ID: <4492C6F2-861C-4468-AEBF-BAEAB5EE6EDA@yahoo.de> X_ITE applies the HAnimDisplacers in the shader, thus no coord.point field has to be changed. Maybe that helps. Best regards, Holger -- Holger Seelig Leipzig, Germany holger.seelig at yahoo.de https://create3000.github.io/x_ite/ > Am 09.02.2025 um 19:33 schrieb Andreas Plesch via x3d-public : > > That would be the point field of a Coordinate node > > https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/rendering.html#Coordinate > > which is used by the coord field of > > https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimSegment > > Andreas > > On Sun, Feb 9, 2025, 12:36?PM Joe D Williams > wrote: >> > coord node emit a point_changed event >> >> sorry,I don't see a field anywhere with that event. Displacer is likely to change several points when new weight is sent. All part of the cascade to produce the changed mesh? >> Thanks, >> Joe >> >> >> -----Original Message----- >> From: Andreas Plesch > >> Sent: Feb 9, 2025 4:25 AM >> To: Brutzman, Donald (Don) (CIV) > >> Cc: Extensible 3D (X3D) Graphics public discussion >, Carol McDonald >, Joe D Williams >, John Carlson > >> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >> >> >> Don, Joe and John >> >> Thanks for collecting these references. >> >> But I am not sure if there is an answer to my original question. Let me rephrase a bit the question: >> >> After a Displacer contained in a Segment node receives a set_weight input, should then the coord node emit a point_changed event ? >> >> I do not think HAnim is concerned about that, so it is really a X3D question. >> >> Thanks, Andreas >> >> On Sun, Feb 9, 2025, 12:49?AM Brutzman, Donald (Don) (CIV) > wrote: >>> Thanks for pointing in the right direction John. >>> >>> Direct links to functional requirements for Displacer in HAnim 2.0 specification: >>> HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, Clause 4 Concepts, 4.7 Displacer object >>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#DisplacerObject >>> >>> HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, Clause 6 Object interfaces, 6.6 Displacer >>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer >>> and >>> X3D 4.0 Architecture, Clause 26 Humanoid Animation (HAnim) component, 26.3.1 HAnimDisplacer >>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimDisplacer >>> and informative >>> X3D Tooltips, HAnimDisplacer >>> https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimDisplacer >>> Thanks for implementation efforts and careful scrutiny. >>> >>> Questions and potential issues/clarifications/corrections are always welcome. >>> >>> >>> 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 https://faculty.nps.edu/brutzman >>> >>> >>> From: x3d-public > on behalf of John Carlson via x3d-public > >>> Sent: Saturday, February 8, 2025 3:43 AM >>> To: Extensible 3D (X3D) Graphics public discussion >; Carol McDonald >; Joe D Williams > >>> Cc: John Carlson >; Andreas Plesch > >>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>> >>> Here?s what HAnim spec says under Displacer: >>> >>> https://www.web3d.org/documents/specifications/19774/V2.0/index.html >>> >>> ?For the Displacer objects that are contained in the displacers field of the Segment objects, the displacements are defined and applied in the Segment coordinate system. The base mesh for the morphed Segment is the original mesh defined in the Segment.? >>> >>> And here?s what it says under Segment: >>> >>> ? >>> The coord field is used for Segment objects that have deformable meshes and shall contain coordinates referenced from the indexed mesh for the Segment object. The coordinates are given the same name as the Segment object, but with a "_coords" appended (e.g.,"skull_coords").? >>> >>> displacements are an offset from the mesh, with weight from 0 to 1. So weight times displacement is total offset from base mesh. 0 weight = no offset, 1 weight = full displacements offset >>> >>> The Coordinate point is maintained to handle weight = 0. Weight ranges from 0 to 1, but double check. >>> >>> Joe or Carol might know where to find it in the HAnim spec. >>> >>> I believe the answer is, ?during rendering,?. Since weight can vary with animation, and so can displacements, AFAIK. More than one displacer can be applied to the mesh. >>> >>> I have not read the spec. >>> >>> John >>> >>> >>> >>> On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public > wrote: >>> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer >>> >>> does not directly explain what the effect of the displacer on the coord.point field of the containing HAnimSegment is. But it mentions the coord.point field and seems to imply that the coord.point field is involved. >>> >>> So the question is if the Displacer should alter the coord.point field in order to achieve a graphical displacement, or if the Browser should only apply the displacements during rendering without a change in the coord.point field ? >>> >>> This is relevant if the coord.point field is accessed by routes or scripts, in addition to displacers. >>> >>> Thanks for any feedback or ideas, >>> >>> Andreas >>> >>> -- >>> Andreas Plesch >>> Waltham, MA 02453 >>> _______________________________________________ >>> x3d-public mailing list >>> x3d-public at web3d.org >>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >> >> > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreasplesch at gmail.com Sun Feb 9 10:44:41 2025 From: andreasplesch at gmail.com (Andreas Plesch) Date: Sun, 9 Feb 2025 13:44:41 -0500 Subject: [x3d-public] HAnimDisplacer effect on coord.point In-Reply-To: <4492C6F2-861C-4468-AEBF-BAEAB5EE6EDA@yahoo.de> References: <4cddd35a-705f-e6fa-742d-1e2e7f6551d7@earthlink.net> <4492C6F2-861C-4468-AEBF-BAEAB5EE6EDA@yahoo.de> Message-ID: Yes, that is an option. However, the question is if it should be changed so it is available for other purposes. Andreas On Sun, Feb 9, 2025, 1:40?PM Holger Seelig wrote: > X_ITE applies the HAnimDisplacers in the shader, thus no coord.point field > has to be changed. > Maybe that helps. > > Best regards, > Holger > > -- > Holger Seelig > Leipzig, Germany > > holger.seelig at yahoo.de > https://create3000.github.io/x_ite/ > > Am 09.02.2025 um 19:33 schrieb Andreas Plesch via x3d-public < > x3d-public at web3d.org>: > > That would be the point field of a Coordinate node > > > https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/rendering.html#Coordinate > > which is used by the coord field of > > > https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimSegment > > Andreas > > On Sun, Feb 9, 2025, 12:36?PM Joe D Williams > wrote: > >> > coord node emit a point_changed event >> >> >> sorry,I don't see a field anywhere with that event. Displacer is likely >> to change several points when new weight is sent. All part of the cascade >> to produce the changed mesh? >> Thanks, >> Joe >> >> >> >> >> >> -----Original Message----- >> From: Andreas Plesch >> Sent: Feb 9, 2025 4:25 AM >> To: Brutzman, Donald (Don) (CIV) >> Cc: Extensible 3D (X3D) Graphics public discussion , >> Carol McDonald , Joe D Williams , >> John Carlson >> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >> >> >> Don, Joe and John >> >> Thanks for collecting these references. >> >> But I am not sure if there is an answer to my original question. Let me >> rephrase a bit the question: >> >> After a Displacer contained in a Segment node receives a set_weight >> input, should then the coord node emit a point_changed event ? >> >> I do not think HAnim is concerned about that, so it is really a X3D >> question. >> >> Thanks, Andreas >> >> On Sun, Feb 9, 2025, 12:49?AM Brutzman, Donald (Don) (CIV) < >> brutzman at nps.edu> wrote: >> >>> Thanks for pointing in the right direction John. >>> >>> Direct links to functional requirements for Displacer in HAnim 2.0 >>> specification: >>> >>> - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, >>> Clause 4 Concepts, 4.7 Displacer object >>> - >>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#DisplacerObject >>> >>> - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, >>> Clause 6 Object interfaces, 6.6 Displacer >>> - >>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer >>> >>> and >>> >>> - X3D 4.0 Architecture, Clause 26 Humanoid Animation (HAnim) >>> component, 26.3.1 HAnimDisplacer >>> - >>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimDisplacer >>> >>> and informative >>> >>> - X3D Tooltips, HAnimDisplacer >>> - https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimDisplacer >>> >>> Thanks for implementation efforts and careful scrutiny. >>> >>> Questions and potential issues/clarifications/corrections are always >>> welcome. >>> >>> >>> 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 >>> https://faculty.nps.edu/brutzman >>> >>> >>> >>> ------------------------------ >>> *From:* x3d-public on behalf of John >>> Carlson via x3d-public >>> *Sent:* Saturday, February 8, 2025 3:43 AM >>> *To:* Extensible 3D (X3D) Graphics public discussion < >>> x3d-public at web3d.org>; Carol McDonald ; Joe D >>> Williams >>> *Cc:* John Carlson ; Andreas Plesch < >>> andreasplesch at gmail.com> >>> *Subject:* Re: [x3d-public] HAnimDisplacer effect on coord.point >>> >>> Here?s what HAnim spec says under Displacer: >>> >>> https://www.web3d.org/documents/specifications/19774/V2.0/index.html >>> >>> ?For the *Displacer* objects that are contained in the *displacers* field >>> of the *Segment* objects, the *displacements* are defined and applied >>> in the *Segment* coordinate system. The base mesh for the morphed >>> *Segment* is the original mesh defined in the *Segment*.? >>> >>> And here?s what it says under Segment: >>> >>> ? >>> >>> The *coord* field is used for *Segment* objects that have deformable >>> meshes and shall contain coordinates referenced from the indexed mesh for >>> the *Segment* object. The coordinates are given the same name as the >>> *Segment* object, but with a "_coords" appended (e.g.,"skull_coords").? >>> displacements are an offset from the mesh, with weight from 0 to 1. So >>> weight times displacement is total offset from base mesh. 0 weight = no >>> offset, 1 weight = full displacements offset >>> >>> The Coordinate point is maintained to handle weight = 0. Weight ranges >>> from 0 to 1, but double check. >>> >>> Joe or Carol might know where to find it in the HAnim spec. >>> >>> I believe the answer is, ?during rendering,?. Since weight can vary with >>> animation, and so can displacements, AFAIK. More than one displacer can be >>> applied to the mesh. >>> >>> I have not read the spec. >>> >>> John >>> >>> >>> >>> On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public < >>> x3d-public at web3d.org> wrote: >>> >>> >>> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer >>> >>> does not directly explain what the effect of the displacer on the >>> coord.point field of the containing HAnimSegment is. But it mentions the >>> coord.point field and seems to imply that the coord.point field is involved. >>> >>> So the question is if the Displacer should alter the coord.point field >>> in order to achieve a graphical displacement, or if the Browser should only >>> apply the displacements during rendering without a change in the >>> coord.point field ? >>> >>> This is relevant if the coord.point field is accessed by routes or >>> scripts, in addition to displacers. >>> >>> Thanks for any feedback or ideas, >>> >>> Andreas >>> >>> -- >>> Andreas Plesch >>> Waltham, MA 02453 >>> _______________________________________________ >>> x3d-public mailing list >>> x3d-public at web3d.org >>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>> >>> >> > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger.seelig at yahoo.de Sun Feb 9 11:23:00 2025 From: holger.seelig at yahoo.de (Holger Seelig) Date: Sun, 9 Feb 2025 20:23:00 +0100 Subject: [x3d-public] HAnimDisplacer effect on coord.point In-Reply-To: References: <4cddd35a-705f-e6fa-742d-1e2e7f6551d7@earthlink.net> <4492C6F2-861C-4468-AEBF-BAEAB5EE6EDA@yahoo.de> Message-ID: I don't think so, coord.point changes are very very expensive quickly, and as Michalis said earlier, with reference to CoordinateInterpolator, we should get rid of them. Holger -- Holger Seelig Leipzig, Germany holger.seelig at yahoo.de https://create3000.github.io/x_ite/ > Am 09.02.2025 um 19:44 schrieb Andreas Plesch : > > Yes, that is an option. However, the question is if it should be changed so it is available for other purposes. > > Andreas > > On Sun, Feb 9, 2025, 1:40?PM Holger Seelig > wrote: >> X_ITE applies the HAnimDisplacers in the shader, thus no coord.point field has to be changed. >> Maybe that helps. >> >> Best regards, >> Holger >> >> -- >> Holger Seelig >> Leipzig, Germany >> >> holger.seelig at yahoo.de >> https://create3000.github.io/x_ite/ >> >>> Am 09.02.2025 um 19:33 schrieb Andreas Plesch via x3d-public >: >>> >>> That would be the point field of a Coordinate node >>> >>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/rendering.html#Coordinate >>> >>> which is used by the coord field of >>> >>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimSegment >>> >>> Andreas >>> >>> On Sun, Feb 9, 2025, 12:36?PM Joe D Williams > wrote: >>>> > coord node emit a point_changed event >>>> >>>> sorry,I don't see a field anywhere with that event. Displacer is likely to change several points when new weight is sent. All part of the cascade to produce the changed mesh? >>>> Thanks, >>>> Joe >>>> >>>> >>>> -----Original Message----- >>>> From: Andreas Plesch > >>>> Sent: Feb 9, 2025 4:25 AM >>>> To: Brutzman, Donald (Don) (CIV) > >>>> Cc: Extensible 3D (X3D) Graphics public discussion >, Carol McDonald >, Joe D Williams >, John Carlson > >>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>> >>>> >>>> Don, Joe and John >>>> >>>> Thanks for collecting these references. >>>> >>>> But I am not sure if there is an answer to my original question. Let me rephrase a bit the question: >>>> >>>> After a Displacer contained in a Segment node receives a set_weight input, should then the coord node emit a point_changed event ? >>>> >>>> I do not think HAnim is concerned about that, so it is really a X3D question. >>>> >>>> Thanks, Andreas >>>> >>>> On Sun, Feb 9, 2025, 12:49?AM Brutzman, Donald (Don) (CIV) > wrote: >>>>> Thanks for pointing in the right direction John. >>>>> >>>>> Direct links to functional requirements for Displacer in HAnim 2.0 specification: >>>>> HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, Clause 4 Concepts, 4.7 Displacer object >>>>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#DisplacerObject >>>>> >>>>> HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, Clause 6 Object interfaces, 6.6 Displacer >>>>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer >>>>> and >>>>> X3D 4.0 Architecture, Clause 26 Humanoid Animation (HAnim) component, 26.3.1 HAnimDisplacer >>>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimDisplacer >>>>> and informative >>>>> X3D Tooltips, HAnimDisplacer >>>>> https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimDisplacer >>>>> Thanks for implementation efforts and careful scrutiny. >>>>> >>>>> Questions and potential issues/clarifications/corrections are always welcome. >>>>> >>>>> >>>>> 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 https://faculty.nps.edu/brutzman >>>>> >>>>> >>>>> From: x3d-public > on behalf of John Carlson via x3d-public > >>>>> Sent: Saturday, February 8, 2025 3:43 AM >>>>> To: Extensible 3D (X3D) Graphics public discussion >; Carol McDonald >; Joe D Williams > >>>>> Cc: John Carlson >; Andreas Plesch > >>>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>> >>>>> Here?s what HAnim spec says under Displacer: >>>>> >>>>> https://www.web3d.org/documents/specifications/19774/V2.0/index.html >>>>> >>>>> ?For the Displacer objects that are contained in the displacers field of the Segment objects, the displacements are defined and applied in the Segment coordinate system. The base mesh for the morphed Segment is the original mesh defined in the Segment.? >>>>> >>>>> And here?s what it says under Segment: >>>>> >>>>> ? >>>>> The coord field is used for Segment objects that have deformable meshes and shall contain coordinates referenced from the indexed mesh for the Segment object. The coordinates are given the same name as the Segment object, but with a "_coords" appended (e.g.,"skull_coords").? >>>>> >>>>> displacements are an offset from the mesh, with weight from 0 to 1. So weight times displacement is total offset from base mesh. 0 weight = no offset, 1 weight = full displacements offset >>>>> >>>>> The Coordinate point is maintained to handle weight = 0. Weight ranges from 0 to 1, but double check. >>>>> >>>>> Joe or Carol might know where to find it in the HAnim spec. >>>>> >>>>> I believe the answer is, ?during rendering,?. Since weight can vary with animation, and so can displacements, AFAIK. More than one displacer can be applied to the mesh. >>>>> >>>>> I have not read the spec. >>>>> >>>>> John >>>>> >>>>> >>>>> >>>>> On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public > wrote: >>>>> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer >>>>> >>>>> does not directly explain what the effect of the displacer on the coord.point field of the containing HAnimSegment is. But it mentions the coord.point field and seems to imply that the coord.point field is involved. >>>>> >>>>> So the question is if the Displacer should alter the coord.point field in order to achieve a graphical displacement, or if the Browser should only apply the displacements during rendering without a change in the coord.point field ? >>>>> >>>>> This is relevant if the coord.point field is accessed by routes or scripts, in addition to displacers. >>>>> >>>>> Thanks for any feedback or ideas, >>>>> >>>>> Andreas >>>>> >>>>> -- >>>>> Andreas Plesch >>>>> Waltham, MA 02453 >>>>> _______________________________________________ >>>>> x3d-public mailing list >>>>> x3d-public at web3d.org >>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>> >>>> >>> _______________________________________________ >>> x3d-public mailing list >>> x3d-public at web3d.org >>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Sun Feb 9 11:28:32 2025 From: yottzumm at gmail.com (John Carlson) Date: Sun, 9 Feb 2025 13:28:32 -0600 Subject: [x3d-public] HAnimDisplacer effect on coord.point In-Reply-To: References: <4cddd35a-705f-e6fa-742d-1e2e7f6551d7@earthlink.net> <4492C6F2-861C-4468-AEBF-BAEAB5EE6EDA@yahoo.de> Message-ID: Agreed that individual numerical point or number events are expensive and should be batched, if implemented. If one wants something more efficient, perhaps just put a ROUTE on displacer weight, or whatever is changing weight. John On Sun, Feb 9, 2025 at 1:24?PM Holger Seelig via x3d-public < x3d-public at web3d.org> wrote: > I don't think so, coord.point changes are very very expensive quickly, and > as Michalis said earlier, with reference to CoordinateInterpolator, we > should get rid of them. > > Holger > -- > Holger Seelig > Leipzig, Germany > > holger.seelig at yahoo.de > https://create3000.github.io/x_ite/ > > Am 09.02.2025 um 19:44 schrieb Andreas Plesch : > > Yes, that is an option. However, the question is if it should be changed > so it is available for other purposes. > > Andreas > > On Sun, Feb 9, 2025, 1:40?PM Holger Seelig wrote: > >> X_ITE applies the HAnimDisplacers in the shader, thus no coord.point >> field has to be changed. >> Maybe that helps. >> >> Best regards, >> Holger >> >> -- >> Holger Seelig >> Leipzig, Germany >> >> holger.seelig at yahoo.de >> https://create3000.github.io/x_ite/ >> >> Am 09.02.2025 um 19:33 schrieb Andreas Plesch via x3d-public < >> x3d-public at web3d.org>: >> >> That would be the point field of a Coordinate node >> >> >> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/rendering.html#Coordinate >> >> which is used by the coord field of >> >> >> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimSegment >> >> Andreas >> >> On Sun, Feb 9, 2025, 12:36?PM Joe D Williams >> wrote: >> >>> > coord node emit a point_changed event >>> >>> >>> sorry,I don't see a field anywhere with that event. Displacer is likely >>> to change several points when new weight is sent. All part of the cascade >>> to produce the changed mesh? >>> Thanks, >>> Joe >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: Andreas Plesch >>> Sent: Feb 9, 2025 4:25 AM >>> To: Brutzman, Donald (Don) (CIV) >>> Cc: Extensible 3D (X3D) Graphics public discussion , >>> Carol McDonald , Joe D Williams < >>> joedwil at earthlink.net>, John Carlson >>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>> >>> >>> Don, Joe and John >>> >>> Thanks for collecting these references. >>> >>> But I am not sure if there is an answer to my original question. Let me >>> rephrase a bit the question: >>> >>> After a Displacer contained in a Segment node receives a set_weight >>> input, should then the coord node emit a point_changed event ? >>> >>> I do not think HAnim is concerned about that, so it is really a X3D >>> question. >>> >>> Thanks, Andreas >>> >>> On Sun, Feb 9, 2025, 12:49?AM Brutzman, Donald (Don) (CIV) < >>> brutzman at nps.edu> wrote: >>> >>>> Thanks for pointing in the right direction John. >>>> >>>> Direct links to functional requirements for Displacer in HAnim 2.0 >>>> specification: >>>> >>>> - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, >>>> Clause 4 Concepts, 4.7 Displacer object >>>> - >>>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#DisplacerObject >>>> >>>> - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, >>>> Clause 6 Object interfaces, 6.6 Displacer >>>> - >>>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer >>>> >>>> and >>>> >>>> - X3D 4.0 Architecture, Clause 26 Humanoid Animation (HAnim) >>>> component, 26.3.1 HAnimDisplacer >>>> - >>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimDisplacer >>>> >>>> and informative >>>> >>>> - X3D Tooltips, HAnimDisplacer >>>> - https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimDisplacer >>>> >>>> Thanks for implementation efforts and careful scrutiny. >>>> >>>> Questions and potential issues/clarifications/corrections are always >>>> welcome. >>>> >>>> >>>> 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 >>>> https://faculty.nps.edu/brutzman >>>> >>>> >>>> >>>> ------------------------------ >>>> *From:* x3d-public on behalf of John >>>> Carlson via x3d-public >>>> *Sent:* Saturday, February 8, 2025 3:43 AM >>>> *To:* Extensible 3D (X3D) Graphics public discussion < >>>> x3d-public at web3d.org>; Carol McDonald ; Joe D >>>> Williams >>>> *Cc:* John Carlson ; Andreas Plesch < >>>> andreasplesch at gmail.com> >>>> *Subject:* Re: [x3d-public] HAnimDisplacer effect on coord.point >>>> >>>> Here?s what HAnim spec says under Displacer: >>>> >>>> https://www.web3d.org/documents/specifications/19774/V2.0/index.html >>>> >>>> ?For the *Displacer* objects that are contained in the *displacers* field >>>> of the *Segment* objects, the *displacements* are defined and applied >>>> in the *Segment* coordinate system. The base mesh for the morphed >>>> *Segment* is the original mesh defined in the *Segment*.? >>>> >>>> And here?s what it says under Segment: >>>> >>>> ? >>>> >>>> The *coord* field is used for *Segment* objects that have deformable >>>> meshes and shall contain coordinates referenced from the indexed mesh for >>>> the *Segment* object. The coordinates are given the same name as the >>>> *Segment* object, but with a "_coords" appended (e.g.,"skull_coords").? >>>> displacements are an offset from the mesh, with weight from 0 to 1. >>>> So weight times displacement is total offset from base mesh. 0 weight = no >>>> offset, 1 weight = full displacements offset >>>> >>>> The Coordinate point is maintained to handle weight = 0. Weight ranges >>>> from 0 to 1, but double check. >>>> >>>> Joe or Carol might know where to find it in the HAnim spec. >>>> >>>> I believe the answer is, ?during rendering,?. Since weight can vary >>>> with animation, and so can displacements, AFAIK. More than one displacer >>>> can be applied to the mesh. >>>> >>>> I have not read the spec. >>>> >>>> John >>>> >>>> >>>> >>>> On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public < >>>> x3d-public at web3d.org> wrote: >>>> >>>> >>>> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer >>>> >>>> does not directly explain what the effect of the displacer on the >>>> coord.point field of the containing HAnimSegment is. But it mentions the >>>> coord.point field and seems to imply that the coord.point field is involved. >>>> >>>> So the question is if the Displacer should alter the coord.point field >>>> in order to achieve a graphical displacement, or if the Browser should only >>>> apply the displacements during rendering without a change in the >>>> coord.point field ? >>>> >>>> This is relevant if the coord.point field is accessed by routes or >>>> scripts, in addition to displacers. >>>> >>>> Thanks for any feedback or ideas, >>>> >>>> Andreas >>>> >>>> -- >>>> Andreas Plesch >>>> Waltham, MA 02453 >>>> _______________________________________________ >>>> x3d-public mailing list >>>> x3d-public at web3d.org >>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>> >>>> >>> >> _______________________________________________ >> x3d-public mailing list >> x3d-public at web3d.org >> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >> >> >> > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Sun Feb 9 11:30:03 2025 From: yottzumm at gmail.com (John Carlson) Date: Sun, 9 Feb 2025 13:30:03 -0600 Subject: [x3d-public] HAnimDisplacer effect on coord.point In-Reply-To: <4492C6F2-861C-4468-AEBF-BAEAB5EE6EDA@yahoo.de> References: <4cddd35a-705f-e6fa-742d-1e2e7f6551d7@earthlink.net> <4492C6F2-861C-4468-AEBF-BAEAB5EE6EDA@yahoo.de> Message-ID: I think this is preferable. The computation should be done in parallel or SIMD. On Sun, Feb 9, 2025 at 12:41?PM Holger Seelig via x3d-public < x3d-public at web3d.org> wrote: > X_ITE applies the HAnimDisplacers in the shader, thus no coord.point field > has to be changed. > Maybe that helps. > > Best regards, > Holger > > -- > Holger Seelig > Leipzig, Germany > > holger.seelig at yahoo.de > https://create3000.github.io/x_ite/ > > Am 09.02.2025 um 19:33 schrieb Andreas Plesch via x3d-public < > x3d-public at web3d.org>: > > That would be the point field of a Coordinate node > > > https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/rendering.html#Coordinate > > which is used by the coord field of > > > https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimSegment > > Andreas > > On Sun, Feb 9, 2025, 12:36?PM Joe D Williams > wrote: > >> > coord node emit a point_changed event >> >> >> sorry,I don't see a field anywhere with that event. Displacer is likely >> to change several points when new weight is sent. All part of the cascade >> to produce the changed mesh? >> Thanks, >> Joe >> >> >> >> >> >> -----Original Message----- >> From: Andreas Plesch >> Sent: Feb 9, 2025 4:25 AM >> To: Brutzman, Donald (Don) (CIV) >> Cc: Extensible 3D (X3D) Graphics public discussion , >> Carol McDonald , Joe D Williams , >> John Carlson >> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >> >> >> Don, Joe and John >> >> Thanks for collecting these references. >> >> But I am not sure if there is an answer to my original question. Let me >> rephrase a bit the question: >> >> After a Displacer contained in a Segment node receives a set_weight >> input, should then the coord node emit a point_changed event ? >> >> I do not think HAnim is concerned about that, so it is really a X3D >> question. >> >> Thanks, Andreas >> >> On Sun, Feb 9, 2025, 12:49?AM Brutzman, Donald (Don) (CIV) < >> brutzman at nps.edu> wrote: >> >>> Thanks for pointing in the right direction John. >>> >>> Direct links to functional requirements for Displacer in HAnim 2.0 >>> specification: >>> >>> - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, >>> Clause 4 Concepts, 4.7 Displacer object >>> - >>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#DisplacerObject >>> >>> - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, >>> Clause 6 Object interfaces, 6.6 Displacer >>> - >>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer >>> >>> and >>> >>> - X3D 4.0 Architecture, Clause 26 Humanoid Animation (HAnim) >>> component, 26.3.1 HAnimDisplacer >>> - >>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimDisplacer >>> >>> and informative >>> >>> - X3D Tooltips, HAnimDisplacer >>> - https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimDisplacer >>> >>> Thanks for implementation efforts and careful scrutiny. >>> >>> Questions and potential issues/clarifications/corrections are always >>> welcome. >>> >>> >>> 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 >>> https://faculty.nps.edu/brutzman >>> >>> >>> >>> ------------------------------ >>> *From:* x3d-public on behalf of John >>> Carlson via x3d-public >>> *Sent:* Saturday, February 8, 2025 3:43 AM >>> *To:* Extensible 3D (X3D) Graphics public discussion < >>> x3d-public at web3d.org>; Carol McDonald ; Joe D >>> Williams >>> *Cc:* John Carlson ; Andreas Plesch < >>> andreasplesch at gmail.com> >>> *Subject:* Re: [x3d-public] HAnimDisplacer effect on coord.point >>> >>> Here?s what HAnim spec says under Displacer: >>> >>> https://www.web3d.org/documents/specifications/19774/V2.0/index.html >>> >>> ?For the *Displacer* objects that are contained in the *displacers* field >>> of the *Segment* objects, the *displacements* are defined and applied >>> in the *Segment* coordinate system. The base mesh for the morphed >>> *Segment* is the original mesh defined in the *Segment*.? >>> >>> And here?s what it says under Segment: >>> >>> ? >>> >>> The *coord* field is used for *Segment* objects that have deformable >>> meshes and shall contain coordinates referenced from the indexed mesh for >>> the *Segment* object. The coordinates are given the same name as the >>> *Segment* object, but with a "_coords" appended (e.g.,"skull_coords").? >>> displacements are an offset from the mesh, with weight from 0 to 1. So >>> weight times displacement is total offset from base mesh. 0 weight = no >>> offset, 1 weight = full displacements offset >>> >>> The Coordinate point is maintained to handle weight = 0. Weight ranges >>> from 0 to 1, but double check. >>> >>> Joe or Carol might know where to find it in the HAnim spec. >>> >>> I believe the answer is, ?during rendering,?. Since weight can vary with >>> animation, and so can displacements, AFAIK. More than one displacer can be >>> applied to the mesh. >>> >>> I have not read the spec. >>> >>> John >>> >>> >>> >>> On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public < >>> x3d-public at web3d.org> wrote: >>> >>> >>> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer >>> >>> does not directly explain what the effect of the displacer on the >>> coord.point field of the containing HAnimSegment is. But it mentions the >>> coord.point field and seems to imply that the coord.point field is involved. >>> >>> So the question is if the Displacer should alter the coord.point field >>> in order to achieve a graphical displacement, or if the Browser should only >>> apply the displacements during rendering without a change in the >>> coord.point field ? >>> >>> This is relevant if the coord.point field is accessed by routes or >>> scripts, in addition to displacers. >>> >>> Thanks for any feedback or ideas, >>> >>> Andreas >>> >>> -- >>> Andreas Plesch >>> Waltham, MA 02453 >>> _______________________________________________ >>> x3d-public mailing list >>> x3d-public at web3d.org >>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>> >>> >> > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > > > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Sun Feb 9 11:34:09 2025 From: yottzumm at gmail.com (John Carlson) Date: Sun, 9 Feb 2025 13:34:09 -0600 Subject: [x3d-public] HAnimDisplacer effect on coord.point In-Reply-To: References: <4cddd35a-705f-e6fa-742d-1e2e7f6551d7@earthlink.net> Message-ID: Perhaps we should just make the coord field optional with Segment and Site displacers? If not specified, look in HAnimHumanoid.skinCoord, or make the search for coords hierarchical. As Joe says, a cascade. Wondering, John On Sun, Feb 9, 2025 at 12:33?PM Andreas Plesch wrote: > That would be the point field of a Coordinate node > > > https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/rendering.html#Coordinate > > which is used by the coord field of > > > https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimSegment > > Andreas > > On Sun, Feb 9, 2025, 12:36?PM Joe D Williams > wrote: > >> > coord node emit a point_changed event >> >> >> >> sorry,I don't see a field anywhere with that event. Displacer is likely >> to change several points when new weight is sent. All part of the cascade >> to produce the changed mesh? >> >> Thanks, >> >> Joe >> >> >> >> >> >> -----Original Message----- >> From: Andreas Plesch >> Sent: Feb 9, 2025 4:25 AM >> To: Brutzman, Donald (Don) (CIV) >> Cc: Extensible 3D (X3D) Graphics public discussion , >> Carol McDonald , Joe D Williams , >> John Carlson >> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >> >> >> Don, Joe and John >> >> Thanks for collecting these references. >> >> But I am not sure if there is an answer to my original question. Let me >> rephrase a bit the question: >> >> After a Displacer contained in a Segment node receives a set_weight >> input, should then the coord node emit a point_changed event ? >> >> I do not think HAnim is concerned about that, so it is really a X3D >> question. >> >> Thanks, Andreas >> >> On Sun, Feb 9, 2025, 12:49?AM Brutzman, Donald (Don) (CIV) < >> brutzman at nps.edu> wrote: >> >>> Thanks for pointing in the right direction John. >>> >>> Direct links to functional requirements for Displacer in HAnim 2.0 >>> specification: >>> >>> - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, >>> Clause 4 Concepts, 4.7 Displacer object >>> - >>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#DisplacerObject >>> >>> - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, >>> Clause 6 Object interfaces, 6.6 Displacer >>> - >>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer >>> >>> and >>> >>> - X3D 4.0 Architecture, Clause 26 Humanoid Animation (HAnim) >>> component, 26.3.1 HAnimDisplacer >>> - >>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimDisplacer >>> >>> and informative >>> >>> - X3D Tooltips, HAnimDisplacer >>> - https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimDisplacer >>> >>> Thanks for implementation efforts and careful scrutiny. >>> >>> Questions and potential issues/clarifications/corrections are always >>> welcome. >>> >>> >>> 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 >>> https://faculty.nps.edu/brutzman >>> >>> >>> >>> ------------------------------ >>> *From:* x3d-public on behalf of John >>> Carlson via x3d-public >>> *Sent:* Saturday, February 8, 2025 3:43 AM >>> *To:* Extensible 3D (X3D) Graphics public discussion < >>> x3d-public at web3d.org>; Carol McDonald ; Joe D >>> Williams >>> *Cc:* John Carlson ; Andreas Plesch < >>> andreasplesch at gmail.com> >>> *Subject:* Re: [x3d-public] HAnimDisplacer effect on coord.point >>> >>> Here?s what HAnim spec says under Displacer: >>> >>> https://www.web3d.org/documents/specifications/19774/V2.0/index.html >>> >>> ?For the *Displacer* objects that are contained in the *displacers* field >>> of the *Segment* objects, the *displacements* are defined and applied >>> in the *Segment* coordinate system. The base mesh for the morphed >>> *Segment* is the original mesh defined in the *Segment*.? >>> >>> And here?s what it says under Segment: >>> >>> ? >>> >>> The *coord* field is used for *Segment* objects that have deformable >>> meshes and shall contain coordinates referenced from the indexed mesh for >>> the *Segment* object. The coordinates are given the same name as the >>> *Segment* object, but with a "_coords" appended (e.g.,"skull_coords").? >>> displacements are an offset from the mesh, with weight from 0 to 1. So >>> weight times displacement is total offset from base mesh. 0 weight = no >>> offset, 1 weight = full displacements offset >>> >>> The Coordinate point is maintained to handle weight = 0. Weight ranges >>> from 0 to 1, but double check. >>> >>> Joe or Carol might know where to find it in the HAnim spec. >>> >>> I believe the answer is, ?during rendering,?. Since weight can vary with >>> animation, and so can displacements, AFAIK. More than one displacer can be >>> applied to the mesh. >>> >>> I have not read the spec. >>> >>> John >>> >>> >>> >>> On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public < >>> x3d-public at web3d.org> wrote: >>> >>> >>> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer >>> >>> does not directly explain what the effect of the displacer on the >>> coord.point field of the containing HAnimSegment is. But it mentions the >>> coord.point field and seems to imply that the coord.point field is involved. >>> >>> So the question is if the Displacer should alter the coord.point field >>> in order to achieve a graphical displacement, or if the Browser should only >>> apply the displacements during rendering without a change in the >>> coord.point field ? >>> >>> This is relevant if the coord.point field is accessed by routes or >>> scripts, in addition to displacers. >>> >>> Thanks for any feedback or ideas, >>> >>> Andreas >>> >>> -- >>> Andreas Plesch >>> Waltham, MA 02453 >>> _______________________________________________ >>> x3d-public mailing list >>> x3d-public at web3d.org >>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreasplesch at gmail.com Sun Feb 9 14:35:01 2025 From: andreasplesch at gmail.com (Andreas Plesch) Date: Sun, 9 Feb 2025 17:35:01 -0500 Subject: [x3d-public] HAnimDisplacer effect on coord.point In-Reply-To: References: <4cddd35a-705f-e6fa-742d-1e2e7f6551d7@earthlink.net> Message-ID: Having a coord field is wise as it makes it unambiguous how displacers are applied. The ManyClocks.x3d example has a lot of HAnimSegment nodes which are empty, only have default values, and seem useless. In particular a NULL coord field invites problems. Probably such a node should be just ignored but it would be good to have more specific spec. guidance, eg. allowing undefined browser behavior similar to many other nodes. There is also a weird Segment node (hanim___4) which does not have geometry and a NULL coord field, but has a displacer. The displacer is even the target of a route. It would be good if such self in-consistent content would be allowed to lead to undefined browser behavior as well. Andreas On Sun, Feb 9, 2025, 2:34?PM John Carlson wrote: > Perhaps we should just make the coord field optional with Segment and Site > displacers? If not specified, look in HAnimHumanoid.skinCoord, or make the > search for coords hierarchical. As Joe says, a cascade. > > Wondering, > > John > > On Sun, Feb 9, 2025 at 12:33?PM Andreas Plesch > wrote: > >> That would be the point field of a Coordinate node >> >> >> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/rendering.html#Coordinate >> >> which is used by the coord field of >> >> >> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimSegment >> >> Andreas >> >> On Sun, Feb 9, 2025, 12:36?PM Joe D Williams >> wrote: >> >>> > coord node emit a point_changed event >>> >>> >>> >>> sorry,I don't see a field anywhere with that event. Displacer is likely >>> to change several points when new weight is sent. All part of the cascade >>> to produce the changed mesh? >>> >>> Thanks, >>> >>> Joe >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: Andreas Plesch >>> Sent: Feb 9, 2025 4:25 AM >>> To: Brutzman, Donald (Don) (CIV) >>> Cc: Extensible 3D (X3D) Graphics public discussion , >>> Carol McDonald , Joe D Williams < >>> joedwil at earthlink.net>, John Carlson >>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>> >>> >>> Don, Joe and John >>> >>> Thanks for collecting these references. >>> >>> But I am not sure if there is an answer to my original question. Let me >>> rephrase a bit the question: >>> >>> After a Displacer contained in a Segment node receives a set_weight >>> input, should then the coord node emit a point_changed event ? >>> >>> I do not think HAnim is concerned about that, so it is really a X3D >>> question. >>> >>> Thanks, Andreas >>> >>> On Sun, Feb 9, 2025, 12:49?AM Brutzman, Donald (Don) (CIV) < >>> brutzman at nps.edu> wrote: >>> >>>> Thanks for pointing in the right direction John. >>>> >>>> Direct links to functional requirements for Displacer in HAnim 2.0 >>>> specification: >>>> >>>> - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, >>>> Clause 4 Concepts, 4.7 Displacer object >>>> - >>>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#DisplacerObject >>>> >>>> - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, >>>> Clause 6 Object interfaces, 6.6 Displacer >>>> - >>>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer >>>> >>>> and >>>> >>>> - X3D 4.0 Architecture, Clause 26 Humanoid Animation (HAnim) >>>> component, 26.3.1 HAnimDisplacer >>>> - >>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimDisplacer >>>> >>>> and informative >>>> >>>> - X3D Tooltips, HAnimDisplacer >>>> - https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimDisplacer >>>> >>>> Thanks for implementation efforts and careful scrutiny. >>>> >>>> Questions and potential issues/clarifications/corrections are always >>>> welcome. >>>> >>>> >>>> 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 >>>> https://faculty.nps.edu/brutzman >>>> >>>> >>>> >>>> ------------------------------ >>>> *From:* x3d-public on behalf of John >>>> Carlson via x3d-public >>>> *Sent:* Saturday, February 8, 2025 3:43 AM >>>> *To:* Extensible 3D (X3D) Graphics public discussion < >>>> x3d-public at web3d.org>; Carol McDonald ; Joe D >>>> Williams >>>> *Cc:* John Carlson ; Andreas Plesch < >>>> andreasplesch at gmail.com> >>>> *Subject:* Re: [x3d-public] HAnimDisplacer effect on coord.point >>>> >>>> Here?s what HAnim spec says under Displacer: >>>> >>>> https://www.web3d.org/documents/specifications/19774/V2.0/index.html >>>> >>>> ?For the *Displacer* objects that are contained in the *displacers* field >>>> of the *Segment* objects, the *displacements* are defined and applied >>>> in the *Segment* coordinate system. The base mesh for the morphed >>>> *Segment* is the original mesh defined in the *Segment*.? >>>> >>>> And here?s what it says under Segment: >>>> >>>> ? >>>> >>>> The *coord* field is used for *Segment* objects that have deformable >>>> meshes and shall contain coordinates referenced from the indexed mesh for >>>> the *Segment* object. The coordinates are given the same name as the >>>> *Segment* object, but with a "_coords" appended (e.g.,"skull_coords").? >>>> displacements are an offset from the mesh, with weight from 0 to 1. >>>> So weight times displacement is total offset from base mesh. 0 weight = no >>>> offset, 1 weight = full displacements offset >>>> >>>> The Coordinate point is maintained to handle weight = 0. Weight ranges >>>> from 0 to 1, but double check. >>>> >>>> Joe or Carol might know where to find it in the HAnim spec. >>>> >>>> I believe the answer is, ?during rendering,?. Since weight can vary >>>> with animation, and so can displacements, AFAIK. More than one displacer >>>> can be applied to the mesh. >>>> >>>> I have not read the spec. >>>> >>>> John >>>> >>>> >>>> >>>> On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public < >>>> x3d-public at web3d.org> wrote: >>>> >>>> >>>> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer >>>> >>>> does not directly explain what the effect of the displacer on the >>>> coord.point field of the containing HAnimSegment is. But it mentions the >>>> coord.point field and seems to imply that the coord.point field is involved. >>>> >>>> So the question is if the Displacer should alter the coord.point field >>>> in order to achieve a graphical displacement, or if the Browser should only >>>> apply the displacements during rendering without a change in the >>>> coord.point field ? >>>> >>>> This is relevant if the coord.point field is accessed by routes or >>>> scripts, in addition to displacers. >>>> >>>> Thanks for any feedback or ideas, >>>> >>>> Andreas >>>> >>>> -- >>>> Andreas Plesch >>>> Waltham, MA 02453 >>>> _______________________________________________ >>>> x3d-public mailing list >>>> x3d-public at web3d.org >>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>> >>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From joedwil at earthlink.net Mon Feb 10 04:27:50 2025 From: joedwil at earthlink.net (Joe D Williams) Date: Mon, 10 Feb 2025 12:27:50 +0000 Subject: [x3d-public] HAnimDisplacer effect on coord.point Message-ID: <7b6e9124-759a-e41a-230d-4a85d9ef12a4@earthlink.net> > Having a coord field is wise as it makes it unambiguous how displacers are applied. Level 1 can include displacers operating on geometry defined in coord fields in a Segment or child Site nodes. Level 2 is can include displacers operating on geometry defined in the skinCoord field of the Humanoid. Level 2 can include Level 1. To me the spec is clear, the displacers in a Segment control points indexed in order of appearance in the Segment. A separate list of displacer-affected points is not necessary This is not in conflict with 'skin' where displacers in a Joint control points indexed by order of appearance in the skinCoord field. Segment geometry is not 'skin' so we would need a node maybe named segmentCoord Coordinate point which would contain all points of all geometries in the Segment? Does not seem useful when the information is there already in the geometry as it appears directly in the code. The skin is special because the skinCoord Coordinate point field list the specific points to be used in the skin animation process, as weighted by one or more Joint rotation data. This listing may (1) duplicate (USE) a coord Coordinate point field defining skin mesh or, (2) a sampling of points found in coord Coordinate point fields of various Segment geometry. The latter (2) is some kind of tricky way to constitute a skin from a set of individual geometries contained in various Segment nodes. Again, for Level 2, the skin points are animated as weighted algorithm as certain Joint rotation(s) are applied, then any points also controlled by Joint displacers is applied. For Level 1 the child geometry of Segment is moved directly by the parent Joint rotation, then any Segment displacers is applied. So yes it can be complicated but if the Level 1 Segment geometry and the Level 2 skin geometry are separate then it gets easy again. Thanks and Best, Joe -----Original Message----- From: Andreas Plesch Sent: Feb 9, 2025 2:35 PM To: John Carlson Cc: Joe D Williams , Brutzman Donald (Don) (CIV) , Extensible 3D (X3D) Graphics public discussion , Carol McDonald Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point Having a coord field is wise as it makes it unambiguous how displacers are applied. The ManyClocks.x3d example has a lot of HAnimSegment nodes which are empty, only have default values, and seem useless. In particular a NULL coord field invites problems. Probably such a node should be just ignored but it would be good to have more specific spec. guidance, eg. allowing undefined browser behavior similar to many other nodes. There is also a weird Segment node (hanim___4) which does not have geometry and a NULL coord field, but has a displacer. The displacer is even the target of a route. It would be good if such self in-consistent content would be allowed to lead to undefined browser behavior as well. Andreas On Sun, Feb 9, 2025, 2:34?PM John Carlson wrote: Perhaps we should just make the coord field optional with Segment and Site displacers? If not specified, look in HAnimHumanoid.skinCoord, or make the search for coords hierarchical. As Joe says, a cascade. Wondering, John On Sun, Feb 9, 2025 at 12:33?PM Andreas Plesch wrote: That would be the point field of a Coordinate node https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/rendering.html#Coordinate which is used by the coord field of https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimSegment Andreas On Sun, Feb 9, 2025, 12:36?PM Joe D Williams wrote: > coord node emit a point_changed event sorry,I don't see a field anywhere with that event. Displacer is likely to change several points when new weight is sent. All part of the cascade to produce the changed mesh? Thanks, Joe -----Original Message----- From: Andreas Plesch Sent: Feb 9, 2025 4:25 AM To: Brutzman, Donald (Don) (CIV) Cc: Extensible 3D (X3D) Graphics public discussion , Carol McDonald , Joe D Williams , John Carlson Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point Don, Joe and John Thanks for collecting these references. But I am not sure if there is an answer to my original question. Let me rephrase a bit the question: After a Displacer contained in a Segment node receives a set_weight input, should then the coord node emit a point_changed event ? I do not think HAnim is concerned about that, so it is really a X3D question. Thanks, Andreas On Sun, Feb 9, 2025, 12:49?AM Brutzman, Donald (Don) (CIV) wrote: Thanks for pointing in the right direction John. Direct links to functional requirements for Displacer in HAnim 2.0 specification: * HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, Clause 4 Concepts, 4.7 Displacer object * https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#DisplacerObject * HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, Clause 6 Object interfaces, 6.6 Displacer * https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer and * X3D 4.0 Architecture, Clause 26 Humanoid Animation (HAnim) component, 26.3.1 HAnimDisplacer * https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimDisplacer and informative * X3D Tooltips, HAnimDisplacer * https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimDisplacer Thanks for implementation efforts and careful scrutiny. Questions and potential issues/clarifications/corrections are always welcome. all the best, Don -- Don Brutzman Naval Postgraduate School, Code USW/Br brutzman at nps.edu (mailto:brutzman at nps.edu) Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149 X3D graphics, virtual worlds, navy robotics https://faculty.nps.edu/brutzman From: x3d-public on behalf of John Carlson via x3d-public Sent: Saturday, February 8, 2025 3:43 AM To: Extensible 3D (X3D) Graphics public discussion ; Carol McDonald ; Joe D Williams Cc: John Carlson ; Andreas Plesch Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point Here’s what HAnim spec says under Displacer: https://www.web3d.org/documents/specifications/19774/V2.0/index.html “For the Displacer objects that are contained in the displacers field of the Segment objects, the displacements are defined and applied in the Segment coordinate system. The base mesh for the morphed Segment is the original mesh defined in the Segment.” And here’s what it says under Segment: “ The coord field is used for Segment objects that have deformable meshes and shall contain coordinates referenced from the indexed mesh for the Segment object. The coordinates are given the same name as the Segment object, but with a "_coords" appended (e.g.,"skull_coords").” displacements are an offset from the mesh, with weight from 0 to 1. So weight times displacement is total offset from base mesh. 0 weight = no offset, 1 weight = full displacements offset The Coordinate point is maintained to handle weight = 0. Weight ranges from 0 to 1, but double check. Joe or Carol might know where to find it in the HAnim spec. I believe the answer is, “during rendering,”. Since weight can vary with animation, and so can displacements, AFAIK. More than one displacer can be applied to the mesh. I have not read the spec. John On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public wrote: https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer does not directly explain what the effect of the displacer on the coord.point field of the containing HAnimSegment is. But it mentions the coord.point field and seems to imply that the coord.point field is involved. So the question is if the Displacer should alter the coord.point field in order to achieve a graphical displacement, or if the Browser should only apply the displacements during rendering without a change in the coord.point field ? This is relevant if the coord.point field is accessed by routes or scripts, in addition to displacers. Thanks for any feedback or ideas, Andreas -- Andreas Plesch Waltham, MA 02453 _______________________________________________ x3d-public mailing list x3d-public at web3d.org (mailto:x3d-public at web3d.org) http://web3d.org/mailman/listinfo/x3d-public_web3d.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreasplesch at gmail.com Mon Feb 10 08:31:04 2025 From: andreasplesch at gmail.com (Andreas Plesch) Date: Mon, 10 Feb 2025 11:31:04 -0500 Subject: [x3d-public] SFRotation default value spec. inconsistency Message-ID: https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/fieldTypes.html#SFRotationAndMFRotation specifies that (0 0 1 0) is the value of an uninitialized SFRotation given as (x y z a). However, the JS SAI spec. in table 7.18 in https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#SFRotationInstanceCreationFunction effectively makes (0 1 0 0) the default value if no parameters are provided. The inconsistency does not have much of an impact since both are 0 rotations but I believe (0 1 0 0) - a 0 rotation around y - may have been intended as the default. -Andreas -- Andreas Plesch Waltham, MA 02453 -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreasplesch at gmail.com Mon Feb 10 08:42:48 2025 From: andreasplesch at gmail.com (Andreas Plesch) Date: Mon, 10 Feb 2025 11:42:48 -0500 Subject: [x3d-public] SFRotation default value spec. inconsistency In-Reply-To: References: Message-ID: The JS SAI spec. at https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#FieldServices does not list functions for SFColorRGBA, only SFColor. There may be an earlier report. -Andreas On Mon, Feb 10, 2025 at 11:31?AM Andreas Plesch wrote: > > https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/fieldTypes.html#SFRotationAndMFRotation > > specifies that (0 0 1 0) is the value of an uninitialized SFRotation given > as (x y z a). > > However, the JS SAI spec. in table 7.18 in > https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#SFRotationInstanceCreationFunction > > effectively makes (0 1 0 0) the default value if no parameters are > provided. > > The inconsistency does not have much of an impact since both are 0 > rotations but I believe (0 1 0 0) - a 0 rotation around y - may have been > intended as the default. > > -Andreas > > -- > Andreas Plesch > Waltham, MA 02453 > -- Andreas Plesch Waltham, MA 02453 -------------- next part -------------- An HTML attachment was scrubbed... URL: From joedwil at earthlink.net Mon Feb 10 09:50:03 2025 From: joedwil at earthlink.net (Joe D Williams) Date: Mon, 10 Feb 2025 17:50:03 +0000 Subject: [x3d-public] SFRotation default value spec. inconsistency Message-ID: <6b6566ee-7393-a6d6-67d0-17383f31e12a@earthlink.net> I think the 0 0 1 0 should be used everywhere for default axis-angle. I thinkI see 'zerp' unit quaternions (as in gltf as 0 0 0 1 XYZW) Thanks, Joe -----Original Message----- From: Extensible 3D (X3D) Graphics public discussion Sent: Feb 10, 2025 8:44 AM To: X3D Graphics public mailing list Cc: Andreas Plesch Subject: Re: [x3d-public] SFRotation default value spec. inconsistency The JS SAI spec. at https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#FieldServices does not list functions for SFColorRGBA, only SFColor. There may be an earlier report. -Andreas On Mon, Feb 10, 2025 at 11:31?AM Andreas Plesch wrote: https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/fieldTypes.html#SFRotationAndMFRotation specifies that (0 0 1 0) is the value of an uninitialized SFRotation given as (x y z a). However, the JS SAI spec. in table 7.18 in https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#SFRotationInstanceCreationFunction effectively makes (0 1 0 0) the default value if no parameters are provided. The inconsistency does not have much of an impact since both are 0 rotations but I believe (0 1 0 0) - a 0 rotation around y - may have been intended as the default. -Andreas -- Andreas Plesch Waltham, MA 02453 -- Andreas Plesch Waltham, MA 02453 -------------- next part -------------- An HTML attachment was scrubbed... URL: From joedwil at earthlink.net Mon Feb 10 09:57:19 2025 From: joedwil at earthlink.net (Joe D Williams) Date: Mon, 10 Feb 2025 17:57:19 +0000 Subject: [x3d-public] SFRotation default value spec. inconsistency Message-ID: not zerp, zero -----Original Message----- From: Extensible 3D (X3D) Graphics public discussion Sent: Feb 10, 2025 9:50 AM To: Extensible 3D (X3D) Graphics public discussion , X3D Graphics public mailing list Cc: Joe D Williams , Andreas Plesch Subject: Re: [x3d-public] SFRotation default value spec. inconsistency I think the 0 0 1 0 should be used everywhere for default axis-angle. I thinkI see 'zerp' unit quaternions (as in gltf as 0 0 0 1 XYZW) Thanks, Joe -----Original Message----- From: Extensible 3D (X3D) Graphics public discussion Sent: Feb 10, 2025 8:44 AM To: X3D Graphics public mailing list Cc: Andreas Plesch Subject: Re: [x3d-public] SFRotation default value spec. inconsistency The JS SAI spec. at https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#FieldServices does not list functions for SFColorRGBA, only SFColor. There may be an earlier report. -Andreas On Mon, Feb 10, 2025 at 11:31?AM Andreas Plesch wrote: https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/fieldTypes.html#SFRotationAndMFRotation specifies that (0 0 1 0) is the value of an uninitialized SFRotation given as (x y z a). However, the JS SAI spec. in table 7.18 in https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#SFRotationInstanceCreationFunction effectively makes (0 1 0 0) the default value if no parameters are provided. The inconsistency does not have much of an impact since both are 0 rotations but I believe (0 1 0 0) - a 0 rotation around y - may have been intended as the default. -Andreas -- Andreas Plesch Waltham, MA 02453 -- Andreas Plesch Waltham, MA 02453 -------------- next part -------------- An HTML attachment was scrubbed... URL: From joedwil at earthlink.net Mon Feb 10 10:23:00 2025 From: joedwil at earthlink.net (Joe D Williams) Date: Mon, 10 Feb 2025 18:23:00 +0000 Subject: [x3d-public] HAnimDisplacer effect on coord.point Message-ID: <89c7a8a3-1da8-f9c4-b8a8-cccd72fd08f5@earthlink.net> > Perhaps we should just make the coord field optional with Segment and Site displacers? please, no. If no coordIndex field,then no Displacer should be there. There are no defaults in a Displacer, there are only the same number of index and weight and displacements entries otherwise it shold not do anything. In your examples, any that are empty should be removed. Although I guess there is the case where these are filled by some input in runtime. Thanks, Joe -----Original Message----- From: Andreas Plesch Sent: Feb 9, 2025 2:35 PM To: John Carlson Cc: Joe D Williams , Brutzman Donald (Don) (CIV) , Extensible 3D (X3D) Graphics public discussion , Carol McDonald Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point Having a coord field is wise as it makes it unambiguous how displacers are applied. The ManyClocks.x3d example has a lot of HAnimSegment nodes which are empty, only have default values, and seem useless. In particular a NULL coord field invites problems. Probably such a node should be just ignored but it would be good to have more specific spec. guidance, eg. allowing undefined browser behavior similar to many other nodes. There is also a weird Segment node (hanim___4) which does not have geometry and a NULL coord field, but has a displacer. The displacer is even the target of a route. It would be good if such self in-consistent content would be allowed to lead to undefined browser behavior as well. Andreas On Sun, Feb 9, 2025, 2:34?PM John Carlson wrote: Perhaps we should just make the coord field optional with Segment and Site displacers? If not specified, look in HAnimHumanoid.skinCoord, or make the search for coords hierarchical. As Joe says, a cascade. Wondering, John On Sun, Feb 9, 2025 at 12:33?PM Andreas Plesch wrote: That would be the point field of a Coordinate node https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/rendering.html#Coordinate which is used by the coord field of https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimSegment Andreas On Sun, Feb 9, 2025, 12:36?PM Joe D Williams wrote: > coord node emit a point_changed event sorry,I don't see a field anywhere with that event. Displacer is likely to change several points when new weight is sent. All part of the cascade to produce the changed mesh? Thanks, Joe -----Original Message----- From: Andreas Plesch Sent: Feb 9, 2025 4:25 AM To: Brutzman, Donald (Don) (CIV) Cc: Extensible 3D (X3D) Graphics public discussion , Carol McDonald , Joe D Williams , John Carlson Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point Don, Joe and John Thanks for collecting these references. But I am not sure if there is an answer to my original question. Let me rephrase a bit the question: After a Displacer contained in a Segment node receives a set_weight input, should then the coord node emit a point_changed event ? I do not think HAnim is concerned about that, so it is really a X3D question. Thanks, Andreas On Sun, Feb 9, 2025, 12:49?AM Brutzman, Donald (Don) (CIV) wrote: Thanks for pointing in the right direction John. Direct links to functional requirements for Displacer in HAnim 2.0 specification: * HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, Clause 4 Concepts, 4.7 Displacer object * https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#DisplacerObject * HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, Clause 6 Object interfaces, 6.6 Displacer * https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer and * X3D 4.0 Architecture, Clause 26 Humanoid Animation (HAnim) component, 26.3.1 HAnimDisplacer * https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimDisplacer and informative * X3D Tooltips, HAnimDisplacer * https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimDisplacer Thanks for implementation efforts and careful scrutiny. Questions and potential issues/clarifications/corrections are always welcome. all the best, Don -- Don Brutzman Naval Postgraduate School, Code USW/Br brutzman at nps.edu (mailto:brutzman at nps.edu) Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149 X3D graphics, virtual worlds, navy robotics https://faculty.nps.edu/brutzman From: x3d-public on behalf of John Carlson via x3d-public Sent: Saturday, February 8, 2025 3:43 AM To: Extensible 3D (X3D) Graphics public discussion ; Carol McDonald ; Joe D Williams Cc: John Carlson ; Andreas Plesch Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point Here’s what HAnim spec says under Displacer: https://www.web3d.org/documents/specifications/19774/V2.0/index.html “For the Displacer objects that are contained in the displacers field of the Segment objects, the displacements are defined and applied in the Segment coordinate system. The base mesh for the morphed Segment is the original mesh defined in the Segment.” And here’s what it says under Segment: “ The coord field is used for Segment objects that have deformable meshes and shall contain coordinates referenced from the indexed mesh for the Segment object. The coordinates are given the same name as the Segment object, but with a "_coords" appended (e.g.,"skull_coords").” displacements are an offset from the mesh, with weight from 0 to 1. So weight times displacement is total offset from base mesh. 0 weight = no offset, 1 weight = full displacements offset The Coordinate point is maintained to handle weight = 0. Weight ranges from 0 to 1, but double check. Joe or Carol might know where to find it in the HAnim spec. I believe the answer is, “during rendering,”. Since weight can vary with animation, and so can displacements, AFAIK. More than one displacer can be applied to the mesh. I have not read the spec. John On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public wrote: https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer does not directly explain what the effect of the displacer on the coord.point field of the containing HAnimSegment is. But it mentions the coord.point field and seems to imply that the coord.point field is involved. So the question is if the Displacer should alter the coord.point field in order to achieve a graphical displacement, or if the Browser should only apply the displacements during rendering without a change in the coord.point field ? This is relevant if the coord.point field is accessed by routes or scripts, in addition to displacers. Thanks for any feedback or ideas, Andreas -- Andreas Plesch Waltham, MA 02453 _______________________________________________ x3d-public mailing list x3d-public at web3d.org (mailto:x3d-public at web3d.org) http://web3d.org/mailman/listinfo/x3d-public_web3d.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Mon Feb 10 11:09:35 2025 From: yottzumm at gmail.com (John Carlson) Date: Mon, 10 Feb 2025 13:09:35 -0600 Subject: [x3d-public] SFRotation default value spec. inconsistency In-Reply-To: References: Message-ID: Okay, Joe, I thought you were talking about some kind of lerp. John On Mon, Feb 10, 2025 at 11:58?AM Joe D Williams via x3d-public < x3d-public at web3d.org> wrote: > not zerp, zero > > -----Original Message----- > From: Extensible 3D (X3D) Graphics public discussion > > Sent: Feb 10, 2025 9:50 AM > To: Extensible 3D (X3D) Graphics public discussion , > X3D Graphics public mailing list > Cc: Joe D Williams , Andreas Plesch < > andreasplesch at gmail.com> > Subject: Re: [x3d-public] SFRotation default value spec. inconsistency > > > > I think the 0 0 1 0 should be used everywhere for default axis-angle. > > I thinkI see 'zerp' unit quaternions (as in gltf as 0 0 0 1 XYZW) > > Thanks, > > Joe > > > > -----Original Message----- > From: Extensible 3D (X3D) Graphics public discussion > > Sent: Feb 10, 2025 8:44 AM > To: X3D Graphics public mailing list > Cc: Andreas Plesch > Subject: Re: [x3d-public] SFRotation default value spec. inconsistency > > > The JS SAI spec. at > https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#FieldServices > > does not list functions for SFColorRGBA, only SFColor. There may be an > earlier report. -Andreas > > On Mon, Feb 10, 2025 at 11:31?AM Andreas Plesch > wrote: > >> >> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/fieldTypes.html#SFRotationAndMFRotation >> >> specifies that (0 0 1 0) is the value of an uninitialized SFRotation >> given as (x y z a). >> >> However, the JS SAI spec. in table 7.18 in >> https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#SFRotationInstanceCreationFunction >> >> effectively makes (0 1 0 0) the default value if no parameters are >> provided. >> >> The inconsistency does not have much of an impact since both are 0 >> rotations but I believe (0 1 0 0) - a 0 rotation around y - may have been >> intended as the default. >> >> -Andreas >> >> -- >> Andreas Plesch >> Waltham, MA 02453 >> > > > -- > Andreas Plesch > Waltham, MA 02453 > > > > > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Mon Feb 10 12:13:39 2025 From: yottzumm at gmail.com (John Carlson) Date: Mon, 10 Feb 2025 14:13:39 -0600 Subject: [x3d-public] HAnimDisplacer effect on coord.point In-Reply-To: <89c7a8a3-1da8-f9c4-b8a8-cccd72fd08f5@earthlink.net> References: <89c7a8a3-1da8-f9c4-b8a8-cccd72fd08f5@earthlink.net> Message-ID: Clarification, I actually meant the Segment coord field. I?m not sure if Site has something similar. John On Mon, Feb 10, 2025 at 12:23?PM Joe D Williams wrote: > > Perhaps we should just make the coord field optional with Segment and > Site displacers? > > > > please, no. If no coordIndex field,then no Displacer should be there. > > There are no defaults in a Displacer, there are only the same number of > index and weight and displacements entries otherwise it shold not do > anything. > > In your examples, any that are empty should be removed. Although I guess > there is the case where these are filled by some input in runtime. > > > > Thanks, > > Joe > > > > -----Original Message----- > From: Andreas Plesch > Sent: Feb 9, 2025 2:35 PM > To: John Carlson > Cc: Joe D Williams , Brutzman Donald (Don) (CIV) < > brutzman at nps.edu>, Extensible 3D (X3D) Graphics public discussion < > x3d-public at web3d.org>, Carol McDonald > Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point > > > Having a coord field is wise as it makes it unambiguous how displacers are > applied. > > The ManyClocks.x3d example has a lot of HAnimSegment nodes which are > empty, only have default values, and seem useless. > > In particular a NULL coord field invites problems. > > Probably such a node should be just ignored but it would be good to have > more specific spec. guidance, eg. allowing undefined browser behavior > similar to many other nodes. > > There is also a weird Segment node (hanim___4) which does not have > geometry and a NULL coord field, but has a displacer. The displacer is even > the target of a route. It would be good if such self in-consistent content > would be allowed to lead to undefined browser behavior as well. > > Andreas > > On Sun, Feb 9, 2025, 2:34?PM John Carlson wrote: > >> Perhaps we should just make the coord field optional with Segment and >> Site displacers? If not specified, look in HAnimHumanoid.skinCoord, or >> make the search for coords hierarchical. As Joe says, a cascade. >> >> Wondering, >> >> John >> >> On Sun, Feb 9, 2025 at 12:33?PM Andreas Plesch >> wrote: >> >>> That would be the point field of a Coordinate node >>> >>> >>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/rendering.html#Coordinate >>> >>> which is used by the coord field of >>> >>> >>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimSegment >>> >>> Andreas >>> >>> On Sun, Feb 9, 2025, 12:36?PM Joe D Williams >>> wrote: >>> >>>> > coord node emit a point_changed event >>>> >>>> >>>> >>>> sorry,I don't see a field anywhere with that event. Displacer is likely >>>> to change several points when new weight is sent. All part of the cascade >>>> to produce the changed mesh? >>>> >>>> Thanks, >>>> >>>> Joe >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Andreas Plesch >>>> Sent: Feb 9, 2025 4:25 AM >>>> To: Brutzman, Donald (Don) (CIV) >>>> Cc: Extensible 3D (X3D) Graphics public discussion < >>>> x3d-public at web3d.org>, Carol McDonald , Joe D >>>> Williams , John Carlson >>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>> >>>> >>>> Don, Joe and John >>>> >>>> Thanks for collecting these references. >>>> >>>> But I am not sure if there is an answer to my original question. Let me >>>> rephrase a bit the question: >>>> >>>> After a Displacer contained in a Segment node receives a set_weight >>>> input, should then the coord node emit a point_changed event ? >>>> >>>> I do not think HAnim is concerned about that, so it is really a X3D >>>> question. >>>> >>>> Thanks, Andreas >>>> >>>> On Sun, Feb 9, 2025, 12:49?AM Brutzman, Donald (Don) (CIV) < >>>> brutzman at nps.edu> wrote: >>>> >>>>> Thanks for pointing in the right direction John. >>>>> >>>>> Direct links to functional requirements for Displacer in HAnim 2.0 >>>>> specification: >>>>> >>>>> - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, >>>>> Clause 4 Concepts, 4.7 Displacer object >>>>> - >>>>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#DisplacerObject >>>>> >>>>> - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, >>>>> Clause 6 Object interfaces, 6.6 Displacer >>>>> - >>>>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer >>>>> >>>>> and >>>>> >>>>> - X3D 4.0 Architecture, Clause 26 Humanoid Animation (HAnim) >>>>> component, 26.3.1 HAnimDisplacer >>>>> - >>>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimDisplacer >>>>> >>>>> and informative >>>>> >>>>> - X3D Tooltips, HAnimDisplacer >>>>> - https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimDisplacer >>>>> >>>>> Thanks for implementation efforts and careful scrutiny. >>>>> >>>>> Questions and potential issues/clarifications/corrections are always >>>>> welcome. >>>>> >>>>> >>>>> 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 >>>>> https://faculty.nps.edu/brutzman >>>>> >>>>> >>>>> >>>>> ------------------------------ >>>>> *From:* x3d-public on behalf of John >>>>> Carlson via x3d-public >>>>> *Sent:* Saturday, February 8, 2025 3:43 AM >>>>> *To:* Extensible 3D (X3D) Graphics public discussion < >>>>> x3d-public at web3d.org>; Carol McDonald ; Joe D >>>>> Williams >>>>> *Cc:* John Carlson ; Andreas Plesch < >>>>> andreasplesch at gmail.com> >>>>> *Subject:* Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>> >>>>> Here?s what HAnim spec says under Displacer: >>>>> >>>>> https://www.web3d.org/documents/specifications/19774/V2.0/index.html >>>>> >>>>> ?For the *Displacer* objects that are contained in the *displacers* field >>>>> of the *Segment* objects, the *displacements* are defined and applied >>>>> in the *Segment* coordinate system. The base mesh for the morphed >>>>> *Segment* is the original mesh defined in the *Segment*.? >>>>> >>>>> And here?s what it says under Segment: >>>>> >>>>> ? >>>>> >>>>> The *coord* field is used for *Segment* objects that have deformable >>>>> meshes and shall contain coordinates referenced from the indexed mesh for >>>>> the *Segment* object. The coordinates are given the same name as the >>>>> *Segment* object, but with a "_coords" appended (e.g.,"skull_coords" >>>>> ).? >>>>> displacements are an offset from the mesh, with weight from 0 to 1. >>>>> So weight times displacement is total offset from base mesh. 0 weight = no >>>>> offset, 1 weight = full displacements offset >>>>> >>>>> The Coordinate point is maintained to handle weight = 0. Weight >>>>> ranges from 0 to 1, but double check. >>>>> >>>>> Joe or Carol might know where to find it in the HAnim spec. >>>>> >>>>> I believe the answer is, ?during rendering,?. Since weight can vary >>>>> with animation, and so can displacements, AFAIK. More than one displacer >>>>> can be applied to the mesh. >>>>> >>>>> I have not read the spec. >>>>> >>>>> John >>>>> >>>>> >>>>> >>>>> On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public < >>>>> x3d-public at web3d.org> wrote: >>>>> >>>>> >>>>> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer >>>>> >>>>> does not directly explain what the effect of the displacer on the >>>>> coord.point field of the containing HAnimSegment is. But it mentions the >>>>> coord.point field and seems to imply that the coord.point field is involved. >>>>> >>>>> So the question is if the Displacer should alter the coord.point field >>>>> in order to achieve a graphical displacement, or if the Browser should only >>>>> apply the displacements during rendering without a change in the >>>>> coord.point field ? >>>>> >>>>> This is relevant if the coord.point field is accessed by routes or >>>>> scripts, in addition to displacers. >>>>> >>>>> Thanks for any feedback or ideas, >>>>> >>>>> Andreas >>>>> >>>>> -- >>>>> Andreas Plesch >>>>> Waltham, MA 02453 >>>>> _______________________________________________ >>>>> x3d-public mailing list >>>>> x3d-public at web3d.org >>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>>> >>>>> >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreasplesch at gmail.com Mon Feb 10 12:37:10 2025 From: andreasplesch at gmail.com (Andreas Plesch) Date: Mon, 10 Feb 2025 15:37:10 -0500 Subject: [x3d-public] SFRotation default value spec. inconsistency In-Reply-To: References: Message-ID: https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#_node_rotation has indeed (0, 0, 0, 1 XYZW) as a default value. This is difficult to interpret as a rotation around an axis since the corresponding axis would be at first glance (0 0 0). x3dom converts quaternion (0, 0, 0, 1 XYZW) to (axis),angle (0,0,0),0 as does https://www.andre-gaschler.com/rotationconverter/ . On the other hand both SFRotation (0 0 1 0) and SFRotation (0 1 0 0) are also represented by quaternion (0, 0, 0, 1 XYZW). So, sensibly, a zero rotation around any axis corresponds to the "zero unit Quaternion" (0, 0, 0, 1 XYZW), making it a useful default value for quaternions. But that does not help with choosing a default axis for the SFRotation value. This will rarely matter. A use case may be when a SFRotation is initialized to the X3D default in a Proto but then only the angle is modified by a Proto script with the assumption that the axis is (0 0 1). -Andreas On Mon, Feb 10, 2025 at 12:57?PM Joe D Williams wrote: > not zerp, zero > > -----Original Message----- > From: Extensible 3D (X3D) Graphics public discussion > > Sent: Feb 10, 2025 9:50 AM > To: Extensible 3D (X3D) Graphics public discussion , > X3D Graphics public mailing list > Cc: Joe D Williams , Andreas Plesch < > andreasplesch at gmail.com> > Subject: Re: [x3d-public] SFRotation default value spec. inconsistency > > > > I think the 0 0 1 0 should be used everywhere for default axis-angle. > > I thinkI see 'zerp' unit quaternions (as in gltf as 0 0 0 1 XYZW) > > Thanks, > > Joe > > > > -----Original Message----- > From: Extensible 3D (X3D) Graphics public discussion > > Sent: Feb 10, 2025 8:44 AM > To: X3D Graphics public mailing list > Cc: Andreas Plesch > Subject: Re: [x3d-public] SFRotation default value spec. inconsistency > > > The JS SAI spec. at > https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#FieldServices > > does not list functions for SFColorRGBA, only SFColor. There may be an > earlier report. -Andreas > > On Mon, Feb 10, 2025 at 11:31?AM Andreas Plesch > wrote: > >> >> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/fieldTypes.html#SFRotationAndMFRotation >> >> specifies that (0 0 1 0) is the value of an uninitialized SFRotation >> given as (x y z a). >> >> However, the JS SAI spec. in table 7.18 in >> https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#SFRotationInstanceCreationFunction >> >> effectively makes (0 1 0 0) the default value if no parameters are >> provided. >> >> The inconsistency does not have much of an impact since both are 0 >> rotations but I believe (0 1 0 0) - a 0 rotation around y - may have been >> intended as the default. >> >> -Andreas >> >> -- >> Andreas Plesch >> Waltham, MA 02453 >> > > > -- > Andreas Plesch > Waltham, MA 02453 > > > > > -- Andreas Plesch Waltham, MA 02453 -------------- next part -------------- An HTML attachment was scrubbed... URL: From joedwil at earthlink.net Tue Feb 11 08:40:00 2025 From: joedwil at earthlink.net (Joe D Williams) Date: Tue, 11 Feb 2025 16:40:00 +0000 Subject: [x3d-public] SFRotation default value spec. inconsistency Message-ID: OK, I favor favoring the value in the prime spec, X3D Part 1. Since gltf always uses unit quaternions (that I have seen), if we import or export gltf, then 0 0 0 1 quaternion should probably result to 0 0 1 0 rather that 0 0 0 0. whoever picked 0 0 1 0 might have had a hint that axis-angle 0 0 0 0 might result in some problem sometime. Thanks, Joe ----Original Message----- From: Andreas Plesch Sent: Feb 10, 2025 12:37 PM To: Joe D Williams Cc: Extensible 3D (X3D) Graphics public discussion Subject: Re: [x3d-public] SFRotation default value spec. inconsistency https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#_node_rotation has indeed (0, 0, 0, 1 XYZW) as a default value. This is difficult to interpret as a rotation around an axis since the corresponding axis would be at first glance (0 0 0). x3dom converts quaternion (0, 0, 0, 1 XYZW) to (axis),angle (0,0,0),0 as does https://www.andre-gaschler.com/rotationconverter/ . On the other hand both SFRotation (0 0 1 0) and SFRotation (0 1 0 0) are also represented by quaternion (0, 0, 0, 1 XYZW). So, sensibly, a zero rotation around any axis corresponds to the "zero unit Quaternion" (0, 0, 0, 1 XYZW), making it a useful default value for quaternions. But that does not help with choosing a default axis for the SFRotation value. This will rarely matter. A use case may be when a SFRotation is initialized to the X3D default in a Proto but then only the angle is modified by a Proto script with the assumption that the axis is (0 0 1). -Andreas On Mon, Feb 10, 2025 at 12:57?PM Joe D Williams wrote: not zerp, zero -----Original Message----- From: Extensible 3D (X3D) Graphics public discussion Sent: Feb 10, 2025 9:50 AM To: Extensible 3D (X3D) Graphics public discussion , X3D Graphics public mailing list Cc: Joe D Williams , Andreas Plesch Subject: Re: [x3d-public] SFRotation default value spec. inconsistency I think the 0 0 1 0 should be used everywhere for default axis-angle. I thinkI see 'zerp' unit quaternions (as in gltf as 0 0 0 1 XYZW) Thanks, Joe -----Original Message----- From: Extensible 3D (X3D) Graphics public discussion Sent: Feb 10, 2025 8:44 AM To: X3D Graphics public mailing list Cc: Andreas Plesch Subject: Re: [x3d-public] SFRotation default value spec. inconsistency The JS SAI spec. at https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#FieldServices does not list functions for SFColorRGBA, only SFColor. There may be an earlier report. -Andreas On Mon, Feb 10, 2025 at 11:31?AM Andreas Plesch wrote: https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/fieldTypes.html#SFRotationAndMFRotation specifies that (0 0 1 0) is the value of an uninitialized SFRotation given as (x y z a). However, the JS SAI spec. in table 7.18 in https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#SFRotationInstanceCreationFunction effectively makes (0 1 0 0) the default value if no parameters are provided. The inconsistency does not have much of an impact since both are 0 rotations but I believe (0 1 0 0) - a 0 rotation around y - may have been intended as the default. -Andreas -- Andreas Plesch Waltham, MA 02453 -- Andreas Plesch Waltham, MA 02453 -- Andreas Plesch Waltham, MA 02453 -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Tue Feb 11 08:47:26 2025 From: yottzumm at gmail.com (John Carlson) Date: Tue, 11 Feb 2025 10:47:26 -0600 Subject: [x3d-public] SFRotation default value spec. inconsistency In-Reply-To: References: Message-ID: 0 0 0 is not an axis and it?s not normalized. On Tue, Feb 11, 2025 at 10:40?AM Joe D Williams via x3d-public < x3d-public at web3d.org> wrote: > OK, I favor favoring the value in the prime spec, X3D Part 1. Since gltf > always uses unit quaternions (that I have seen), if we import or export > gltf, then 0 0 0 1 quaternion should probably result to 0 0 1 0 rather that > 0 0 0 0. whoever picked 0 0 1 0 might have had a hint that axis-angle 0 0 0 > 0 might result in some problem sometime. > > Thanks, > > Joe > > > > ----Original Message----- > > From: Andreas Plesch > Sent: Feb 10, 2025 12:37 PM > To: Joe D Williams > Cc: Extensible 3D (X3D) Graphics public discussion > Subject: Re: [x3d-public] SFRotation default value spec. inconsistency > > > https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#_node_rotation > has indeed (0, 0, 0, 1 XYZW) as a default value. > > This is difficult to interpret as a rotation around an axis since the > corresponding axis would be at first glance (0 0 0). > > x3dom converts quaternion (0, 0, 0, 1 XYZW) to (axis),angle (0,0,0),0 as > does https://www.andre-gaschler.com/rotationconverter/ . > > On the other hand both SFRotation (0 0 1 0) and SFRotation (0 1 0 0) are > also represented by quaternion (0, 0, 0, 1 XYZW). > > So, sensibly, a zero rotation around any axis corresponds to the "zero > unit Quaternion" (0, 0, 0, 1 XYZW), making it a useful default value for > quaternions. But that does not help with choosing a default axis for the > SFRotation value. > > This will rarely matter. A use case may be when a SFRotation is > initialized to the X3D default in a Proto but then only the angle is > modified by a Proto script with the assumption that the axis is (0 0 1). > > -Andreas > > On Mon, Feb 10, 2025 at 12:57?PM Joe D Williams > wrote: > >> not zerp, zero >> >> -----Original Message----- >> From: Extensible 3D (X3D) Graphics public discussion < >> x3d-public at web3d.org> >> Sent: Feb 10, 2025 9:50 AM >> To: Extensible 3D (X3D) Graphics public discussion , >> X3D Graphics public mailing list >> Cc: Joe D Williams , Andreas Plesch < >> andreasplesch at gmail.com> >> Subject: Re: [x3d-public] SFRotation default value spec. inconsistency >> >> >> >> I think the 0 0 1 0 should be used everywhere for default axis-angle. >> >> I thinkI see 'zerp' unit quaternions (as in gltf as 0 0 0 1 XYZW) >> >> Thanks, >> >> Joe >> >> >> >> -----Original Message----- >> From: Extensible 3D (X3D) Graphics public discussion < >> x3d-public at web3d.org> >> Sent: Feb 10, 2025 8:44 AM >> To: X3D Graphics public mailing list >> Cc: Andreas Plesch >> Subject: Re: [x3d-public] SFRotation default value spec. inconsistency >> >> >> The JS SAI spec. at >> https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#FieldServices >> >> does not list functions for SFColorRGBA, only SFColor. There may be an >> earlier report. -Andreas >> >> On Mon, Feb 10, 2025 at 11:31?AM Andreas Plesch >> wrote: >> >>> >>> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/fieldTypes.html#SFRotationAndMFRotation >>> >>> specifies that (0 0 1 0) is the value of an uninitialized SFRotation >>> given as (x y z a). >>> >>> However, the JS SAI spec. in table 7.18 in >>> https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#SFRotationInstanceCreationFunction >>> >>> effectively makes (0 1 0 0) the default value if no parameters are >>> provided. >>> >>> The inconsistency does not have much of an impact since both are 0 >>> rotations but I believe (0 1 0 0) - a 0 rotation around y - may have been >>> intended as the default. >>> >>> -Andreas >>> >>> -- >>> Andreas Plesch >>> Waltham, MA 02453 >>> >> >> >> -- >> Andreas Plesch >> Waltham, MA 02453 >> >> >> >> >> > > > -- > Andreas Plesch > Waltham, MA 02453 > > > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joedwil at earthlink.net Tue Feb 11 08:54:10 2025 From: joedwil at earthlink.net (Joe D Williams) Date: Tue, 11 Feb 2025 16:54:10 +0000 Subject: [x3d-public] HAnimDisplacer effect on coord.point Message-ID: <9580a6c8-6d4c-2d3d-a01a-9b874d0023d0@earthlink.net> Well, if Site includes geometry, then it would include coord Coordinate point. So, needs testing, but if Displacer worked on that Site geometry it would be included in the Segment and the coordIndex would refer to points in the order they appear in geometry under Segment. Again, the skinCoord Coordinate point field is just there to identify skin points for Joint-driven mesh animation and have nothing to do with with Displacer. Thanks, Joe -----Original Message----- From: John Carlson Sent: Feb 10, 2025 12:20 PM To: Joe D Williams Cc: Andreas Plesch , Brutzman Donald (Don) (CIV) , Extensible 3D (X3D) Graphics public discussion , Carol McDonald Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point Clarification, I actually meant the Segment coord field. I’m not sure if Site has something similar. John On Mon, Feb 10, 2025 at 12:23?PM Joe D Williams wrote: > Perhaps we should just make the coord field optional with Segment and Site displacers? please, no. If no coordIndex field,then no Displacer should be there. There are no defaults in a Displacer, there are only the same number of index and weight and displacements entries otherwise it shold not do anything. In your examples, any that are empty should be removed. Although I guess there is the case where these are filled by some input in runtime. Thanks, Joe -----Original Message----- From: Andreas Plesch Sent: Feb 9, 2025 2:35 PM To: John Carlson Cc: Joe D Williams , Brutzman Donald (Don) (CIV) , Extensible 3D (X3D) Graphics public discussion , Carol McDonald Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point Having a coord field is wise as it makes it unambiguous how displacers are applied. The ManyClocks.x3d example has a lot of HAnimSegment nodes which are empty, only have default values, and seem useless. In particular a NULL coord field invites problems. Probably such a node should be just ignored but it would be good to have more specific spec. guidance, eg. allowing undefined browser behavior similar to many other nodes. There is also a weird Segment node (hanim___4) which does not have geometry and a NULL coord field, but has a displacer. The displacer is even the target of a route. It would be good if such self in-consistent content would be allowed to lead to undefined browser behavior as well. Andreas On Sun, Feb 9, 2025, 2:34?PM John Carlson wrote: Perhaps we should just make the coord field optional with Segment and Site displacers? If not specified, look in HAnimHumanoid.skinCoord, or make the search for coords hierarchical. As Joe says, a cascade. Wondering, John On Sun, Feb 9, 2025 at 12:33?PM Andreas Plesch wrote: That would be the point field of a Coordinate node https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/rendering.html#Coordinate which is used by the coord field of https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimSegment Andreas On Sun, Feb 9, 2025, 12:36?PM Joe D Williams wrote: > coord node emit a point_changed event sorry,I don't see a field anywhere with that event. Displacer is likely to change several points when new weight is sent. All part of the cascade to produce the changed mesh? Thanks, Joe -----Original Message----- From: Andreas Plesch Sent: Feb 9, 2025 4:25 AM To: Brutzman, Donald (Don) (CIV) Cc: Extensible 3D (X3D) Graphics public discussion , Carol McDonald , Joe D Williams , John Carlson Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point Don, Joe and John Thanks for collecting these references. But I am not sure if there is an answer to my original question. Let me rephrase a bit the question: After a Displacer contained in a Segment node receives a set_weight input, should then the coord node emit a point_changed event ? I do not think HAnim is concerned about that, so it is really a X3D question. Thanks, Andreas On Sun, Feb 9, 2025, 12:49?AM Brutzman, Donald (Don) (CIV) wrote: Thanks for pointing in the right direction John. Direct links to functional requirements for Displacer in HAnim 2.0 specification: * HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, Clause 4 Concepts, 4.7 Displacer object * https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#DisplacerObject * HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, Clause 6 Object interfaces, 6.6 Displacer * https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer and * X3D 4.0 Architecture, Clause 26 Humanoid Animation (HAnim) component, 26.3.1 HAnimDisplacer * https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimDisplacer and informative * X3D Tooltips, HAnimDisplacer * https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimDisplacer Thanks for implementation efforts and careful scrutiny. Questions and potential issues/clarifications/corrections are always welcome. all the best, Don -- Don Brutzman Naval Postgraduate School, Code USW/Br brutzman at nps.edu (mailto:brutzman at nps.edu) Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149 X3D graphics, virtual worlds, navy robotics https://faculty.nps.edu/brutzman From: x3d-public on behalf of John Carlson via x3d-public Sent: Saturday, February 8, 2025 3:43 AM To: Extensible 3D (X3D) Graphics public discussion ; Carol McDonald ; Joe D Williams Cc: John Carlson ; Andreas Plesch Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point Here’s what HAnim spec says under Displacer: https://www.web3d.org/documents/specifications/19774/V2.0/index.html “For the Displacer objects that are contained in the displacers field of the Segment objects, the displacements are defined and applied in the Segment coordinate system. The base mesh for the morphed Segment is the original mesh defined in the Segment.” And here’s what it says under Segment: “ The coord field is used for Segment objects that have deformable meshes and shall contain coordinates referenced from the indexed mesh for the Segment object. The coordinates are given the same name as the Segment object, but with a "_coords" appended (e.g.,"skull_coords").” displacements are an offset from the mesh, with weight from 0 to 1. So weight times displacement is total offset from base mesh. 0 weight = no offset, 1 weight = full displacements offset The Coordinate point is maintained to handle weight = 0. Weight ranges from 0 to 1, but double check. Joe or Carol might know where to find it in the HAnim spec. I believe the answer is, “during rendering,”. Since weight can vary with animation, and so can displacements, AFAIK. More than one displacer can be applied to the mesh. I have not read the spec. John On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public wrote: https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer does not directly explain what the effect of the displacer on the coord.point field of the containing HAnimSegment is. But it mentions the coord.point field and seems to imply that the coord.point field is involved. So the question is if the Displacer should alter the coord.point field in order to achieve a graphical displacement, or if the Browser should only apply the displacements during rendering without a change in the coord.point field ? This is relevant if the coord.point field is accessed by routes or scripts, in addition to displacers. Thanks for any feedback or ideas, Andreas -- Andreas Plesch Waltham, MA 02453 _______________________________________________ x3d-public mailing list x3d-public at web3d.org (mailto:x3d-public at web3d.org) http://web3d.org/mailman/listinfo/x3d-public_web3d.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From joedwil at earthlink.net Tue Feb 11 09:08:40 2025 From: joedwil at earthlink.net (Joe D Williams) Date: Tue, 11 Feb 2025 17:08:40 +0000 Subject: [x3d-public] SFRotation default value spec. inconsistency Message-ID: <2159974c-e7c9-49a2-36c8-c6b23c588703@earthlink.net> in general, if you have three numbers for a rotation it is talking euler angles, Sure there is a conversion to quaternions and axis-angle but we don't do that except when importing some styles of BVH, then we also need to worry about intrinsic and extrinsic rotations, and the order thereof. Thanks, Joe -----Original Message----- From: John Carlson Sent: Feb 11, 2025 8:47 AM To: Extensible 3D (X3D) Graphics public discussion Cc: Andreas Plesch , Joe D Williams Subject: Re: [x3d-public] SFRotation default value spec. inconsistency 0 0 0 is not an axis and it’s not normalized. On Tue, Feb 11, 2025 at 10:40?AM Joe D Williams via x3d-public wrote: OK, I favor favoring the value in the prime spec, X3D Part 1. Since gltf always uses unit quaternions (that I have seen), if we import or export gltf, then 0 0 0 1 quaternion should probably result to 0 0 1 0 rather that 0 0 0 0. whoever picked 0 0 1 0 might have had a hint that axis-angle 0 0 0 0 might result in some problem sometime. Thanks, Joe ----Original Message----- From: Andreas Plesch Sent: Feb 10, 2025 12:37 PM To: Joe D Williams Cc: Extensible 3D (X3D) Graphics public discussion Subject: Re: [x3d-public] SFRotation default value spec. inconsistency https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#_node_rotation has indeed (0, 0, 0, 1 XYZW) as a default value. This is difficult to interpret as a rotation around an axis since the corresponding axis would be at first glance (0 0 0). x3dom converts quaternion (0, 0, 0, 1 XYZW) to (axis),angle (0,0,0),0 as does https://www.andre-gaschler.com/rotationconverter/ . On the other hand both SFRotation (0 0 1 0) and SFRotation (0 1 0 0) are also represented by quaternion (0, 0, 0, 1 XYZW). So, sensibly, a zero rotation around any axis corresponds to the "zero unit Quaternion" (0, 0, 0, 1 XYZW), making it a useful default value for quaternions. But that does not help with choosing a default axis for the SFRotation value. This will rarely matter. A use case may be when a SFRotation is initialized to the X3D default in a Proto but then only the angle is modified by a Proto script with the assumption that the axis is (0 0 1). -Andreas On Mon, Feb 10, 2025 at 12:57?PM Joe D Williams wrote: not zerp, zero -----Original Message----- From: Extensible 3D (X3D) Graphics public discussion Sent: Feb 10, 2025 9:50 AM To: Extensible 3D (X3D) Graphics public discussion , X3D Graphics public mailing list Cc: Joe D Williams , Andreas Plesch Subject: Re: [x3d-public] SFRotation default value spec. inconsistency I think the 0 0 1 0 should be used everywhere for default axis-angle. I thinkI see 'zerp' unit quaternions (as in gltf as 0 0 0 1 XYZW) Thanks, Joe -----Original Message----- From: Extensible 3D (X3D) Graphics public discussion Sent: Feb 10, 2025 8:44 AM To: X3D Graphics public mailing list Cc: Andreas Plesch Subject: Re: [x3d-public] SFRotation default value spec. inconsistency The JS SAI spec. at https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#FieldServices does not list functions for SFColorRGBA, only SFColor. There may be an earlier report. -Andreas On Mon, Feb 10, 2025 at 11:31?AM Andreas Plesch wrote: https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/fieldTypes.html#SFRotationAndMFRotation specifies that (0 0 1 0) is the value of an uninitialized SFRotation given as (x y z a). However, the JS SAI spec. in table 7.18 in https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#SFRotationInstanceCreationFunction effectively makes (0 1 0 0) the default value if no parameters are provided. The inconsistency does not have much of an impact since both are 0 rotations but I believe (0 1 0 0) - a 0 rotation around y - may have been intended as the default. -Andreas -- Andreas Plesch Waltham, MA 02453 -- Andreas Plesch Waltham, MA 02453 -- Andreas Plesch Waltham, MA 02453 _______________________________________________ x3d-public mailing list x3d-public at web3d.org (mailto:x3d-public at web3d.org) http://web3d.org/mailman/listinfo/x3d-public_web3d.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreasplesch at gmail.com Tue Feb 11 13:40:21 2025 From: andreasplesch at gmail.com (Andreas Plesch) Date: Tue, 11 Feb 2025 16:40:21 -0500 Subject: [x3d-public] Displacer and normals ? Message-ID: I noticed that some displacers cause degenerate or flipped triangles which may cause rendering problems, mostly due to problems calculating automatically a good normal vector. In general, for best rendering results, it is necessary to provide precomputed normals. rather than rely on automatic normal calculations. Was there a discussion on how to have displacers provide precomputed normals along with the displacement of the vertices ? That would help with rendering quality, and may be necessary for some use cases. This may be deemed a long term feature to consider. Perhaps an idea would be a MFRotation normalRotations field which has the rotation required to rotate the normal (per vertex, or perhaps per face) from the rest orientation to the final orientation. Weights are applied with slerp. For animation authors it would be probably easier to be able to just directly provide the final orientation. Any feedback or comment much welcome, -Andreas -- Andreas Plesch Waltham, MA 02453 -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Tue Feb 11 13:58:40 2025 From: yottzumm at gmail.com (John Carlson) Date: Tue, 11 Feb 2025 15:58:40 -0600 Subject: [x3d-public] Displacer and normals ? In-Reply-To: References: Message-ID: Did you get the black tongue effect? I?ve seen that in Sunrize, and reported it there. Holger had a response about providing normals. The displacers were taken from CoordinateInterpolators in the HumanoidAnimation/FacialAnimation X3D archive. https://www.web3d.org/x3d/content/examples/HumanoidAnimation/FacialAnimation/index.html Perhaps we could derive normals from those examples, realizing only one set of meshes is chosen for the final version. It?s relevant, because I will be providing a unified skin mesh for FACS, and it would be nice to provide normals. On Tue, Feb 11, 2025 at 3:41?PM Andreas Plesch via x3d-public < x3d-public at web3d.org> wrote: > I noticed that some displacers cause degenerate or flipped triangles which > may cause rendering problems, mostly due to problems calculating > automatically a good normal vector. > > In general, for best rendering results, it is necessary to provide > precomputed normals. rather than rely on automatic normal calculations. Was > there a discussion on how to have displacers provide precomputed normals > along with the displacement of the vertices ? That would help with > rendering quality, and may be necessary for some use cases. > > This may be deemed a long term feature to consider. > > Perhaps an idea would be a MFRotation normalRotations field which has the > rotation required to rotate the normal (per vertex, or perhaps per face) > from the rest orientation to the final orientation. Weights are applied > with slerp. For animation authors it would be probably easier to be able to > just directly provide the final orientation. > > Any feedback or comment much welcome, -Andreas > > > -- > Andreas Plesch > Waltham, MA 02453 > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreasplesch at gmail.com Wed Feb 12 08:27:59 2025 From: andreasplesch at gmail.com (Andreas Plesch) Date: Wed, 12 Feb 2025 11:27:59 -0500 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: Message-ID: Hi, I took a first stab at Displacers in Segments for x3dom and use it now in the editor: https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/ManyClocks.x3d This is experimental and mostly for testing purposes. If there is an example combining Displacers in both Joints and Segments that would be interesting as it is not necessarily expected to work. The experimental implementation is inefficient and expensive as it is weight_changed event driven. If you activate multiple displacers the frame rate starts to drop. It probably is not very useful at this point. Fee free to give it a try, -Andreas On Wed, Feb 5, 2025, 4:11?PM Andreas Plesch wrote: > Hi John, > > Thanks. I found the tongue.x3d example but if you can create another one > that would be helpful in general. > > You vastly overestimate my ability and availability ;) This would be a > longer term project. I have an idea what to do. > > Andreas > > > On Wed, Feb 5, 2025, 1:31?PM John Carlson wrote: > >> I had one I sent to Holger, probably derived from this one: >> >> >> https://github.com/coderextreme/ci2had/blob/main/resources/JinMouthStretch.x3d >> >> >> What I would do (again) is take out all the segments but the tongue. >> >> There?s no menus involved in this one. >> >> If you need further assistance, like a smaller example, I can help. Also >> all the Jin*.x3d FACS action units can also provide examples. >> >> I?ll be pretty unbusy today. I can allocate some time for creating a >> model, make sure it animates, etc. >> >> If you?re able to allocate some time today, great, we have an HAnim >> meeting tomorrow and showing off X3DOM editor using Displacers would be >> fantastic! >> >> Remember there?s a coord field in HAnimSegment that the HAnimDisplacer >> operates on! >> >> John >> >> On Wed, Feb 5, 2025 at 12:01?PM Andreas Plesch >> wrote: >> >>> Hi John, >>> >>> The reason is that Displacers are currently implemented in x3dom only >>> for Joints, but not for Segments, unfortunately. Do you know of a simple >>> but instructive test case of Segments with Displacers ? >>> >>> Andreas >>> >>> >>> On Tue, Feb 4, 2025, 2:33?PM John Carlson wrote: >>> >>>> I will try to test this in castle model converter. >>>> >>>> I did try setting a value for the outputOnly fields, but the converter >>>> wouldn?t shut up. >>>> >>>> The model below doesn?t seem to animate when one presses the menu >>>> items. Did you get it to animate? >>>> >>>> On Tue, Feb 4, 2025 at 12:27?PM Andreas Plesch >>>> wrote: >>>> >>>>> Hi John, all, >>>>> >>>>> It turns out that x3dom currently expects a default value for Proto >>>>> fields even for outputOnly fields. This is due to how Proto fields are >>>>> initialized. They always need to have a value. While the spec. does not >>>>> require this, it seems still good practice to always define a default value >>>>> in the ProtoInterface. There may be a case where an outputOnly field is >>>>> used in ISing where a valid value would be expected. There may be other >>>>> corner cases. >>>>> >>>>> Here is your example with added default values for outputOnly fields: >>>>> >>>>> >>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/af5ff3148c1159f71d34fb78c1f63024/raw/b3d4470107ab74e301ed48448ab2a4f4154672e0/ManyClocks_John.x3d >>>>> >>>>> This could be fixed in x3dom, by always setting some default value. Is >>>>> there a list of recommended defaults for each data type if no other source >>>>> of defaults is available? For SFTime it seems to be -1. >>>>> >>>>> >>>>> -Andreas >>>>> >>>>> >>>>> On Mon, Feb 3, 2025 at 7:39?AM Andreas Plesch >>>>> wrote: >>>>> >>>>>> Hi John, >>>>>> >>>>>> On Mon, Feb 3, 2025 at 12:48?AM John Carlson >>>>>> wrote: >>>>>> >>>>>>> Andreas, "startTime" is an accessType outputOnly field, so why do I >>>>>>> need to provide a value attribute in fieldValue? I'm kind of confused. >>>>>>> I'm probably missing something in the spec. >>>>>>> >>>>>> >>>>>> You are right, I only outlined scenarios where the accessType allows >>>>>> input or initialization.. >>>>>> In the outputOnly case it is not necessary to provide a fieldValue >>>>>> node at all since there is no value which can be provided. Providing the >>>>>> node would indeed be confusing, to both the user code reader and any X3D >>>>>> browser. >>>>>> I believe the spec. is silent on this case in any encoding. >>>>>> >>>>>> Best, Andreas >>>>>> >>>>>> Thanks for any clarification. >>>>>>> >>>>>>> I have finally enabled schematron on the project, but I'm finding it >>>>>>> hard to understand the messages, and modifications that I make, while >>>>>>> removing the immediate problems, seem to move the problems elsewhere. >>>>>>> >>>>>>> Explaining why I need a "startTime" fieldValue value is my main lack >>>>>>> of understanding, but perhaps I need a whole review of accessType. >>>>>>> >>>>>>> Castle Model Converter reports: >>>>>>> >>>>>>> castle-model-converter: Warning: X3D: X3D XML: element >>>>>>> references unknown field name "enabled" >>>>>>> castle-model-converter: Warning: X3D: X3D XML: element >>>>>>> references unknown field name "startTime" >>>>>>> castle-model-converter: Warning: X3D: X3D XML: element >>>>>>> references unknown field name "stopTime" >>>>>>> >>>>>>> I will try providing a field value in the ProtoInterface >>>>>>> >>>>>>> If I "cleanup" enabled, startTime and stopTime, I get: >>>>>>> >>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>>> "MenuItem", event "inputTrue" references (by "IS" clause) non-existing >>>>>>> event "enabled" >>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) non-existing >>>>>>> event "startTime" >>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) non-existing >>>>>>> event "stopTime" >>>>>>> >>>>>>> I guess what I conclude at this point is, startTime and stopTime are >>>>>>> bad DEF names, but what about enabled as a field? The dominoes are falling. >>>>>>> >>>>>>> About your two scenarios in the other message, perhaps this is >>>>>>> revealing. >>>>>>> >>>>>>> See attached attempt to fix original issue, which resulted in the >>>>>>> above. >>>>>>> >>>>>>> John >>>>>>> >>>>>>> On Sun, Feb 2, 2025 at 3:59?PM Andreas Plesch < >>>>>>> andreasplesch at gmail.com> wrote: >>>>>>> >>>>>>>> I think x3dom, reasonably, expects a value for the fieldValue nodes: >>>>>>>> >>>>>>>> For example: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> and others. >>>>>>>> >>>>>>>> On Sun, Feb 2, 2025 at 5:42?AM John Carlson >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Andreas, Joe, >>>>>>>>> >>>>>>>>> Reset Button, Reset_Clock added. >>>>>>>>> >>>>>>>>> See attached zip for details, or visit link; >>>>>>>>> >>>>>>>>> >>>>>>>>> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>>>>> >>>>>>>>> For some reason, this link doesn't show the live scene? >>>>>>>>> >>>>>>>>> >>>>>>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>>>>> >>>>>>>>> Puzzled, haven't researched it yet. Looks good in Sunrize and >>>>>>>>> X_ITE, will try FreeWRL next. >>>>>>>>> >>>>>>>>> John >>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Andreas Plesch >>>>>>>> Waltham, MA 02453 >>>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Andreas Plesch >>>>>> Waltham, MA 02453 >>>>>> >>>>> >>>>> >>>>> -- >>>>> Andreas Plesch >>>>> Waltham, MA 02453 >>>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreasplesch at gmail.com Wed Feb 12 09:09:31 2025 From: andreasplesch at gmail.com (Andreas Plesch) Date: Wed, 12 Feb 2025 12:09:31 -0500 Subject: [x3d-public] Displacer and normals ? In-Reply-To: References: Message-ID: Responses below: > Date: Tue, 11 Feb 2025 15:58:40 -0600 > From: John Carlson > To: "Extensible 3D (X3D) Graphics public discussion" > > Subject: Re: [x3d-public] Displacer and normals ? > > Did you get the black tongue effect? I?ve seen that in Sunrize, and > reported it there. Holger had a response about providing normals. > I found https://github.com/create3000/sunrize/issues/9 Yes, I think this is similar. x-ite/sunrize just may not automatically recalculate normals for performance reasons which in some cases may be beneficial by avoiding the effects of degenerate triangles. The displacers were taken from CoordinateInterpolators in the > HumanoidAnimation/FacialAnimation X3D archive. > > https://www.web3d.org/x3d/content/examples/HumanoidAnimation/FacialAnimation/index.html > Perhaps we could derive normals from those examples, realizing only one set > of meshes is chosen for the final version. > > It?s relevant, because I will be providing a unified skin mesh for FACS, > and it would be nice to provide normals. > I noticed the effect actually only in combined displacers/morphers, eg. the Contempt combo. That brings up the future question of how pre-computed normals from multiple displacers may be combined, maybe just by averaging the slerped orientation from each. There may have been studies on how to best recombine facial subexpressions for a valid result. -Andreas > On Tue, Feb 11, 2025 at 3:41?PM Andreas Plesch via x3d-public < > x3d-public at web3d.org> wrote: > > > I noticed that some displacers cause degenerate or flipped triangles > which > > may cause rendering problems, mostly due to problems calculating > > automatically a good normal vector. > > > > In general, for best rendering results, it is necessary to provide > > precomputed normals. rather than rely on automatic normal calculations. > Was > > there a discussion on how to have displacers provide precomputed normals > > along with the displacement of the vertices ? That would help with > > rendering quality, and may be necessary for some use cases. > > > > This may be deemed a long term feature to consider. > > > > Perhaps an idea would be a MFRotation normalRotations field which has the > > rotation required to rotate the normal (per vertex, or perhaps per face) > > from the rest orientation to the final orientation. Weights are applied > > with slerp. For animation authors it would be probably easier to be able > to > > just directly provide the final orientation. > > > > Any feedback or comment much welcome, -Andreas > > > > > > -- > > Andreas Plesch > > Waltham, MA 02453 > > _______________________________________________ > > x3d-public mailing list > > x3d-public at web3d.org > > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20250211/a4be3c1a/attachment-0001.html > > > > ------------------------------ > > Message: 3 > Date: Wed, 12 Feb 2025 11:27:59 -0500 > From: Andreas Plesch > To: John Carlson > Cc: Holger Seelig , X3D Graphics public > mailing list , Joe D Williams > > Subject: Re: [x3d-public] Turning on and off simultaneous animations > individually > Message-ID: > < > CAKdk67vXRSz1pM4QLjcxuCQHfjY4LUT924cSmX7rPAasroPUCw at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi, > > I took a first stab at Displacers in Segments for x3dom and use it now in > the editor: > > > https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/ManyClocks.x3d > > This is experimental and mostly for testing purposes. If there is an > example combining Displacers in both Joints and Segments that would be > interesting as it is not necessarily expected to work. > The experimental implementation is inefficient and expensive as it is > weight_changed event driven. If you activate multiple displacers the frame > rate starts to drop. It probably is not very useful at this point. > > Fee free to give it a try, -Andreas > > On Wed, Feb 5, 2025, 4:11?PM Andreas Plesch > wrote: > > > Hi John, > > > > Thanks. I found the tongue.x3d example but if you can create another one > > that would be helpful in general. > > > > You vastly overestimate my ability and availability ;) This would be a > > longer term project. I have an idea what to do. > > > > Andreas > > > > > > On Wed, Feb 5, 2025, 1:31?PM John Carlson wrote: > > > >> I had one I sent to Holger, probably derived from this one: > >> > >> > >> > https://github.com/coderextreme/ci2had/blob/main/resources/JinMouthStretch.x3d > >> > >> > >> What I would do (again) is take out all the segments but the tongue. > >> > >> There?s no menus involved in this one. > >> > >> If you need further assistance, like a smaller example, I can help. > Also > >> all the Jin*.x3d FACS action units can also provide examples. > >> > >> I?ll be pretty unbusy today. I can allocate some time for creating a > >> model, make sure it animates, etc. > >> > >> If you?re able to allocate some time today, great, we have an HAnim > >> meeting tomorrow and showing off X3DOM editor using Displacers would be > >> fantastic! > >> > >> Remember there?s a coord field in HAnimSegment that the HAnimDisplacer > >> operates on! > >> > >> John > >> > >> On Wed, Feb 5, 2025 at 12:01?PM Andreas Plesch > > >> wrote: > >> > >>> Hi John, > >>> > >>> The reason is that Displacers are currently implemented in x3dom only > >>> for Joints, but not for Segments, unfortunately. Do you know of a > simple > >>> but instructive test case of Segments with Displacers ? > >>> > >>> Andreas > >>> > >>> > >>> On Tue, Feb 4, 2025, 2:33?PM John Carlson wrote: > >>> > >>>> I will try to test this in castle model converter. > >>>> > >>>> I did try setting a value for the outputOnly fields, but the converter > >>>> wouldn?t shut up. > >>>> > >>>> The model below doesn?t seem to animate when one presses the menu > >>>> items. Did you get it to animate? > >>>> > >>>> On Tue, Feb 4, 2025 at 12:27?PM Andreas Plesch < > andreasplesch at gmail.com> > >>>> wrote: > >>>> > >>>>> Hi John, all, > >>>>> > >>>>> It turns out that x3dom currently expects a default value for Proto > >>>>> fields even for outputOnly fields. This is due to how Proto fields > are > >>>>> initialized. They always need to have a value. While the spec. does > not > >>>>> require this, it seems still good practice to always define a > default value > >>>>> in the ProtoInterface. There may be a case where an outputOnly field > is > >>>>> used in ISing where a valid value would be expected. There may be > other > >>>>> corner cases. > >>>>> > >>>>> Here is your example with added default values for outputOnly fields: > >>>>> > >>>>> > >>>>> > https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/af5ff3148c1159f71d34fb78c1f63024/raw/b3d4470107ab74e301ed48448ab2a4f4154672e0/ManyClocks_John.x3d > >>>>> > >>>>> This could be fixed in x3dom, by always setting some default value. > Is > >>>>> there a list of recommended defaults for each data type if no other > source > >>>>> of defaults is available? For SFTime it seems to be -1. > >>>>> > >>>>> > >>>>> -Andreas > >>>>> > >>>>> > >>>>> On Mon, Feb 3, 2025 at 7:39?AM Andreas Plesch < > andreasplesch at gmail.com> > >>>>> wrote: > >>>>> > >>>>>> Hi John, > >>>>>> > >>>>>> On Mon, Feb 3, 2025 at 12:48?AM John Carlson > >>>>>> wrote: > >>>>>> > >>>>>>> Andreas, "startTime" is an accessType outputOnly field, so why do I > >>>>>>> need to provide a value attribute in fieldValue? I'm kind of > confused. > >>>>>>> I'm probably missing something in the spec. > >>>>>>> > >>>>>> > >>>>>> You are right, I only outlined scenarios where the accessType allows > >>>>>> input or initialization.. > >>>>>> In the outputOnly case it is not necessary to provide a fieldValue > >>>>>> node at all since there is no value which can be provided. > Providing the > >>>>>> node would indeed be confusing, to both the user code reader and > any X3D > >>>>>> browser. > >>>>>> I believe the spec. is silent on this case in any encoding. > >>>>>> > >>>>>> Best, Andreas > >>>>>> > >>>>>> Thanks for any clarification. > >>>>>>> > >>>>>>> I have finally enabled schematron on the project, but I'm finding > it > >>>>>>> hard to understand the messages, and modifications that I make, > while > >>>>>>> removing the immediate problems, seem to move the problems > elsewhere. > >>>>>>> > >>>>>>> Explaining why I need a "startTime" fieldValue value is my main > lack > >>>>>>> of understanding, but perhaps I need a whole review of accessType. > >>>>>>> > >>>>>>> Castle Model Converter reports: > >>>>>>> > >>>>>>> castle-model-converter: Warning: X3D: X3D XML: element > >>>>>>> references unknown field name "enabled" > >>>>>>> castle-model-converter: Warning: X3D: X3D XML: element > >>>>>>> references unknown field name "startTime" > >>>>>>> castle-model-converter: Warning: X3D: X3D XML: element > >>>>>>> references unknown field name "stopTime" > >>>>>>> > >>>>>>> I will try providing a field value in the ProtoInterface > >>>>>>> > >>>>>>> If I "cleanup" enabled, startTime and stopTime, I get: > >>>>>>> > >>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype > >>>>>>> "MenuItem", event "inputTrue" references (by "IS" clause) > non-existing > >>>>>>> event "enabled" > >>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype > >>>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) > non-existing > >>>>>>> event "startTime" > >>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype > >>>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) > non-existing > >>>>>>> event "stopTime" > >>>>>>> > >>>>>>> I guess what I conclude at this point is, startTime and stopTime > are > >>>>>>> bad DEF names, but what about enabled as a field? The dominoes > are falling. > >>>>>>> > >>>>>>> About your two scenarios in the other message, perhaps this is > >>>>>>> revealing. > >>>>>>> > >>>>>>> See attached attempt to fix original issue, which resulted in the > >>>>>>> above. > >>>>>>> > >>>>>>> John > >>>>>>> > >>>>>>> On Sun, Feb 2, 2025 at 3:59?PM Andreas Plesch < > >>>>>>> andreasplesch at gmail.com> wrote: > >>>>>>> > >>>>>>>> I think x3dom, reasonably, expects a value for the fieldValue > nodes: > >>>>>>>> > >>>>>>>> For example: > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> and others. > >>>>>>>> > >>>>>>>> On Sun, Feb 2, 2025 at 5:42?AM John Carlson > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>>> Andreas, Joe, > >>>>>>>>> > >>>>>>>>> Reset Button, Reset_Clock added. > >>>>>>>>> > >>>>>>>>> See attached zip for details, or visit link; > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d > >>>>>>>>> > >>>>>>>>> For some reason, this link doesn't show the live scene? > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d > >>>>>>>>> > >>>>>>>>> Puzzled, haven't researched it yet. Looks good in Sunrize and > >>>>>>>>> X_ITE, will try FreeWRL next. > >>>>>>>>> > >>>>>>>>> John > >>>>>>>>> > >>>>>>>>>> > >>>>>>>> > >>>>>>>> -- > >>>>>>>> Andreas Plesch > >>>>>>>> Waltham, MA 02453 > >>>>>>>> > >>>>>>> > >>>>>> > >>>>>> -- > >>>>>> Andreas Plesch > >>>>>> Waltham, MA 02453 > >>>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Andreas Plesch > >>>>> Waltham, MA 02453 > >>>>> > >>>> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20250212/6f37d6ce/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > > > ------------------------------ > > End of x3d-public Digest, Vol 191, Issue 57 > ******************************************* > -- Andreas Plesch Waltham, MA 02453 -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Wed Feb 12 12:43:12 2025 From: yottzumm at gmail.com (John Carlson) Date: Wed, 12 Feb 2025 14:43:12 -0600 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: Message-ID: This is a cleaned up version: https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d On Wed, Feb 12, 2025 at 10:28?AM Andreas Plesch wrote: > Hi, > > I took a first stab at Displacers in Segments for x3dom and use it now in > the editor: > > > https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/ManyClocks.x3d > > This is experimental and mostly for testing purposes. If there is an > example combining Displacers in both Joints and Segments that would be > interesting as it is not necessarily expected to work. > The experimental implementation is inefficient and expensive as it is > weight_changed event driven. If you activate multiple displacers the frame > rate starts to drop. It probably is not very useful at this point. > > Fee free to give it a try, -Andreas > > On Wed, Feb 5, 2025, 4:11?PM Andreas Plesch > wrote: > >> Hi John, >> >> Thanks. I found the tongue.x3d example but if you can create another one >> that would be helpful in general. >> >> You vastly overestimate my ability and availability ;) This would be a >> longer term project. I have an idea what to do. >> >> Andreas >> >> >> On Wed, Feb 5, 2025, 1:31?PM John Carlson wrote: >> >>> I had one I sent to Holger, probably derived from this one: >>> >>> >>> https://github.com/coderextreme/ci2had/blob/main/resources/JinMouthStretch.x3d >>> >>> >>> What I would do (again) is take out all the segments but the tongue. >>> >>> There?s no menus involved in this one. >>> >>> If you need further assistance, like a smaller example, I can help. >>> Also all the Jin*.x3d FACS action units can also provide examples. >>> >>> I?ll be pretty unbusy today. I can allocate some time for creating a >>> model, make sure it animates, etc. >>> >>> If you?re able to allocate some time today, great, we have an HAnim >>> meeting tomorrow and showing off X3DOM editor using Displacers would be >>> fantastic! >>> >>> Remember there?s a coord field in HAnimSegment that the HAnimDisplacer >>> operates on! >>> >>> John >>> >>> On Wed, Feb 5, 2025 at 12:01?PM Andreas Plesch >>> wrote: >>> >>>> Hi John, >>>> >>>> The reason is that Displacers are currently implemented in x3dom only >>>> for Joints, but not for Segments, unfortunately. Do you know of a simple >>>> but instructive test case of Segments with Displacers ? >>>> >>>> Andreas >>>> >>>> >>>> On Tue, Feb 4, 2025, 2:33?PM John Carlson wrote: >>>> >>>>> I will try to test this in castle model converter. >>>>> >>>>> I did try setting a value for the outputOnly fields, but the converter >>>>> wouldn?t shut up. >>>>> >>>>> The model below doesn?t seem to animate when one presses the menu >>>>> items. Did you get it to animate? >>>>> >>>>> On Tue, Feb 4, 2025 at 12:27?PM Andreas Plesch < >>>>> andreasplesch at gmail.com> wrote: >>>>> >>>>>> Hi John, all, >>>>>> >>>>>> It turns out that x3dom currently expects a default value for Proto >>>>>> fields even for outputOnly fields. This is due to how Proto fields are >>>>>> initialized. They always need to have a value. While the spec. does not >>>>>> require this, it seems still good practice to always define a default value >>>>>> in the ProtoInterface. There may be a case where an outputOnly field is >>>>>> used in ISing where a valid value would be expected. There may be other >>>>>> corner cases. >>>>>> >>>>>> Here is your example with added default values for outputOnly fields: >>>>>> >>>>>> >>>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/af5ff3148c1159f71d34fb78c1f63024/raw/b3d4470107ab74e301ed48448ab2a4f4154672e0/ManyClocks_John.x3d >>>>>> >>>>>> This could be fixed in x3dom, by always setting some default value. >>>>>> Is there a list of recommended defaults for each data type if no other >>>>>> source of defaults is available? For SFTime it seems to be -1. >>>>>> >>>>>> >>>>>> -Andreas >>>>>> >>>>>> >>>>>> On Mon, Feb 3, 2025 at 7:39?AM Andreas Plesch < >>>>>> andreasplesch at gmail.com> wrote: >>>>>> >>>>>>> Hi John, >>>>>>> >>>>>>> On Mon, Feb 3, 2025 at 12:48?AM John Carlson >>>>>>> wrote: >>>>>>> >>>>>>>> Andreas, "startTime" is an accessType outputOnly field, so why do I >>>>>>>> need to provide a value attribute in fieldValue? I'm kind of confused. >>>>>>>> I'm probably missing something in the spec. >>>>>>>> >>>>>>> >>>>>>> You are right, I only outlined scenarios where the accessType allows >>>>>>> input or initialization.. >>>>>>> In the outputOnly case it is not necessary to provide a fieldValue >>>>>>> node at all since there is no value which can be provided. Providing the >>>>>>> node would indeed be confusing, to both the user code reader and any X3D >>>>>>> browser. >>>>>>> I believe the spec. is silent on this case in any encoding. >>>>>>> >>>>>>> Best, Andreas >>>>>>> >>>>>>> Thanks for any clarification. >>>>>>>> >>>>>>>> I have finally enabled schematron on the project, but I'm finding >>>>>>>> it hard to understand the messages, and modifications that I make, while >>>>>>>> removing the immediate problems, seem to move the problems elsewhere. >>>>>>>> >>>>>>>> Explaining why I need a "startTime" fieldValue value is my main >>>>>>>> lack of understanding, but perhaps I need a whole review of accessType. >>>>>>>> >>>>>>>> Castle Model Converter reports: >>>>>>>> >>>>>>>> castle-model-converter: Warning: X3D: X3D XML: element >>>>>>>> references unknown field name "enabled" >>>>>>>> castle-model-converter: Warning: X3D: X3D XML: element >>>>>>>> references unknown field name "startTime" >>>>>>>> castle-model-converter: Warning: X3D: X3D XML: element >>>>>>>> references unknown field name "stopTime" >>>>>>>> >>>>>>>> I will try providing a field value in the ProtoInterface >>>>>>>> >>>>>>>> If I "cleanup" enabled, startTime and stopTime, I get: >>>>>>>> >>>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>>>> "MenuItem", event "inputTrue" references (by "IS" clause) non-existing >>>>>>>> event "enabled" >>>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) non-existing >>>>>>>> event "startTime" >>>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) non-existing >>>>>>>> event "stopTime" >>>>>>>> >>>>>>>> I guess what I conclude at this point is, startTime and stopTime >>>>>>>> are bad DEF names, but what about enabled as a field? The dominoes are >>>>>>>> falling. >>>>>>>> >>>>>>>> About your two scenarios in the other message, perhaps this is >>>>>>>> revealing. >>>>>>>> >>>>>>>> See attached attempt to fix original issue, which resulted in the >>>>>>>> above. >>>>>>>> >>>>>>>> John >>>>>>>> >>>>>>>> On Sun, Feb 2, 2025 at 3:59?PM Andreas Plesch < >>>>>>>> andreasplesch at gmail.com> wrote: >>>>>>>> >>>>>>>>> I think x3dom, reasonably, expects a value for the fieldValue >>>>>>>>> nodes: >>>>>>>>> >>>>>>>>> For example: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> and others. >>>>>>>>> >>>>>>>>> On Sun, Feb 2, 2025 at 5:42?AM John Carlson >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Andreas, Joe, >>>>>>>>>> >>>>>>>>>> Reset Button, Reset_Clock added. >>>>>>>>>> >>>>>>>>>> See attached zip for details, or visit link; >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>>>>>> >>>>>>>>>> For some reason, this link doesn't show the live scene? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>>>>>> >>>>>>>>>> Puzzled, haven't researched it yet. Looks good in Sunrize and >>>>>>>>>> X_ITE, will try FreeWRL next. >>>>>>>>>> >>>>>>>>>> John >>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Andreas Plesch >>>>>>>>> Waltham, MA 02453 >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Andreas Plesch >>>>>>> Waltham, MA 02453 >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Andreas Plesch >>>>>> Waltham, MA 02453 >>>>>> >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From joedwil at earthlink.net Wed Feb 12 19:57:16 2025 From: joedwil at earthlink.net (Joe D Williams) Date: Thu, 13 Feb 2025 03:57:16 +0000 Subject: [x3d-public] Displacer and normals ? Message-ID: I think degenerate triangles, ones that flip from ccw to cw, or overlap or whatever messes up a triangle when any of all of its points get moved is purely result of author error(s) in setting the parameter(s). Whatever happens with normals of triangles moved or destroyed by Displacer must match what happens with points moved by joint-driven skin animations which can also mess up, and by points moved by CoordinateInterpolator, same as any morphing operation. Normals can also be set by the author each frame if desired. Maybe some help given in authortime but not any sort of enumerated error except undefined in runtime since this visual effect; it is just an artifact of bad data. Esp likey when deformable face is actually composed of multiple shapes and they must blend regardless of the combinations of shapes that move to make the motion for a pose. Always? much easier with single basic mesh for the face and and then add features and accessories animated individually? One of the limitations with Displacer is that it is just a single scaled 3D vector, meaning it has a fixed relative direction regardless of the weight applied. When a curved displacement is required, then point motion can be controlled using joint rotation, like the eyeball. In some cases,a CoordinateInterpolator may be used to move points around. Texture position and rotation can be animated. Since all these Displacer nodes have been produced by finding the simple 3D vector difference between the first and last data point of a source CoordinateInterpolator it is likely that some displacements do not produce exact same movement of a point just because the original interpolator keyValue keyframe data points described a curved path. Sure, we can update the 3D vector direction each frame if we want to, but I would like to see a Displacer which could use multiple sets of vectors interpolated to produce computed keyframes like other interpolators. For each point there could be a set of vectors where the output value for point movement is the result of interpolation between adjacent key time (weight) keyValue 3D vectors. So, more fun with x3d HAnim Thanks, Joe -----Original Message----- From: Extensible 3D (X3D) Graphics public discussion Sent: Feb 12, 2025 9:11 AM To: X3D Graphics public mailing list Cc: Andreas Plesch Subject: Re: [x3d-public] Displacer and normals ? Responses below: Date: Tue, 11 Feb 2025 15:58:40 -0600 From: John Carlson To: "Extensible 3D (X3D) Graphics public discussion" Subject: Re: [x3d-public] Displacer and normals ? Did you get the black tongue effect? I?ve seen that in Sunrize, and reported it there. Holger had a response about providing normals. I found https://github.com/create3000/sunrize/issues/9 Yes, I think this is similar. x-ite/sunrize just may not automatically recalculate normals for performance reasons which in some cases may be beneficial by avoiding the effects of degenerate triangles. The displacers were taken from CoordinateInterpolators in the HumanoidAnimation/FacialAnimation X3D archive. https://www.web3d.org/x3d/content/examples/HumanoidAnimation/FacialAnimation/index.html Perhaps we could derive normals from those examples, realizing only one set of meshes is chosen for the final version. It?s relevant, because I will be providing a unified skin mesh for FACS, and it would be nice to provide normals. I noticed the effect actually only in combined displacers/morphers, eg. the Contempt combo. That brings up the future question of how pre-computed normals from multiple displacers may be combined, maybe just by averaging the slerped orientation from each. There may have been studies on how to best recombine facial subexpressions for a valid result. -Andreas On Tue, Feb 11, 2025 at 3:41?PM Andreas Plesch via x3d-public < x3d-public at web3d.org (mailto:x3d-public at web3d.org)> wrote: > I noticed that some displacers cause degenerate or flipped triangles which > may cause rendering problems, mostly due to problems calculating > automatically a good normal vector. > > In general, for best rendering results, it is necessary to provide > precomputed normals. rather than rely on automatic normal calculations. Was > there a discussion on how to have displacers provide precomputed normals > along with the displacement of the vertices ? That would help with > rendering quality, and may be necessary for some use cases. > > This may be deemed a long term feature to consider. > > Perhaps an idea would be a MFRotation normalRotations field which has the > rotation required to rotate the normal (per vertex, or perhaps per face) > from the rest orientation to the final orientation. Weights are applied > with slerp. For animation authors it would be probably easier to be able to > just directly provide the final orientation. > > Any feedback or comment much welcome, -Andreas > > > -- > Andreas Plesch > Waltham, MA 02453 > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org (mailto:x3d-public at web3d.org) > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Wed, 12 Feb 2025 11:27:59 -0500 From: Andreas Plesch To: John Carlson Cc: Holger Seelig , X3D Graphics public mailing list , Joe D Williams Subject: Re: [x3d-public] Turning on and off simultaneous animations individually Message-ID: Content-Type: text/plain; charset="utf-8" Hi, I took a first stab at Displacers in Segments for x3dom and use it now in the editor: https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/ManyClocks.x3d This is experimental and mostly for testing purposes. If there is an example combining Displacers in both Joints and Segments that would be interesting as it is not necessarily expected to work. The experimental implementation is inefficient and expensive as it is weight_changed event driven. If you activate multiple displacers the frame rate starts to drop. It probably is not very useful at this point. Fee free to give it a try, -Andreas On Wed, Feb 5, 2025, 4:11?PM Andreas Plesch wrote: > Hi John, > > Thanks. I found the tongue.x3d example but if you can create another one > that would be helpful in general. > > You vastly overestimate my ability and availability ;) This would be a > longer term project. I have an idea what to do. > > Andreas > > > On Wed, Feb 5, 2025, 1:31?PM John Carlson wrote: > >> I had one I sent to Holger, probably derived from this one: >> >> >> https://github.com/coderextreme/ci2had/blob/main/resources/JinMouthStretch.x3d >> >> >> What I would do (again) is take out all the segments but the tongue. >> >> There?s no menus involved in this one. >> >> If you need further assistance, like a smaller example, I can help. Also >> all the Jin*.x3d FACS action units can also provide examples. >> >> I?ll be pretty unbusy today. I can allocate some time for creating a >> model, make sure it animates, etc. >> >> If you?re able to allocate some time today, great, we have an HAnim >> meeting tomorrow and showing off X3DOM editor using Displacers would be >> fantastic! >> >> Remember there?s a coord field in HAnimSegment that the HAnimDisplacer >> operates on! >> >> John >> >> On Wed, Feb 5, 2025 at 12:01?PM Andreas Plesch >> wrote: >> >>> Hi John, >>> >>> The reason is that Displacers are currently implemented in x3dom only >>> for Joints, but not for Segments, unfortunately. Do you know of a simple >>> but instructive test case of Segments with Displacers ? >>> >>> Andreas >>> >>> >>> On Tue, Feb 4, 2025, 2:33?PM John Carlson wrote: >>> >>>> I will try to test this in castle model converter. >>>> >>>> I did try setting a value for the outputOnly fields, but the converter >>>> wouldn?t shut up. >>>> >>>> The model below doesn?t seem to animate when one presses the menu >>>> items. Did you get it to animate? >>>> >>>> On Tue, Feb 4, 2025 at 12:27?PM Andreas Plesch >>>> wrote: >>>> >>>>> Hi John, all, >>>>> >>>>> It turns out that x3dom currently expects a default value for Proto >>>>> fields even for outputOnly fields. This is due to how Proto fields are >>>>> initialized. They always need to have a value. While the spec. does not >>>>> require this, it seems still good practice to always define a default value >>>>> in the ProtoInterface. There may be a case where an outputOnly field is >>>>> used in ISing where a valid value would be expected. There may be other >>>>> corner cases. >>>>> >>>>> Here is your example with added default values for outputOnly fields: >>>>> >>>>> >>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/af5ff3148c1159f71d34fb78c1f63024/raw/b3d4470107ab74e301ed48448ab2a4f4154672e0/ManyClocks_John.x3d >>>>> >>>>> This could be fixed in x3dom, by always setting some default value. Is >>>>> there a list of recommended defaults for each data type if no other source >>>>> of defaults is available? For SFTime it seems to be -1. >>>>> >>>>> >>>>> -Andreas >>>>> >>>>> >>>>> On Mon, Feb 3, 2025 at 7:39?AM Andreas Plesch >>>>> wrote: >>>>> >>>>>> Hi John, >>>>>> >>>>>> On Mon, Feb 3, 2025 at 12:48?AM John Carlson >>>>>> wrote: >>>>>> >>>>>>> Andreas, "startTime" is an accessType outputOnly field, so why do I >>>>>>> need to provide a value attribute in fieldValue? I'm kind of confused. >>>>>>> I'm probably missing something in the spec. >>>>>>> >>>>>> >>>>>> You are right, I only outlined scenarios where the accessType allows >>>>>> input or initialization.. >>>>>> In the outputOnly case it is not necessary to provide a fieldValue >>>>>> node at all since there is no value which can be provided. Providing the >>>>>> node would indeed be confusing, to both the user code reader and any X3D >>>>>> browser. >>>>>> I believe the spec. is silent on this case in any encoding. >>>>>> >>>>>> Best, Andreas >>>>>> >>>>>> Thanks for any clarification. >>>>>>> >>>>>>> I have finally enabled schematron on the project, but I'm finding it >>>>>>> hard to understand the messages, and modifications that I make, while >>>>>>> removing the immediate problems, seem to move the problems elsewhere. >>>>>>> >>>>>>> Explaining why I need a "startTime" fieldValue value is my main lack >>>>>>> of understanding, but perhaps I need a whole review of accessType. >>>>>>> >>>>>>> Castle Model Converter reports: >>>>>>> >>>>>>> castle-model-converter: Warning: X3D: X3D XML: element >>>>>>> references unknown field name "enabled" >>>>>>> castle-model-converter: Warning: X3D: X3D XML: element >>>>>>> references unknown field name "startTime" >>>>>>> castle-model-converter: Warning: X3D: X3D XML: element >>>>>>> references unknown field name "stopTime" >>>>>>> >>>>>>> I will try providing a field value in the ProtoInterface >>>>>>> >>>>>>> If I "cleanup" enabled, startTime and stopTime, I get: >>>>>>> >>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>>> "MenuItem", event "inputTrue" references (by "IS" clause) non-existing >>>>>>> event "enabled" >>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) non-existing >>>>>>> event "startTime" >>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) non-existing >>>>>>> event "stopTime" >>>>>>> >>>>>>> I guess what I conclude at this point is, startTime and stopTime are >>>>>>> bad DEF names, but what about enabled as a field? The dominoes are falling. >>>>>>> >>>>>>> About your two scenarios in the other message, perhaps this is >>>>>>> revealing. >>>>>>> >>>>>>> See attached attempt to fix original issue, which resulted in the >>>>>>> above. >>>>>>> >>>>>>> John >>>>>>> >>>>>>> On Sun, Feb 2, 2025 at 3:59?PM Andreas Plesch < >>>>>>> andreasplesch at gmail.com (mailto:andreasplesch at gmail.com)> wrote: >>>>>>> >>>>>>>> I think x3dom, reasonably, expects a value for the fieldValue nodes: >>>>>>>> >>>>>>>> For example: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> and others. >>>>>>>> >>>>>>>> On Sun, Feb 2, 2025 at 5:42?AM John Carlson >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Andreas, Joe, >>>>>>>>> >>>>>>>>> Reset Button, Reset_Clock added. >>>>>>>>> >>>>>>>>> See attached zip for details, or visit link; >>>>>>>>> >>>>>>>>> >>>>>>>>> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>>>>> >>>>>>>>> For some reason, this link doesn't show the live scene? >>>>>>>>> >>>>>>>>> >>>>>>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>>>>> >>>>>>>>> Puzzled, haven't researched it yet. Looks good in Sunrize and >>>>>>>>> X_ITE, will try FreeWRL next. >>>>>>>>> >>>>>>>>> John >>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Andreas Plesch >>>>>>>> Waltham, MA 02453 >>>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Andreas Plesch >>>>>> Waltham, MA 02453 >>>>>> >>>>> >>>>> >>>>> -- >>>>> Andreas Plesch >>>>> Waltham, MA 02453 >>>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ x3d-public mailing list x3d-public at web3d.org (mailto:x3d-public at web3d.org) http://web3d.org/mailman/listinfo/x3d-public_web3d.org ------------------------------ End of x3d-public Digest, Vol 191, Issue 57 ******************************************* -- Andreas Plesch Waltham, MA 02453 -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Thu Feb 13 00:12:31 2025 From: yottzumm at gmail.com (John Carlson) Date: Thu, 13 Feb 2025 02:12:31 -0600 Subject: [x3d-public] Displacer and normals ? In-Reply-To: References: Message-ID: I?ll be working on creating a unified mesh at some point, and probably be pointing all the HAnimSegment.coord fields at it, rather than using HAnimHumanoid.skinCoord. Once we figure out how to animate joints for FACS, then we can move to animation that?s both joint and segment based. I haven?t seen a way to create joint animations from our data yet, so creating eyeball, eyebrow, eyelid, etc. joints is not quite appropriate yet. Perhaps a good start would be to rename head bones from the complex rig in Blender and do another export, perhaps with a skin I create from FACS data. Note that creating a unified FACS is top on my to do list. I?m not sure how to merge the triangles yet, except through concatenation, so I probably won?t be trying to reduce the number of points initially. This is probably best done once we have a single mesh, and probably the coordIndex field should be maintained after merging??? On Wed, Feb 12, 2025 at 9:58?PM Joe D Williams via x3d-public < x3d-public at web3d.org> wrote: > I think degenerate triangles, ones that flip from ccw to cw, or overlap or > > whatever messes up a triangle when any of all of its points get moved > > is purely result of author error(s) in setting the parameter(s). > > > > Whatever happens with normals of triangles moved or destroyed by Displacer > > must match what happens with points moved by joint-driven skin animations > > which can also mess up, and by points moved by CoordinateInterpolator, > > same as any morphing operation. > > Normals can also be set by the author each frame if desired. > > > > Maybe some help given in authortime but not any sort of > > enumerated error except undefined in runtime since this visual effect; > > it is just an artifact of bad data. > > Esp likey when deformable face is actually composed of multiple shapes > > and they must blend regardless of the combinations of shapes > > that move to make the motion for a pose. > > Always? much easier with single basic mesh for the face and and then > > add features and accessories animated individually? > > > > One of the limitations with Displacer is that it is just a single scaled > 3D vector, > > meaning it has a fixed relative direction regardless of the weight > applied. > > When a curved displacement is required, then point motion can be > > controlled using joint rotation, like the eyeball. > > In some cases,a CoordinateInterpolator may be used to move points around. > > Texture position and rotation can be animated. > > > > Since all these Displacer nodes have been produced by finding the > > simple 3D vector difference between the first and last data point > > of a source CoordinateInterpolator it is likely that some displacements > > do not produce exact same movement of a point just because the > > original interpolator keyValue keyframe data points described a curved > path. > > > > Sure, we can update the 3D vector direction each frame if we want to, > > but I would like to see a Displacer which could use multiple sets of > vectors > > interpolated to produce computed keyframes like other interpolators. > > For each point there could be a set of vectors where the output value for > > point movement is the result of interpolation between > > adjacent key time (weight) keyValue 3D vectors. > > > > So, more fun with x3d HAnim > > Thanks, > > Joe > > > > > > -----Original Message----- > From: Extensible 3D (X3D) Graphics public discussion > > Sent: Feb 12, 2025 9:11 AM > To: X3D Graphics public mailing list > Cc: Andreas Plesch > Subject: Re: [x3d-public] Displacer and normals ? > > > > Responses below: > > >> Date: Tue, 11 Feb 2025 15:58:40 -0600 >> From: John Carlson >> To: "Extensible 3D (X3D) Graphics public discussion" >> >> Subject: Re: [x3d-public] Displacer and normals ? >> >> Did you get the black tongue effect? I?ve seen that in Sunrize, and >> reported it there. Holger had a response about providing normals. > > > I found https://github.com/create3000/sunrize/issues/9 > > Yes, I think this is similar. x-ite/sunrize just may not automatically > recalculate normals for performance reasons which in some cases may be > beneficial by avoiding the effects of degenerate triangles. > > >> The displacers were taken from CoordinateInterpolators in the >> HumanoidAnimation/FacialAnimation X3D archive. >> >> https://www.web3d.org/x3d/content/examples/HumanoidAnimation/FacialAnimation/index.html >> Perhaps we could derive normals from those examples, realizing only one >> set >> of meshes is chosen for the final version. >> >> It?s relevant, because I will be providing a unified skin mesh for FACS, >> and it would be nice to provide normals. > > > I noticed the effect actually only in combined displacers/morphers, eg. > the Contempt combo. That brings up the future question of how pre-computed > normals from multiple displacers may be combined, maybe just by averaging > the slerped orientation from each. > There may have been studies on how to best recombine facial subexpressions > for a valid result. > > -Andreas > > >> >> On Tue, Feb 11, 2025 at 3:41?PM Andreas Plesch via x3d-public < >> x3d-public at web3d.org> wrote: >> >> > I noticed that some displacers cause degenerate or flipped triangles >> which >> > may cause rendering problems, mostly due to problems calculating >> > automatically a good normal vector. >> > >> > In general, for best rendering results, it is necessary to provide >> > precomputed normals. rather than rely on automatic normal calculations. >> Was >> > there a discussion on how to have displacers provide precomputed normals >> > along with the displacement of the vertices ? That would help with >> > rendering quality, and may be necessary for some use cases. >> > >> > This may be deemed a long term feature to consider. >> > >> > Perhaps an idea would be a MFRotation normalRotations field which has >> the >> > rotation required to rotate the normal (per vertex, or perhaps per face) >> > from the rest orientation to the final orientation. Weights are applied >> > with slerp. For animation authors it would be probably easier to be >> able to >> > just directly provide the final orientation. >> > >> > Any feedback or comment much welcome, -Andreas >> > >> > >> > -- >> > Andreas Plesch >> > Waltham, MA 02453 >> > _______________________________________________ >> > x3d-public mailing list >> > x3d-public at web3d.org >> > http://web3d.org/mailman/listinfo/x3d-public_web3d.org >> > >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20250211/a4be3c1a/attachment-0001.html >> > >> >> ------------------------------ >> >> Message: 3 >> Date: Wed, 12 Feb 2025 11:27:59 -0500 >> From: Andreas Plesch >> To: John Carlson >> Cc: Holger Seelig , X3D Graphics public >> mailing list , Joe D Williams >> >> Subject: Re: [x3d-public] Turning on and off simultaneous animations >> individually >> Message-ID: >> < >> CAKdk67vXRSz1pM4QLjcxuCQHfjY4LUT924cSmX7rPAasroPUCw at mail.gmail.com> >> Content-Type: text/plain; charset="utf-8" >> >> Hi, >> >> I took a first stab at Displacers in Segments for x3dom and use it now in >> the editor: >> >> >> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/ManyClocks.x3d >> >> This is experimental and mostly for testing purposes. If there is an >> example combining Displacers in both Joints and Segments that would be >> interesting as it is not necessarily expected to work. >> The experimental implementation is inefficient and expensive as it is >> weight_changed event driven. If you activate multiple displacers the frame >> rate starts to drop. It probably is not very useful at this point. >> >> Fee free to give it a try, -Andreas >> >> On Wed, Feb 5, 2025, 4:11?PM Andreas Plesch >> wrote: >> >> > Hi John, >> > >> > Thanks. I found the tongue.x3d example but if you can create another one >> > that would be helpful in general. >> > >> > You vastly overestimate my ability and availability ;) This would be a >> > longer term project. I have an idea what to do. >> > >> > Andreas >> > >> > >> > On Wed, Feb 5, 2025, 1:31?PM John Carlson wrote: >> > >> >> I had one I sent to Holger, probably derived from this one: >> >> >> >> >> >> >> https://github.com/coderextreme/ci2had/blob/main/resources/JinMouthStretch.x3d >> >> >> >> >> >> What I would do (again) is take out all the segments but the tongue. >> >> >> >> There?s no menus involved in this one. >> >> >> >> If you need further assistance, like a smaller example, I can help. >> Also >> >> all the Jin*.x3d FACS action units can also provide examples. >> >> >> >> I?ll be pretty unbusy today. I can allocate some time for creating a >> >> model, make sure it animates, etc. >> >> >> >> If you?re able to allocate some time today, great, we have an HAnim >> >> meeting tomorrow and showing off X3DOM editor using Displacers would be >> >> fantastic! >> >> >> >> Remember there?s a coord field in HAnimSegment that the HAnimDisplacer >> >> operates on! >> >> >> >> John >> >> >> >> On Wed, Feb 5, 2025 at 12:01?PM Andreas Plesch < >> andreasplesch at gmail.com> >> >> wrote: >> >> >> >>> Hi John, >> >>> >> >>> The reason is that Displacers are currently implemented in x3dom only >> >>> for Joints, but not for Segments, unfortunately. Do you know of a >> simple >> >>> but instructive test case of Segments with Displacers ? >> >>> >> >>> Andreas >> >>> >> >>> >> >>> On Tue, Feb 4, 2025, 2:33?PM John Carlson wrote: >> >>> >> >>>> I will try to test this in castle model converter. >> >>>> >> >>>> I did try setting a value for the outputOnly fields, but the >> converter >> >>>> wouldn?t shut up. >> >>>> >> >>>> The model below doesn?t seem to animate when one presses the menu >> >>>> items. Did you get it to animate? >> >>>> >> >>>> On Tue, Feb 4, 2025 at 12:27?PM Andreas Plesch < >> andreasplesch at gmail.com> >> >>>> wrote: >> >>>> >> >>>>> Hi John, all, >> >>>>> >> >>>>> It turns out that x3dom currently expects a default value for Proto >> >>>>> fields even for outputOnly fields. This is due to how Proto fields >> are >> >>>>> initialized. They always need to have a value. While the spec. does >> not >> >>>>> require this, it seems still good practice to always define a >> default value >> >>>>> in the ProtoInterface. There may be a case where an outputOnly >> field is >> >>>>> used in ISing where a valid value would be expected. There may be >> other >> >>>>> corner cases. >> >>>>> >> >>>>> Here is your example with added default values for outputOnly >> fields: >> >>>>> >> >>>>> >> >>>>> >> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/af5ff3148c1159f71d34fb78c1f63024/raw/b3d4470107ab74e301ed48448ab2a4f4154672e0/ManyClocks_John.x3d >> >>>>> >> >>>>> This could be fixed in x3dom, by always setting some default value. >> Is >> >>>>> there a list of recommended defaults for each data type if no other >> source >> >>>>> of defaults is available? For SFTime it seems to be -1. >> >>>>> >> >>>>> >> >>>>> -Andreas >> >>>>> >> >>>>> >> >>>>> On Mon, Feb 3, 2025 at 7:39?AM Andreas Plesch < >> andreasplesch at gmail.com> >> >>>>> wrote: >> >>>>> >> >>>>>> Hi John, >> >>>>>> >> >>>>>> On Mon, Feb 3, 2025 at 12:48?AM John Carlson >> >>>>>> wrote: >> >>>>>> >> >>>>>>> Andreas, "startTime" is an accessType outputOnly field, so why do >> I >> >>>>>>> need to provide a value attribute in fieldValue? I'm kind of >> confused. >> >>>>>>> I'm probably missing something in the spec. >> >>>>>>> >> >>>>>> >> >>>>>> You are right, I only outlined scenarios where the accessType >> allows >> >>>>>> input or initialization.. >> >>>>>> In the outputOnly case it is not necessary to provide a fieldValue >> >>>>>> node at all since there is no value which can be provided. >> Providing the >> >>>>>> node would indeed be confusing, to both the user code reader and >> any X3D >> >>>>>> browser. >> >>>>>> I believe the spec. is silent on this case in any encoding. >> >>>>>> >> >>>>>> Best, Andreas >> >>>>>> >> >>>>>> Thanks for any clarification. >> >>>>>>> >> >>>>>>> I have finally enabled schematron on the project, but I'm finding >> it >> >>>>>>> hard to understand the messages, and modifications that I make, >> while >> >>>>>>> removing the immediate problems, seem to move the problems >> elsewhere. >> >>>>>>> >> >>>>>>> Explaining why I need a "startTime" fieldValue value is my main >> lack >> >>>>>>> of understanding, but perhaps I need a whole review of accessType. >> >>>>>>> >> >>>>>>> Castle Model Converter reports: >> >>>>>>> >> >>>>>>> castle-model-converter: Warning: X3D: X3D XML: >> element >> >>>>>>> references unknown field name "enabled" >> >>>>>>> castle-model-converter: Warning: X3D: X3D XML: >> element >> >>>>>>> references unknown field name "startTime" >> >>>>>>> castle-model-converter: Warning: X3D: X3D XML: >> element >> >>>>>>> references unknown field name "stopTime" >> >>>>>>> >> >>>>>>> I will try providing a field value in the ProtoInterface >> >>>>>>> >> >>>>>>> If I "cleanup" enabled, startTime and stopTime, I get: >> >>>>>>> >> >>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >> >>>>>>> "MenuItem", event "inputTrue" references (by "IS" clause) >> non-existing >> >>>>>>> event "enabled" >> >>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >> >>>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) >> non-existing >> >>>>>>> event "startTime" >> >>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >> >>>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) >> non-existing >> >>>>>>> event "stopTime" >> >>>>>>> >> >>>>>>> I guess what I conclude at this point is, startTime and stopTime >> are >> >>>>>>> bad DEF names, but what about enabled as a field? The dominoes >> are falling. >> >>>>>>> >> >>>>>>> About your two scenarios in the other message, perhaps this is >> >>>>>>> revealing. >> >>>>>>> >> >>>>>>> See attached attempt to fix original issue, which resulted in the >> >>>>>>> above. >> >>>>>>> >> >>>>>>> John >> >>>>>>> >> >>>>>>> On Sun, Feb 2, 2025 at 3:59?PM Andreas Plesch < >> >>>>>>> andreasplesch at gmail.com> wrote: >> >>>>>>> >> >>>>>>>> I think x3dom, reasonably, expects a value for the fieldValue >> nodes: >> >>>>>>>> >> >>>>>>>> For example: >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> and others. >> >>>>>>>> >> >>>>>>>> On Sun, Feb 2, 2025 at 5:42?AM John Carlson >> >>>>>>>> wrote: >> >>>>>>>> >> >>>>>>>>> Andreas, Joe, >> >>>>>>>>> >> >>>>>>>>> Reset Button, Reset_Clock added. >> >>>>>>>>> >> >>>>>>>>> See attached zip for details, or visit link; >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >> >>>>>>>>> >> >>>>>>>>> For some reason, this link doesn't show the live scene? >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >> >>>>>>>>> >> >>>>>>>>> Puzzled, haven't researched it yet. Looks good in Sunrize and >> >>>>>>>>> X_ITE, will try FreeWRL next. >> >>>>>>>>> >> >>>>>>>>> John >> >>>>>>>>> >> >>>>>>>>>> >> >>>>>>>> >> >>>>>>>> -- >> >>>>>>>> Andreas Plesch >> >>>>>>>> Waltham, MA 02453 >> >>>>>>>> >> >>>>>>> >> >>>>>> >> >>>>>> -- >> >>>>>> Andreas Plesch >> >>>>>> Waltham, MA 02453 >> >>>>>> >> >>>>> >> >>>>> >> >>>>> -- >> >>>>> Andreas Plesch >> >>>>> Waltham, MA 02453 >> >>>>> >> >>>> >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20250212/6f37d6ce/attachment.html >> > >> >> ------------------------------ >> >> Subject: Digest Footer >> >> _______________________________________________ >> x3d-public mailing list >> x3d-public at web3d.org >> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >> >> >> ------------------------------ >> >> End of x3d-public Digest, Vol 191, Issue 57 >> ******************************************* > > > > -- > Andreas Plesch > Waltham, MA 02453 > > > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Thu Feb 13 02:28:03 2025 From: yottzumm at gmail.com (John Carlson) Date: Thu, 13 Feb 2025 04:28:03 -0600 Subject: [x3d-public] Ant based schematron example Message-ID: I don?t think I mentioned this yet. I have a small ant build.xml schematron example that can be used in batch mode instead of relying on one-at-a-time mode in X3D-Edit. https://github.com/coderextreme/ci2had/blob/main/build.xml If someone has schematron working for DOM, let us know. I?m pretty sure sourceforge has batch schematron, but I?ve not figured it out yet. Ultimately, I?d like to use X3DJSONLD and run schematron on JSON via DOM. -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Thu Feb 13 03:14:38 2025 From: yottzumm at gmail.com (John Carlson) Date: Thu, 13 Feb 2025 05:14:38 -0600 Subject: [x3d-public] Wind Turbine future IEC standard based on JSONSchema Message-ID: I was stumbling through Slack and found this: https://github.com/octue/power-curve-schema?tab=readme-ov-file Apparently, they use some form of JSON schema. To be standardized by the IEC. John -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreasplesch at gmail.com Thu Feb 13 13:13:29 2025 From: andreasplesch at gmail.com (Andreas Plesch) Date: Thu, 13 Feb 2025 16:13:29 -0500 Subject: [x3d-public] Displacer and normals ? In-Reply-To: References: Message-ID: Indeed, author errors do not need to be addressed by functionality, and rarely even could be without mindreading. "Normals can also be set by the author each frame if desired." This is true outside of Displacers using Interpolators and maybe this is all that is needed. I was thinking more about Displacers and augmenting vertex displacements with normal "displacements" for cases where automatic recalculation of normals based on the current orientation of triangles is not satisfactory but these cases may be rare. However, it is common practice, I believe, to provide normals with each model and animation frame. To me, segment displacers seem to be designed for the use case of minor geometric adjustment where linear paths would often work. Larger deformation or animation seem to be better addressed by joints and skinning. It would be probably feasible from an implementation perspective to have displacers with weight (key) ranges for piecewise linear interpolations to approximate curved displacement paths. Thinking about it, it may already be possible to design a CoordinateInterpolator of _displacement_ keyValues which gets routed to the displacement field of a displacer, with a constant weight of 1. So animation then happens by changing displacement values directly rather than weight values. This would allow for arbitrary displacement paths and does not need any changes, still allowing targeting vertex subsets and composing. Might be worth testing, seems interesting. -Andreas On Wed, Feb 12, 2025 at 10:58?PM Joe D Williams wrote: > I think degenerate triangles, ones that flip from ccw to cw, or overlap or > > whatever messes up a triangle when any of all of its points get moved > > is purely result of author error(s) in setting the parameter(s). > > > > Whatever happens with normals of triangles moved or destroyed by Displacer > > must match what happens with points moved by joint-driven skin animations > > which can also mess up, and by points moved by CoordinateInterpolator, > > same as any morphing operation. > > Normals can also be set by the author each frame if desired. > > > > Maybe some help given in authortime but not any sort of > > enumerated error except undefined in runtime since this visual effect; > > it is just an artifact of bad data. > > Esp likey when deformable face is actually composed of multiple shapes > > and they must blend regardless of the combinations of shapes > > that move to make the motion for a pose. > > Always? much easier with single basic mesh for the face and and then > > add features and accessories animated individually? > > > > One of the limitations with Displacer is that it is just a single scaled > 3D vector, > > meaning it has a fixed relative direction regardless of the weight > applied. > > When a curved displacement is required, then point motion can be > > controlled using joint rotation, like the eyeball. > > In some cases,a CoordinateInterpolator may be used to move points around. > > Texture position and rotation can be animated. > > > > Since all these Displacer nodes have been produced by finding the > > simple 3D vector difference between the first and last data point > > of a source CoordinateInterpolator it is likely that some displacements > > do not produce exact same movement of a point just because the > > original interpolator keyValue keyframe data points described a curved > path. > > > > Sure, we can update the 3D vector direction each frame if we want to, > > but I would like to see a Displacer which could use multiple sets of > vectors > > interpolated to produce computed keyframes like other interpolators. > > For each point there could be a set of vectors where the output value for > > point movement is the result of interpolation between > > adjacent key time (weight) keyValue 3D vectors. > > > > So, more fun with x3d HAnim > > Thanks, > > Joe > > > > > > -----Original Message----- > From: Extensible 3D (X3D) Graphics public discussion > > Sent: Feb 12, 2025 9:11 AM > To: X3D Graphics public mailing list > Cc: Andreas Plesch > Subject: Re: [x3d-public] Displacer and normals ? > > > > Responses below: > > >> Date: Tue, 11 Feb 2025 15:58:40 -0600 >> From: John Carlson >> To: "Extensible 3D (X3D) Graphics public discussion" >> >> Subject: Re: [x3d-public] Displacer and normals ? >> >> Did you get the black tongue effect? I?ve seen that in Sunrize, and >> reported it there. Holger had a response about providing normals. > > > I found https://github.com/create3000/sunrize/issues/9 > > Yes, I think this is similar. x-ite/sunrize just may not automatically > recalculate normals for performance reasons which in some cases may be > beneficial by avoiding the effects of degenerate triangles. > > >> The displacers were taken from CoordinateInterpolators in the >> HumanoidAnimation/FacialAnimation X3D archive. >> >> https://www.web3d.org/x3d/content/examples/HumanoidAnimation/FacialAnimation/index.html >> Perhaps we could derive normals from those examples, realizing only one >> set >> of meshes is chosen for the final version. >> >> It?s relevant, because I will be providing a unified skin mesh for FACS, >> and it would be nice to provide normals. > > > I noticed the effect actually only in combined displacers/morphers, eg. > the Contempt combo. That brings up the future question of how pre-computed > normals from multiple displacers may be combined, maybe just by averaging > the slerped orientation from each. > There may have been studies on how to best recombine facial subexpressions > for a valid result. > > -Andreas > > >> >> On Tue, Feb 11, 2025 at 3:41?PM Andreas Plesch via x3d-public < >> x3d-public at web3d.org> wrote: >> >> > I noticed that some displacers cause degenerate or flipped triangles >> which >> > may cause rendering problems, mostly due to problems calculating >> > automatically a good normal vector. >> > >> > In general, for best rendering results, it is necessary to provide >> > precomputed normals. rather than rely on automatic normal calculations. >> Was >> > there a discussion on how to have displacers provide precomputed normals >> > along with the displacement of the vertices ? That would help with >> > rendering quality, and may be necessary for some use cases. >> > >> > This may be deemed a long term feature to consider. >> > >> > Perhaps an idea would be a MFRotation normalRotations field which has >> the >> > rotation required to rotate the normal (per vertex, or perhaps per face) >> > from the rest orientation to the final orientation. Weights are applied >> > with slerp. For animation authors it would be probably easier to be >> able to >> > just directly provide the final orientation. >> > >> > Any feedback or comment much welcome, -Andreas >> > >> > >> > -- >> > Andreas Plesch >> > Waltham, MA 02453 >> > _______________________________________________ >> > x3d-public mailing list >> > x3d-public at web3d.org >> > http://web3d.org/mailman/listinfo/x3d-public_web3d.org >> > >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20250211/a4be3c1a/attachment-0001.html >> > >> >> ------------------------------ >> >> Message: 3 >> Date: Wed, 12 Feb 2025 11:27:59 -0500 >> From: Andreas Plesch >> To: John Carlson >> Cc: Holger Seelig , X3D Graphics public >> mailing list , Joe D Williams >> >> Subject: Re: [x3d-public] Turning on and off simultaneous animations >> individually >> Message-ID: >> < >> CAKdk67vXRSz1pM4QLjcxuCQHfjY4LUT924cSmX7rPAasroPUCw at mail.gmail.com> >> Content-Type: text/plain; charset="utf-8" >> >> Hi, >> >> I took a first stab at Displacers in Segments for x3dom and use it now in >> the editor: >> >> >> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/ManyClocks.x3d >> >> This is experimental and mostly for testing purposes. If there is an >> example combining Displacers in both Joints and Segments that would be >> interesting as it is not necessarily expected to work. >> The experimental implementation is inefficient and expensive as it is >> weight_changed event driven. If you activate multiple displacers the frame >> rate starts to drop. It probably is not very useful at this point. >> >> Fee free to give it a try, -Andreas >> >> On Wed, Feb 5, 2025, 4:11?PM Andreas Plesch >> wrote: >> >> > Hi John, >> > >> > Thanks. I found the tongue.x3d example but if you can create another one >> > that would be helpful in general. >> > >> > You vastly overestimate my ability and availability ;) This would be a >> > longer term project. I have an idea what to do. >> > >> > Andreas >> > >> > >> > On Wed, Feb 5, 2025, 1:31?PM John Carlson wrote: >> > >> >> I had one I sent to Holger, probably derived from this one: >> >> >> >> >> >> >> https://github.com/coderextreme/ci2had/blob/main/resources/JinMouthStretch.x3d >> >> >> >> >> >> What I would do (again) is take out all the segments but the tongue. >> >> >> >> There?s no menus involved in this one. >> >> >> >> If you need further assistance, like a smaller example, I can help. >> Also >> >> all the Jin*.x3d FACS action units can also provide examples. >> >> >> >> I?ll be pretty unbusy today. I can allocate some time for creating a >> >> model, make sure it animates, etc. >> >> >> >> If you?re able to allocate some time today, great, we have an HAnim >> >> meeting tomorrow and showing off X3DOM editor using Displacers would be >> >> fantastic! >> >> >> >> Remember there?s a coord field in HAnimSegment that the HAnimDisplacer >> >> operates on! >> >> >> >> John >> >> >> >> On Wed, Feb 5, 2025 at 12:01?PM Andreas Plesch < >> andreasplesch at gmail.com> >> >> wrote: >> >> >> >>> Hi John, >> >>> >> >>> The reason is that Displacers are currently implemented in x3dom only >> >>> for Joints, but not for Segments, unfortunately. Do you know of a >> simple >> >>> but instructive test case of Segments with Displacers ? >> >>> >> >>> Andreas >> >>> >> >>> >> >>> On Tue, Feb 4, 2025, 2:33?PM John Carlson wrote: >> >>> >> >>>> I will try to test this in castle model converter. >> >>>> >> >>>> I did try setting a value for the outputOnly fields, but the >> converter >> >>>> wouldn?t shut up. >> >>>> >> >>>> The model below doesn?t seem to animate when one presses the menu >> >>>> items. Did you get it to animate? >> >>>> >> >>>> On Tue, Feb 4, 2025 at 12:27?PM Andreas Plesch < >> andreasplesch at gmail.com> >> >>>> wrote: >> >>>> >> >>>>> Hi John, all, >> >>>>> >> >>>>> It turns out that x3dom currently expects a default value for Proto >> >>>>> fields even for outputOnly fields. This is due to how Proto fields >> are >> >>>>> initialized. They always need to have a value. While the spec. does >> not >> >>>>> require this, it seems still good practice to always define a >> default value >> >>>>> in the ProtoInterface. There may be a case where an outputOnly >> field is >> >>>>> used in ISing where a valid value would be expected. There may be >> other >> >>>>> corner cases. >> >>>>> >> >>>>> Here is your example with added default values for outputOnly >> fields: >> >>>>> >> >>>>> >> >>>>> >> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/af5ff3148c1159f71d34fb78c1f63024/raw/b3d4470107ab74e301ed48448ab2a4f4154672e0/ManyClocks_John.x3d >> >>>>> >> >>>>> This could be fixed in x3dom, by always setting some default value. >> Is >> >>>>> there a list of recommended defaults for each data type if no other >> source >> >>>>> of defaults is available? For SFTime it seems to be -1. >> >>>>> >> >>>>> >> >>>>> -Andreas >> >>>>> >> >>>>> >> >>>>> On Mon, Feb 3, 2025 at 7:39?AM Andreas Plesch < >> andreasplesch at gmail.com> >> >>>>> wrote: >> >>>>> >> >>>>>> Hi John, >> >>>>>> >> >>>>>> On Mon, Feb 3, 2025 at 12:48?AM John Carlson >> >>>>>> wrote: >> >>>>>> >> >>>>>>> Andreas, "startTime" is an accessType outputOnly field, so why do >> I >> >>>>>>> need to provide a value attribute in fieldValue? I'm kind of >> confused. >> >>>>>>> I'm probably missing something in the spec. >> >>>>>>> >> >>>>>> >> >>>>>> You are right, I only outlined scenarios where the accessType >> allows >> >>>>>> input or initialization.. >> >>>>>> In the outputOnly case it is not necessary to provide a fieldValue >> >>>>>> node at all since there is no value which can be provided. >> Providing the >> >>>>>> node would indeed be confusing, to both the user code reader and >> any X3D >> >>>>>> browser. >> >>>>>> I believe the spec. is silent on this case in any encoding. >> >>>>>> >> >>>>>> Best, Andreas >> >>>>>> >> >>>>>> Thanks for any clarification. >> >>>>>>> >> >>>>>>> I have finally enabled schematron on the project, but I'm finding >> it >> >>>>>>> hard to understand the messages, and modifications that I make, >> while >> >>>>>>> removing the immediate problems, seem to move the problems >> elsewhere. >> >>>>>>> >> >>>>>>> Explaining why I need a "startTime" fieldValue value is my main >> lack >> >>>>>>> of understanding, but perhaps I need a whole review of accessType. >> >>>>>>> >> >>>>>>> Castle Model Converter reports: >> >>>>>>> >> >>>>>>> castle-model-converter: Warning: X3D: X3D XML: >> element >> >>>>>>> references unknown field name "enabled" >> >>>>>>> castle-model-converter: Warning: X3D: X3D XML: >> element >> >>>>>>> references unknown field name "startTime" >> >>>>>>> castle-model-converter: Warning: X3D: X3D XML: >> element >> >>>>>>> references unknown field name "stopTime" >> >>>>>>> >> >>>>>>> I will try providing a field value in the ProtoInterface >> >>>>>>> >> >>>>>>> If I "cleanup" enabled, startTime and stopTime, I get: >> >>>>>>> >> >>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >> >>>>>>> "MenuItem", event "inputTrue" references (by "IS" clause) >> non-existing >> >>>>>>> event "enabled" >> >>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >> >>>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) >> non-existing >> >>>>>>> event "startTime" >> >>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >> >>>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) >> non-existing >> >>>>>>> event "stopTime" >> >>>>>>> >> >>>>>>> I guess what I conclude at this point is, startTime and stopTime >> are >> >>>>>>> bad DEF names, but what about enabled as a field? The dominoes >> are falling. >> >>>>>>> >> >>>>>>> About your two scenarios in the other message, perhaps this is >> >>>>>>> revealing. >> >>>>>>> >> >>>>>>> See attached attempt to fix original issue, which resulted in the >> >>>>>>> above. >> >>>>>>> >> >>>>>>> John >> >>>>>>> >> >>>>>>> On Sun, Feb 2, 2025 at 3:59?PM Andreas Plesch < >> >>>>>>> andreasplesch at gmail.com> wrote: >> >>>>>>> >> >>>>>>>> I think x3dom, reasonably, expects a value for the fieldValue >> nodes: >> >>>>>>>> >> >>>>>>>> For example: >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> and others. >> >>>>>>>> >> >>>>>>>> On Sun, Feb 2, 2025 at 5:42?AM John Carlson >> >>>>>>>> wrote: >> >>>>>>>> >> >>>>>>>>> Andreas, Joe, >> >>>>>>>>> >> >>>>>>>>> Reset Button, Reset_Clock added. >> >>>>>>>>> >> >>>>>>>>> See attached zip for details, or visit link; >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >> >>>>>>>>> >> >>>>>>>>> For some reason, this link doesn't show the live scene? >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >> >>>>>>>>> >> >>>>>>>>> Puzzled, haven't researched it yet. Looks good in Sunrize and >> >>>>>>>>> X_ITE, will try FreeWRL next. >> >>>>>>>>> >> >>>>>>>>> John >> >>>>>>>>> >> >>>>>>>>>> >> >>>>>>>> >> >>>>>>>> -- >> >>>>>>>> Andreas Plesch >> >>>>>>>> Waltham, MA 02453 >> >>>>>>>> >> >>>>>>> >> >>>>>> >> >>>>>> -- >> >>>>>> Andreas Plesch >> >>>>>> Waltham, MA 02453 >> >>>>>> >> >>>>> >> >>>>> >> >>>>> -- >> >>>>> Andreas Plesch >> >>>>> Waltham, MA 02453 >> >>>>> >> >>>> >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20250212/6f37d6ce/attachment.html >> > >> >> ------------------------------ >> >> Subject: Digest Footer >> >> _______________________________________________ >> x3d-public mailing list >> x3d-public at web3d.org >> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >> >> >> ------------------------------ >> >> End of x3d-public Digest, Vol 191, Issue 57 >> ******************************************* > > > > -- > Andreas Plesch > Waltham, MA 02453 > > > -- Andreas Plesch Waltham, MA 02453 -------------- next part -------------- An HTML attachment was scrubbed... URL: From joedwil at earthlink.net Fri Feb 14 06:38:12 2025 From: joedwil at earthlink.net (joedwil at earthlink.net) Date: Fri, 14 Feb 2025 14:38:12 +0000 Subject: [x3d-public] SFRotation default value spec. inconsistency Message-ID: <0027a346-05ca-e6e1-8064-63b097e730fc@earthlink.net> > So, sensibly, a zero rotation around any axis corresponds to the "zero unit Quaternion" (0, 0, 0, 1 XYZW), Right. Not sure but 0 0 0 0 for unit quaternion might not be legal. I think the values must compute to1 to be legal? Thanks, Joe -----Original Message----- From: Andreas Plesch Sent: Feb 10, 2025 12:37 PM To: Joe D Williams Cc: Extensible 3D (X3D) Graphics public discussion Subject: Re: [x3d-public] SFRotation default value spec. inconsistency https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#_node_rotation has indeed (0, 0, 0, 1 XYZW) as a default value. This is difficult to interpret as a rotation around an axis since the corresponding axis would be at first glance (0 0 0). x3dom converts quaternion (0, 0, 0, 1 XYZW) to (axis),angle (0,0,0),0 as does https://www.andre-gaschler.com/rotationconverter/ . On the other hand both SFRotation (0 0 1 0) and SFRotation (0 1 0 0) are also represented by quaternion (0, 0, 0, 1 XYZW). So, sensibly, a zero rotation around any axis corresponds to the "zero unit Quaternion" (0, 0, 0, 1 XYZW), making it a useful default value for quaternions. But that does not help with choosing a default axis for the SFRotation value. This will rarely matter. A use case may be when a SFRotation is initialized to the X3D default in a Proto but then only the angle is modified by a Proto script with the assumption that the axis is (0 0 1). -Andreas On Mon, Feb 10, 2025 at 12:57?PM Joe D Williams wrote: not zerp, zero -----Original Message----- From: Extensible 3D (X3D) Graphics public discussion Sent: Feb 10, 2025 9:50 AM To: Extensible 3D (X3D) Graphics public discussion , X3D Graphics public mailing list Cc: Joe D Williams , Andreas Plesch Subject: Re: [x3d-public] SFRotation default value spec. inconsistency I think the 0 0 1 0 should be used everywhere for default axis-angle. I thinkI see 'zerp' unit quaternions (as in gltf as 0 0 0 1 XYZW) Thanks, Joe -----Original Message----- From: Extensible 3D (X3D) Graphics public discussion Sent: Feb 10, 2025 8:44 AM To: X3D Graphics public mailing list Cc: Andreas Plesch Subject: Re: [x3d-public] SFRotation default value spec. inconsistency The JS SAI spec. at https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#FieldServices does not list functions for SFColorRGBA, only SFColor. There may be an earlier report. -Andreas On Mon, Feb 10, 2025 at 11:31?AM Andreas Plesch wrote: https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/fieldTypes.html#SFRotationAndMFRotation specifies that (0 0 1 0) is the value of an uninitialized SFRotation given as (x y z a). However, the JS SAI spec. in table 7.18 in https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#SFRotationInstanceCreationFunction effectively makes (0 1 0 0) the default value if no parameters are provided. The inconsistency does not have much of an impact since both are 0 rotations but I believe (0 1 0 0) - a 0 rotation around y - may have been intended as the default. -Andreas -- Andreas Plesch Waltham, MA 02453 -- Andreas Plesch Waltham, MA 02453 -- Andreas Plesch Waltham, MA 02453 -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger.seelig at yahoo.de Fri Feb 14 07:22:02 2025 From: holger.seelig at yahoo.de (Holger Seelig) Date: Fri, 14 Feb 2025 16:22:02 +0100 Subject: [x3d-public] SFRotation default value spec. inconsistency In-Reply-To: <0027a346-05ca-e6e1-8064-63b097e730fc@earthlink.net> References: <0027a346-05ca-e6e1-8064-63b097e730fc@earthlink.net> Message-ID: All quaternions must be normalized to be a legal rotation, so the length of the quaternion must always be one. Holger -- Holger Seelig Leipzig, Germany holger.seelig at yahoo.de https://create3000.github.io/x_ite/ > Am 14.02.2025 um 15:38 schrieb Joe D Williams via x3d-public : > > > So, sensibly, a zero rotation around any axis corresponds to the "zero unit Quaternion" (0, 0, 0, 1 XYZW), > > Right. Not sure but 0 0 0 0 for unit quaternion might not be legal. I think the values must compute to1 to be legal? > Thanks, > Joe > > > -----Original Message----- > From: Andreas Plesch > Sent: Feb 10, 2025 12:37 PM > To: Joe D Williams > Cc: Extensible 3D (X3D) Graphics public discussion > Subject: Re: [x3d-public] SFRotation default value spec. inconsistency > > > https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#_node_rotation > has indeed (0, 0, 0, 1 XYZW) as a default value. > > This is difficult to interpret as a rotation around an axis since the corresponding axis would be at first glance (0 0 0). > > x3dom converts quaternion (0, 0, 0, 1 XYZW) to (axis),angle (0,0,0),0 as does https://www.andre-gaschler.com/rotationconverter/ . > > On the other hand both SFRotation (0 0 1 0) and SFRotation (0 1 0 0) are also represented by quaternion (0, 0, 0, 1 XYZW). > > So, sensibly, a zero rotation around any axis corresponds to the "zero unit Quaternion" (0, 0, 0, 1 XYZW), making it a useful default value for quaternions. But that does not help with choosing a default axis for the SFRotation value. > > This will rarely matter. A use case may be when a SFRotation is initialized to the X3D default in a Proto but then only the angle is modified by a Proto script with the assumption that the axis is (0 0 1). > > -Andreas > > On Mon, Feb 10, 2025 at 12:57?PM Joe D Williams > wrote: >> not zerp, zero >> -----Original Message----- >> From: Extensible 3D (X3D) Graphics public discussion > >> Sent: Feb 10, 2025 9:50 AM >> To: Extensible 3D (X3D) Graphics public discussion >, X3D Graphics public mailing list > >> Cc: Joe D Williams >, Andreas Plesch > >> Subject: Re: [x3d-public] SFRotation default value spec. inconsistency >> >> >> I think the 0 0 1 0 should be used everywhere for default axis-angle. >> I thinkI see 'zerp' unit quaternions (as in gltf as 0 0 0 1 XYZW) >> Thanks, >> Joe >> >> -----Original Message----- >> From: Extensible 3D (X3D) Graphics public discussion > >> Sent: Feb 10, 2025 8:44 AM >> To: X3D Graphics public mailing list > >> Cc: Andreas Plesch > >> Subject: Re: [x3d-public] SFRotation default value spec. inconsistency >> >> >> The JS SAI spec. at https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#FieldServices >> >> does not list functions for SFColorRGBA, only SFColor. There may be an earlier report. -Andreas >> >> On Mon, Feb 10, 2025 at 11:31?AM Andreas Plesch > wrote: >>> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/fieldTypes.html#SFRotationAndMFRotation >>> >>> specifies that (0 0 1 0) is the value of an uninitialized SFRotation given as (x y z a). >>> >>> However, the JS SAI spec. in table 7.18 in https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#SFRotationInstanceCreationFunction >>> >>> effectively makes (0 1 0 0) the default value if no parameters are provided. >>> >>> The inconsistency does not have much of an impact since both are 0 rotations but I believe (0 1 0 0) - a 0 rotation around y - may have been intended as the default. >>> >>> -Andreas >>> >>> -- >>> Andreas Plesch >>> Waltham, MA 02453 >> >> >> >> -- >> Andreas Plesch >> Waltham, MA 02453 >> >> > > > > -- > Andreas Plesch > Waltham, MA 02453 > > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From joedwil at earthlink.net Fri Feb 14 10:11:01 2025 From: joedwil at earthlink.net (joedwil at earthlink.net) Date: Fri, 14 Feb 2025 18:11:01 +0000 Subject: [x3d-public] X3D in and of the MetaVerse Message-ID: So, I have been participating in the MSF, Metaverse Standards Forum, in areas related to X3D, X3D HAnim, and especially HAnim. One item I am convinced of is that MetaVerse should be CamelCase. There will be many Verses and so this One particular, although having properties of waves, virtualization deserves extra special distinction. because it alone will be free and open, and defined by free and open standards. However, this name of this asset could be controversial. If only to me? Because, well, is there a real possibility there can be only one Meta when even that common name of a common self-defining thing can be owned? Is a meta really only a meta when it completely describes itself in logically related pairs both locally and by remote proxy? Does the runtime need live access to meta? But seriously, there is some naming I would like to see. We have some existing web standardizable interfaces to assist in specialized communications and interactions that are considered as Accessibility features. For this unique versal effort, let's put these within the broad category of Conveniences. A Convenience is just an asset that gives the Avatar, your HAnim Humanoid Twin, for instance, and thus the user, You, for instance, access to some standard or enriched feature of the host environment. In the immersive experience there are at least two levels of convenience. First the Avatar must be able to navigate and interact in the current scene of the container provided by the host, Second, the User must be able to reliably control navigation and interactions of the Avatar in the environment the Avatar finds itself. The user can be immersed only to the extent that the Avatar can be immersed. Each asset of the Avatar that can transact with a feature or collection of features of the scene are shared with the Avatar and thus with the User as a Convenience. Overall, MSF id a chance to discuss targets for implementations and at least give an evolving metaverse an idea of what we, by consensus, consider best standard practices at this time. Videos here: https://www.youtube.com/@metaversestandardsforum Thanks for All, Joe . . From andreasplesch at gmail.com Fri Feb 14 11:35:42 2025 From: andreasplesch at gmail.com (Andreas Plesch) Date: Fri, 14 Feb 2025 14:35:42 -0500 Subject: [x3d-public] SFRotation default value spec. inconsistency In-Reply-To: References: <0027a346-05ca-e6e1-8064-63b097e730fc@earthlink.net> Message-ID: Let me just add for clarity that the length (or norm) of a quaternion includes the fourth, the scalar component. The norm is the square root of the sum of the squares of all four components. Only unit quaternions represent rotations. A (0,0,0,0) quaternion does not represent any rotation (but of course exists outside of rotations). Andreas PS: To add back in some fuzziness, a unit quaternion can only represent a rotation up to 360 degrees. I think there is a mechanism to use non-unit quaternions for larger rotations. On Fri, Feb 14, 2025 at 10:22?AM Holger Seelig wrote: > All quaternions must be normalized to be a legal rotation, so the length > of the quaternion must always be one. > > Holger > -- > Holger Seelig > Leipzig, Germany > > holger.seelig at yahoo.de > https://create3000.github.io/x_ite/ > > Am 14.02.2025 um 15:38 schrieb Joe D Williams via x3d-public < > x3d-public at web3d.org>: > > > So, sensibly, a zero rotation around any axis corresponds to the "zero > unit Quaternion" (0, 0, 0, 1 XYZW), > > > Right. Not sure but 0 0 0 0 for unit quaternion might not be legal. I > think the values must compute to1 to be legal? > Thanks, > Joe > > > > > > -----Original Message----- > From: Andreas Plesch > Sent: Feb 10, 2025 12:37 PM > To: Joe D Williams > Cc: Extensible 3D (X3D) Graphics public discussion > Subject: Re: [x3d-public] SFRotation default value spec. inconsistency > > > https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#_node_rotation > has indeed (0, 0, 0, 1 XYZW) as a default value. > > This is difficult to interpret as a rotation around an axis since the > corresponding axis would be at first glance (0 0 0). > > x3dom converts quaternion (0, 0, 0, 1 XYZW) to (axis),angle (0,0,0),0 as > does https://www.andre-gaschler.com/rotationconverter/ . > > On the other hand both SFRotation (0 0 1 0) and SFRotation (0 1 0 0) are > also represented by quaternion (0, 0, 0, 1 XYZW). > > So, sensibly, a zero rotation around any axis corresponds to the "zero > unit Quaternion" (0, 0, 0, 1 XYZW), making it a useful default value for > quaternions. But that does not help with choosing a default axis for the > SFRotation value. > > This will rarely matter. A use case may be when a SFRotation is > initialized to the X3D default in a Proto but then only the angle is > modified by a Proto script with the assumption that the axis is (0 0 1). > > -Andreas > > On Mon, Feb 10, 2025 at 12:57?PM Joe D Williams > wrote: > >> not zerp, zero >> >> -----Original Message----- >> From: Extensible 3D (X3D) Graphics public discussion < >> x3d-public at web3d.org> >> Sent: Feb 10, 2025 9:50 AM >> To: Extensible 3D (X3D) Graphics public discussion , >> X3D Graphics public mailing list >> Cc: Joe D Williams , Andreas Plesch < >> andreasplesch at gmail.com> >> Subject: Re: [x3d-public] SFRotation default value spec. inconsistency >> >> >> I think the 0 0 1 0 should be used everywhere for default axis-angle. >> I thinkI see 'zerp' unit quaternions (as in gltf as 0 0 0 1 XYZW) >> Thanks, >> Joe >> >> >> >> -----Original Message----- >> From: Extensible 3D (X3D) Graphics public discussion < >> x3d-public at web3d.org> >> Sent: Feb 10, 2025 8:44 AM >> To: X3D Graphics public mailing list >> Cc: Andreas Plesch >> Subject: Re: [x3d-public] SFRotation default value spec. inconsistency >> >> >> The JS SAI spec. at >> https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#FieldServices >> >> does not list functions for SFColorRGBA, only SFColor. There may be an >> earlier report. -Andreas >> >> On Mon, Feb 10, 2025 at 11:31?AM Andreas Plesch >> wrote: >> >>> >>> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/fieldTypes.html#SFRotationAndMFRotation >>> >>> specifies that (0 0 1 0) is the value of an uninitialized SFRotation >>> given as (x y z a). >>> >>> However, the JS SAI spec. in table 7.18 in >>> https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#SFRotationInstanceCreationFunction >>> >>> effectively makes (0 1 0 0) the default value if no parameters are >>> provided. >>> >>> The inconsistency does not have much of an impact since both are 0 >>> rotations but I believe (0 1 0 0) - a 0 rotation around y - may have been >>> intended as the default. >>> >>> -Andreas >>> >>> -- >>> Andreas Plesch >>> Waltham, MA 02453 >>> >> >> >> -- >> Andreas Plesch >> Waltham, MA 02453 >> >> >> >> >> > > > -- > Andreas Plesch > Waltham, MA 02453 > > > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > > > -- Andreas Plesch Waltham, MA 02453 -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreasplesch at gmail.com Sat Feb 15 13:24:39 2025 From: andreasplesch at gmail.com (Andreas Plesch) Date: Sat, 15 Feb 2025 16:24:39 -0500 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: Message-ID: Hi, the x3dom editor now uses an experimental version with much improved performance for HAnimDisplacers: https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d This experimental x3dom version is available at https://andreasplesch.github.io/x3dom/dist/ Feel free to use and test it. Some tests are available at https://andreasplesch.github.io/x3dom/test/ Have fun, -Andreas On Wed, Feb 12, 2025 at 11:27?AM Andreas Plesch wrote: > Hi, > > I took a first stab at Displacers in Segments for x3dom and use it now in > the editor: > > > https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/ManyClocks.x3d > > This is experimental and mostly for testing purposes. If there is an > example combining Displacers in both Joints and Segments that would be > interesting as it is not necessarily expected to work. > The experimental implementation is inefficient and expensive as it is > weight_changed event driven. If you activate multiple displacers the frame > rate starts to drop. It probably is not very useful at this point. > > Fee free to give it a try, -Andreas > > On Wed, Feb 5, 2025, 4:11?PM Andreas Plesch > wrote: > >> Hi John, >> >> Thanks. I found the tongue.x3d example but if you can create another one >> that would be helpful in general. >> >> You vastly overestimate my ability and availability ;) This would be a >> longer term project. I have an idea what to do. >> >> Andreas >> >> >> On Wed, Feb 5, 2025, 1:31?PM John Carlson wrote: >> >>> I had one I sent to Holger, probably derived from this one: >>> >>> >>> https://github.com/coderextreme/ci2had/blob/main/resources/JinMouthStretch.x3d >>> >>> >>> What I would do (again) is take out all the segments but the tongue. >>> >>> There?s no menus involved in this one. >>> >>> If you need further assistance, like a smaller example, I can help. >>> Also all the Jin*.x3d FACS action units can also provide examples. >>> >>> I?ll be pretty unbusy today. I can allocate some time for creating a >>> model, make sure it animates, etc. >>> >>> If you?re able to allocate some time today, great, we have an HAnim >>> meeting tomorrow and showing off X3DOM editor using Displacers would be >>> fantastic! >>> >>> Remember there?s a coord field in HAnimSegment that the HAnimDisplacer >>> operates on! >>> >>> John >>> >>> On Wed, Feb 5, 2025 at 12:01?PM Andreas Plesch >>> wrote: >>> >>>> Hi John, >>>> >>>> The reason is that Displacers are currently implemented in x3dom only >>>> for Joints, but not for Segments, unfortunately. Do you know of a simple >>>> but instructive test case of Segments with Displacers ? >>>> >>>> Andreas >>>> >>>> >>>> On Tue, Feb 4, 2025, 2:33?PM John Carlson wrote: >>>> >>>>> I will try to test this in castle model converter. >>>>> >>>>> I did try setting a value for the outputOnly fields, but the converter >>>>> wouldn?t shut up. >>>>> >>>>> The model below doesn?t seem to animate when one presses the menu >>>>> items. Did you get it to animate? >>>>> >>>>> On Tue, Feb 4, 2025 at 12:27?PM Andreas Plesch < >>>>> andreasplesch at gmail.com> wrote: >>>>> >>>>>> Hi John, all, >>>>>> >>>>>> It turns out that x3dom currently expects a default value for Proto >>>>>> fields even for outputOnly fields. This is due to how Proto fields are >>>>>> initialized. They always need to have a value. While the spec. does not >>>>>> require this, it seems still good practice to always define a default value >>>>>> in the ProtoInterface. There may be a case where an outputOnly field is >>>>>> used in ISing where a valid value would be expected. There may be other >>>>>> corner cases. >>>>>> >>>>>> Here is your example with added default values for outputOnly fields: >>>>>> >>>>>> >>>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/af5ff3148c1159f71d34fb78c1f63024/raw/b3d4470107ab74e301ed48448ab2a4f4154672e0/ManyClocks_John.x3d >>>>>> >>>>>> This could be fixed in x3dom, by always setting some default value. >>>>>> Is there a list of recommended defaults for each data type if no other >>>>>> source of defaults is available? For SFTime it seems to be -1. >>>>>> >>>>>> >>>>>> -Andreas >>>>>> >>>>>> >>>>>> On Mon, Feb 3, 2025 at 7:39?AM Andreas Plesch < >>>>>> andreasplesch at gmail.com> wrote: >>>>>> >>>>>>> Hi John, >>>>>>> >>>>>>> On Mon, Feb 3, 2025 at 12:48?AM John Carlson >>>>>>> wrote: >>>>>>> >>>>>>>> Andreas, "startTime" is an accessType outputOnly field, so why do I >>>>>>>> need to provide a value attribute in fieldValue? I'm kind of confused. >>>>>>>> I'm probably missing something in the spec. >>>>>>>> >>>>>>> >>>>>>> You are right, I only outlined scenarios where the accessType allows >>>>>>> input or initialization.. >>>>>>> In the outputOnly case it is not necessary to provide a fieldValue >>>>>>> node at all since there is no value which can be provided. Providing the >>>>>>> node would indeed be confusing, to both the user code reader and any X3D >>>>>>> browser. >>>>>>> I believe the spec. is silent on this case in any encoding. >>>>>>> >>>>>>> Best, Andreas >>>>>>> >>>>>>> Thanks for any clarification. >>>>>>>> >>>>>>>> I have finally enabled schematron on the project, but I'm finding >>>>>>>> it hard to understand the messages, and modifications that I make, while >>>>>>>> removing the immediate problems, seem to move the problems elsewhere. >>>>>>>> >>>>>>>> Explaining why I need a "startTime" fieldValue value is my main >>>>>>>> lack of understanding, but perhaps I need a whole review of accessType. >>>>>>>> >>>>>>>> Castle Model Converter reports: >>>>>>>> >>>>>>>> castle-model-converter: Warning: X3D: X3D XML: element >>>>>>>> references unknown field name "enabled" >>>>>>>> castle-model-converter: Warning: X3D: X3D XML: element >>>>>>>> references unknown field name "startTime" >>>>>>>> castle-model-converter: Warning: X3D: X3D XML: element >>>>>>>> references unknown field name "stopTime" >>>>>>>> >>>>>>>> I will try providing a field value in the ProtoInterface >>>>>>>> >>>>>>>> If I "cleanup" enabled, startTime and stopTime, I get: >>>>>>>> >>>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>>>> "MenuItem", event "inputTrue" references (by "IS" clause) non-existing >>>>>>>> event "enabled" >>>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) non-existing >>>>>>>> event "startTime" >>>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) non-existing >>>>>>>> event "stopTime" >>>>>>>> >>>>>>>> I guess what I conclude at this point is, startTime and stopTime >>>>>>>> are bad DEF names, but what about enabled as a field? The dominoes are >>>>>>>> falling. >>>>>>>> >>>>>>>> About your two scenarios in the other message, perhaps this is >>>>>>>> revealing. >>>>>>>> >>>>>>>> See attached attempt to fix original issue, which resulted in the >>>>>>>> above. >>>>>>>> >>>>>>>> John >>>>>>>> >>>>>>>> On Sun, Feb 2, 2025 at 3:59?PM Andreas Plesch < >>>>>>>> andreasplesch at gmail.com> wrote: >>>>>>>> >>>>>>>>> I think x3dom, reasonably, expects a value for the fieldValue >>>>>>>>> nodes: >>>>>>>>> >>>>>>>>> For example: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> and others. >>>>>>>>> >>>>>>>>> On Sun, Feb 2, 2025 at 5:42?AM John Carlson >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Andreas, Joe, >>>>>>>>>> >>>>>>>>>> Reset Button, Reset_Clock added. >>>>>>>>>> >>>>>>>>>> See attached zip for details, or visit link; >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>>>>>> >>>>>>>>>> For some reason, this link doesn't show the live scene? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>>>>>> >>>>>>>>>> Puzzled, haven't researched it yet. Looks good in Sunrize and >>>>>>>>>> X_ITE, will try FreeWRL next. >>>>>>>>>> >>>>>>>>>> John >>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Andreas Plesch >>>>>>>>> Waltham, MA 02453 >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Andreas Plesch >>>>>>> Waltham, MA 02453 >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Andreas Plesch >>>>>> Waltham, MA 02453 >>>>>> >>>>> -- Andreas Plesch Waltham, MA 02453 -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreasplesch at gmail.com Sat Feb 15 13:34:13 2025 From: andreasplesch at gmail.com (Andreas Plesch) Date: Sat, 15 Feb 2025 16:34:13 -0500 Subject: [x3d-public] Displacer and normals ? In-Reply-To: References: Message-ID: Non-linear displacement paths > > It would be probably feasible from an implementation perspective to have > displacers with weight (key) ranges for piecewise linear interpolations to > approximate curved displacement paths. Thinking about it, it may already be > possible to design a CoordinateInterpolator of _displacement_ keyValues > which gets routed to the displacement field of a displacer, with a constant > weight of 1. So animation then happens by changing displacement values > directly rather than weight values. This would allow for arbitrary > displacement paths and does not need any changes, still allowing targeting > vertex subsets and composing. Might be worth testing, seems interesting. > This idea seems to work. Here is a simple example based on John's Tongue.x3d https://raw.githubusercontent.com/andreasplesch/x3dom/refs/heads/HAnim_displacers/test/functional/hanim/tongueCurved.x3d [ Use Alt-Q to flip line wrapping of long lines. ] It adds an additional displacement step halfways through the animation which has non-linear z displacements. Could be interesting. -Andreas -Andreas > > On Wed, Feb 12, 2025 at 10:58?PM Joe D Williams > wrote: > >> I think degenerate triangles, ones that flip from ccw to cw, or overlap or >> >> whatever messes up a triangle when any of all of its points get moved >> >> is purely result of author error(s) in setting the parameter(s). >> >> >> >> Whatever happens with normals of triangles moved or destroyed by Displacer >> >> must match what happens with points moved by joint-driven skin animations >> >> which can also mess up, and by points moved by CoordinateInterpolator, >> >> same as any morphing operation. >> >> Normals can also be set by the author each frame if desired. >> >> >> >> Maybe some help given in authortime but not any sort of >> >> enumerated error except undefined in runtime since this visual effect; >> >> it is just an artifact of bad data. >> >> Esp likey when deformable face is actually composed of multiple shapes >> >> and they must blend regardless of the combinations of shapes >> >> that move to make the motion for a pose. >> >> Always? much easier with single basic mesh for the face and and then >> >> add features and accessories animated individually? >> >> >> >> One of the limitations with Displacer is that it is just a single scaled >> 3D vector, >> >> meaning it has a fixed relative direction regardless of the weight >> applied. >> >> When a curved displacement is required, then point motion can be >> >> controlled using joint rotation, like the eyeball. >> >> In some cases,a CoordinateInterpolator may be used to move points >> around. >> >> Texture position and rotation can be animated. >> >> >> >> Since all these Displacer nodes have been produced by finding the >> >> simple 3D vector difference between the first and last data point >> >> of a source CoordinateInterpolator it is likely that some displacements >> >> do not produce exact same movement of a point just because the >> >> original interpolator keyValue keyframe data points described a curved >> path. >> >> >> >> Sure, we can update the 3D vector direction each frame if we want to, >> >> but I would like to see a Displacer which could use multiple sets of >> vectors >> >> interpolated to produce computed keyframes like other interpolators. >> >> For each point there could be a set of vectors where the output value for >> >> point movement is the result of interpolation between >> >> adjacent key time (weight) keyValue 3D vectors. >> >> >> >> So, more fun with x3d HAnim >> >> Thanks, >> >> Joe >> >> >> >> >> >> -----Original Message----- >> From: Extensible 3D (X3D) Graphics public discussion < >> x3d-public at web3d.org> >> Sent: Feb 12, 2025 9:11 AM >> To: X3D Graphics public mailing list >> Cc: Andreas Plesch >> Subject: Re: [x3d-public] Displacer and normals ? >> >> >> >> Responses below: >> >> >>> Date: Tue, 11 Feb 2025 15:58:40 -0600 >>> From: John Carlson >>> To: "Extensible 3D (X3D) Graphics public discussion" >>> >>> Subject: Re: [x3d-public] Displacer and normals ? >>> >>> Did you get the black tongue effect? I?ve seen that in Sunrize, and >>> reported it there. Holger had a response about providing normals. >> >> >> I found https://github.com/create3000/sunrize/issues/9 >> >> Yes, I think this is similar. x-ite/sunrize just may not automatically >> recalculate normals for performance reasons which in some cases may be >> beneficial by avoiding the effects of degenerate triangles. >> >> >>> The displacers were taken from CoordinateInterpolators in the >>> HumanoidAnimation/FacialAnimation X3D archive. >>> >>> https://www.web3d.org/x3d/content/examples/HumanoidAnimation/FacialAnimation/index.html >>> Perhaps we could derive normals from those examples, realizing only one >>> set >>> of meshes is chosen for the final version. >>> >>> It?s relevant, because I will be providing a unified skin mesh for FACS, >>> and it would be nice to provide normals. >> >> >> I noticed the effect actually only in combined displacers/morphers, eg. >> the Contempt combo. That brings up the future question of how pre-computed >> normals from multiple displacers may be combined, maybe just by averaging >> the slerped orientation from each. >> There may have been studies on how to best recombine facial >> subexpressions for a valid result. >> >> -Andreas >> >> >>> >>> On Tue, Feb 11, 2025 at 3:41?PM Andreas Plesch via x3d-public < >>> x3d-public at web3d.org> wrote: >>> >>> > I noticed that some displacers cause degenerate or flipped triangles >>> which >>> > may cause rendering problems, mostly due to problems calculating >>> > automatically a good normal vector. >>> > >>> > In general, for best rendering results, it is necessary to provide >>> > precomputed normals. rather than rely on automatic normal >>> calculations. Was >>> > there a discussion on how to have displacers provide precomputed >>> normals >>> > along with the displacement of the vertices ? That would help with >>> > rendering quality, and may be necessary for some use cases. >>> > >>> > This may be deemed a long term feature to consider. >>> > >>> > Perhaps an idea would be a MFRotation normalRotations field which has >>> the >>> > rotation required to rotate the normal (per vertex, or perhaps per >>> face) >>> > from the rest orientation to the final orientation. Weights are applied >>> > with slerp. For animation authors it would be probably easier to be >>> able to >>> > just directly provide the final orientation. >>> > >>> > Any feedback or comment much welcome, -Andreas >>> > >>> > >>> > -- >>> > Andreas Plesch >>> > Waltham, MA 02453 >>> > _______________________________________________ >>> > x3d-public mailing list >>> > x3d-public at web3d.org >>> > http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>> > >>> -------------- next part -------------- >>> An HTML attachment was scrubbed... >>> URL: < >>> http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20250211/a4be3c1a/attachment-0001.html >>> > >>> >>> ------------------------------ >>> >>> Message: 3 >>> Date: Wed, 12 Feb 2025 11:27:59 -0500 >>> From: Andreas Plesch >>> To: John Carlson >>> Cc: Holger Seelig , X3D Graphics public >>> mailing list , Joe D Williams >>> >>> Subject: Re: [x3d-public] Turning on and off simultaneous animations >>> individually >>> Message-ID: >>> < >>> CAKdk67vXRSz1pM4QLjcxuCQHfjY4LUT924cSmX7rPAasroPUCw at mail.gmail.com> >>> Content-Type: text/plain; charset="utf-8" >>> >>> Hi, >>> >>> I took a first stab at Displacers in Segments for x3dom and use it now in >>> the editor: >>> >>> >>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/ManyClocks.x3d >>> >>> This is experimental and mostly for testing purposes. If there is an >>> example combining Displacers in both Joints and Segments that would be >>> interesting as it is not necessarily expected to work. >>> The experimental implementation is inefficient and expensive as it is >>> weight_changed event driven. If you activate multiple displacers the >>> frame >>> rate starts to drop. It probably is not very useful at this point. >>> >>> Fee free to give it a try, -Andreas >>> >>> On Wed, Feb 5, 2025, 4:11?PM Andreas Plesch >>> wrote: >>> >>> > Hi John, >>> > >>> > Thanks. I found the tongue.x3d example but if you can create another >>> one >>> > that would be helpful in general. >>> > >>> > You vastly overestimate my ability and availability ;) This would be a >>> > longer term project. I have an idea what to do. >>> > >>> > Andreas >>> > >>> > >>> > On Wed, Feb 5, 2025, 1:31?PM John Carlson wrote: >>> > >>> >> I had one I sent to Holger, probably derived from this one: >>> >> >>> >> >>> >> >>> https://github.com/coderextreme/ci2had/blob/main/resources/JinMouthStretch.x3d >>> >> >>> >> >>> >> What I would do (again) is take out all the segments but the tongue. >>> >> >>> >> There?s no menus involved in this one. >>> >> >>> >> If you need further assistance, like a smaller example, I can help. >>> Also >>> >> all the Jin*.x3d FACS action units can also provide examples. >>> >> >>> >> I?ll be pretty unbusy today. I can allocate some time for creating a >>> >> model, make sure it animates, etc. >>> >> >>> >> If you?re able to allocate some time today, great, we have an HAnim >>> >> meeting tomorrow and showing off X3DOM editor using Displacers would >>> be >>> >> fantastic! >>> >> >>> >> Remember there?s a coord field in HAnimSegment that the HAnimDisplacer >>> >> operates on! >>> >> >>> >> John >>> >> >>> >> On Wed, Feb 5, 2025 at 12:01?PM Andreas Plesch < >>> andreasplesch at gmail.com> >>> >> wrote: >>> >> >>> >>> Hi John, >>> >>> >>> >>> The reason is that Displacers are currently implemented in x3dom only >>> >>> for Joints, but not for Segments, unfortunately. Do you know of a >>> simple >>> >>> but instructive test case of Segments with Displacers ? >>> >>> >>> >>> Andreas >>> >>> >>> >>> >>> >>> On Tue, Feb 4, 2025, 2:33?PM John Carlson >>> wrote: >>> >>> >>> >>>> I will try to test this in castle model converter. >>> >>>> >>> >>>> I did try setting a value for the outputOnly fields, but the >>> converter >>> >>>> wouldn?t shut up. >>> >>>> >>> >>>> The model below doesn?t seem to animate when one presses the menu >>> >>>> items. Did you get it to animate? >>> >>>> >>> >>>> On Tue, Feb 4, 2025 at 12:27?PM Andreas Plesch < >>> andreasplesch at gmail.com> >>> >>>> wrote: >>> >>>> >>> >>>>> Hi John, all, >>> >>>>> >>> >>>>> It turns out that x3dom currently expects a default value for Proto >>> >>>>> fields even for outputOnly fields. This is due to how Proto fields >>> are >>> >>>>> initialized. They always need to have a value. While the spec. >>> does not >>> >>>>> require this, it seems still good practice to always define a >>> default value >>> >>>>> in the ProtoInterface. There may be a case where an outputOnly >>> field is >>> >>>>> used in ISing where a valid value would be expected. There may be >>> other >>> >>>>> corner cases. >>> >>>>> >>> >>>>> Here is your example with added default values for outputOnly >>> fields: >>> >>>>> >>> >>>>> >>> >>>>> >>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/af5ff3148c1159f71d34fb78c1f63024/raw/b3d4470107ab74e301ed48448ab2a4f4154672e0/ManyClocks_John.x3d >>> >>>>> >>> >>>>> This could be fixed in x3dom, by always setting some default >>> value. Is >>> >>>>> there a list of recommended defaults for each data type if no >>> other source >>> >>>>> of defaults is available? For SFTime it seems to be -1. >>> >>>>> >>> >>>>> >>> >>>>> -Andreas >>> >>>>> >>> >>>>> >>> >>>>> On Mon, Feb 3, 2025 at 7:39?AM Andreas Plesch < >>> andreasplesch at gmail.com> >>> >>>>> wrote: >>> >>>>> >>> >>>>>> Hi John, >>> >>>>>> >>> >>>>>> On Mon, Feb 3, 2025 at 12:48?AM John Carlson >>> >>>>>> wrote: >>> >>>>>> >>> >>>>>>> Andreas, "startTime" is an accessType outputOnly field, so why >>> do I >>> >>>>>>> need to provide a value attribute in fieldValue? I'm kind of >>> confused. >>> >>>>>>> I'm probably missing something in the spec. >>> >>>>>>> >>> >>>>>> >>> >>>>>> You are right, I only outlined scenarios where the accessType >>> allows >>> >>>>>> input or initialization.. >>> >>>>>> In the outputOnly case it is not necessary to provide a fieldValue >>> >>>>>> node at all since there is no value which can be provided. >>> Providing the >>> >>>>>> node would indeed be confusing, to both the user code reader and >>> any X3D >>> >>>>>> browser. >>> >>>>>> I believe the spec. is silent on this case in any encoding. >>> >>>>>> >>> >>>>>> Best, Andreas >>> >>>>>> >>> >>>>>> Thanks for any clarification. >>> >>>>>>> >>> >>>>>>> I have finally enabled schematron on the project, but I'm >>> finding it >>> >>>>>>> hard to understand the messages, and modifications that I make, >>> while >>> >>>>>>> removing the immediate problems, seem to move the problems >>> elsewhere. >>> >>>>>>> >>> >>>>>>> Explaining why I need a "startTime" fieldValue value is my main >>> lack >>> >>>>>>> of understanding, but perhaps I need a whole review of >>> accessType. >>> >>>>>>> >>> >>>>>>> Castle Model Converter reports: >>> >>>>>>> >>> >>>>>>> castle-model-converter: Warning: X3D: X3D XML: >>> element >>> >>>>>>> references unknown field name "enabled" >>> >>>>>>> castle-model-converter: Warning: X3D: X3D XML: >>> element >>> >>>>>>> references unknown field name "startTime" >>> >>>>>>> castle-model-converter: Warning: X3D: X3D XML: >>> element >>> >>>>>>> references unknown field name "stopTime" >>> >>>>>>> >>> >>>>>>> I will try providing a field value in the ProtoInterface >>> >>>>>>> >>> >>>>>>> If I "cleanup" enabled, startTime and stopTime, I get: >>> >>>>>>> >>> >>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>> >>>>>>> "MenuItem", event "inputTrue" references (by "IS" clause) >>> non-existing >>> >>>>>>> event "enabled" >>> >>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>> >>>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) >>> non-existing >>> >>>>>>> event "startTime" >>> >>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>> >>>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) >>> non-existing >>> >>>>>>> event "stopTime" >>> >>>>>>> >>> >>>>>>> I guess what I conclude at this point is, startTime and stopTime >>> are >>> >>>>>>> bad DEF names, but what about enabled as a field? The dominoes >>> are falling. >>> >>>>>>> >>> >>>>>>> About your two scenarios in the other message, perhaps this is >>> >>>>>>> revealing. >>> >>>>>>> >>> >>>>>>> See attached attempt to fix original issue, which resulted in the >>> >>>>>>> above. >>> >>>>>>> >>> >>>>>>> John >>> >>>>>>> >>> >>>>>>> On Sun, Feb 2, 2025 at 3:59?PM Andreas Plesch < >>> >>>>>>> andreasplesch at gmail.com> wrote: >>> >>>>>>> >>> >>>>>>>> I think x3dom, reasonably, expects a value for the fieldValue >>> nodes: >>> >>>>>>>> >>> >>>>>>>> For example: >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> and others. >>> >>>>>>>> >>> >>>>>>>> On Sun, Feb 2, 2025 at 5:42?AM John Carlson >> > >>> >>>>>>>> wrote: >>> >>>>>>>> >>> >>>>>>>>> Andreas, Joe, >>> >>>>>>>>> >>> >>>>>>>>> Reset Button, Reset_Clock added. >>> >>>>>>>>> >>> >>>>>>>>> See attached zip for details, or visit link; >>> >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> >>> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>> >>>>>>>>> >>> >>>>>>>>> For some reason, this link doesn't show the live scene? >>> >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> >>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>> >>>>>>>>> >>> >>>>>>>>> Puzzled, haven't researched it yet. Looks good in Sunrize and >>> >>>>>>>>> X_ITE, will try FreeWRL next. >>> >>>>>>>>> >>> >>>>>>>>> John >>> >>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>> >>> >>>>>>>> -- >>> >>>>>>>> Andreas Plesch >>> >>>>>>>> Waltham, MA 02453 >>> >>>>>>>> >>> >>>>>>> >>> >>>>>> >>> >>>>>> -- >>> >>>>>> Andreas Plesch >>> >>>>>> Waltham, MA 02453 >>> >>>>>> >>> >>>>> >>> >>>>> >>> >>>>> -- >>> >>>>> Andreas Plesch >>> >>>>> Waltham, MA 02453 >>> >>>>> >>> >>>> >>> -------------- next part -------------- >>> An HTML attachment was scrubbed... >>> URL: < >>> http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20250212/6f37d6ce/attachment.html >>> > >>> >>> ------------------------------ >>> >>> Subject: Digest Footer >>> >>> _______________________________________________ >>> x3d-public mailing list >>> x3d-public at web3d.org >>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>> >>> >>> ------------------------------ >>> >>> End of x3d-public Digest, Vol 191, Issue 57 >>> ******************************************* >> >> >> >> -- >> Andreas Plesch >> Waltham, MA 02453 >> >> >> > > > -- > Andreas Plesch > Waltham, MA 02453 > -- Andreas Plesch Waltham, MA 02453 -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Sat Feb 15 13:42:38 2025 From: yottzumm at gmail.com (John Carlson) Date: Sat, 15 Feb 2025 15:42:38 -0600 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: Message-ID: Looks great, Andreas, much appreciated improvement to x3dom. Hopefully, with these 2 browsers working with HAnimDisplacer, we can see even more cross-browser comparable HAnim functionality. So now I have to get off my butt and do something in Blender HAnim import/export. Thanks for your efforts! On Sat, Feb 15, 2025 at 3:25?PM Andreas Plesch wrote: > Hi, > > the x3dom editor now uses an experimental version with much improved > performance for HAnimDisplacers: > > > https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d > > This experimental x3dom version is available at > > https://andreasplesch.github.io/x3dom/dist/ > > Feel free to use and test it. Some tests are available at > > https://andreasplesch.github.io/x3dom/test/ > > Have fun, -Andreas > > On Wed, Feb 12, 2025 at 11:27?AM Andreas Plesch > wrote: > >> Hi, >> >> I took a first stab at Displacers in Segments for x3dom and use it now in >> the editor: >> >> >> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/ManyClocks.x3d >> >> This is experimental and mostly for testing purposes. If there is an >> example combining Displacers in both Joints and Segments that would be >> interesting as it is not necessarily expected to work. >> The experimental implementation is inefficient and expensive as it is >> weight_changed event driven. If you activate multiple displacers the frame >> rate starts to drop. It probably is not very useful at this point. >> >> Fee free to give it a try, -Andreas >> >> On Wed, Feb 5, 2025, 4:11?PM Andreas Plesch >> wrote: >> >>> Hi John, >>> >>> Thanks. I found the tongue.x3d example but if you can create another one >>> that would be helpful in general. >>> >>> You vastly overestimate my ability and availability ;) This would be a >>> longer term project. I have an idea what to do. >>> >>> Andreas >>> >>> >>> On Wed, Feb 5, 2025, 1:31?PM John Carlson wrote: >>> >>>> I had one I sent to Holger, probably derived from this one: >>>> >>>> >>>> https://github.com/coderextreme/ci2had/blob/main/resources/JinMouthStretch.x3d >>>> >>>> >>>> What I would do (again) is take out all the segments but the tongue. >>>> >>>> There?s no menus involved in this one. >>>> >>>> If you need further assistance, like a smaller example, I can help. >>>> Also all the Jin*.x3d FACS action units can also provide examples. >>>> >>>> I?ll be pretty unbusy today. I can allocate some time for creating a >>>> model, make sure it animates, etc. >>>> >>>> If you?re able to allocate some time today, great, we have an HAnim >>>> meeting tomorrow and showing off X3DOM editor using Displacers would be >>>> fantastic! >>>> >>>> Remember there?s a coord field in HAnimSegment that the HAnimDisplacer >>>> operates on! >>>> >>>> John >>>> >>>> On Wed, Feb 5, 2025 at 12:01?PM Andreas Plesch >>>> wrote: >>>> >>>>> Hi John, >>>>> >>>>> The reason is that Displacers are currently implemented in x3dom only >>>>> for Joints, but not for Segments, unfortunately. Do you know of a simple >>>>> but instructive test case of Segments with Displacers ? >>>>> >>>>> Andreas >>>>> >>>>> >>>>> On Tue, Feb 4, 2025, 2:33?PM John Carlson wrote: >>>>> >>>>>> I will try to test this in castle model converter. >>>>>> >>>>>> I did try setting a value for the outputOnly fields, but the >>>>>> converter wouldn?t shut up. >>>>>> >>>>>> The model below doesn?t seem to animate when one presses the menu >>>>>> items. Did you get it to animate? >>>>>> >>>>>> On Tue, Feb 4, 2025 at 12:27?PM Andreas Plesch < >>>>>> andreasplesch at gmail.com> wrote: >>>>>> >>>>>>> Hi John, all, >>>>>>> >>>>>>> It turns out that x3dom currently expects a default value for Proto >>>>>>> fields even for outputOnly fields. This is due to how Proto fields are >>>>>>> initialized. They always need to have a value. While the spec. does not >>>>>>> require this, it seems still good practice to always define a default value >>>>>>> in the ProtoInterface. There may be a case where an outputOnly field is >>>>>>> used in ISing where a valid value would be expected. There may be other >>>>>>> corner cases. >>>>>>> >>>>>>> Here is your example with added default values for outputOnly fields: >>>>>>> >>>>>>> >>>>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/af5ff3148c1159f71d34fb78c1f63024/raw/b3d4470107ab74e301ed48448ab2a4f4154672e0/ManyClocks_John.x3d >>>>>>> >>>>>>> This could be fixed in x3dom, by always setting some default value. >>>>>>> Is there a list of recommended defaults for each data type if no other >>>>>>> source of defaults is available? For SFTime it seems to be -1. >>>>>>> >>>>>>> >>>>>>> -Andreas >>>>>>> >>>>>>> >>>>>>> On Mon, Feb 3, 2025 at 7:39?AM Andreas Plesch < >>>>>>> andreasplesch at gmail.com> wrote: >>>>>>> >>>>>>>> Hi John, >>>>>>>> >>>>>>>> On Mon, Feb 3, 2025 at 12:48?AM John Carlson >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Andreas, "startTime" is an accessType outputOnly field, so why do >>>>>>>>> I need to provide a value attribute in fieldValue? I'm kind of confused. >>>>>>>>> I'm probably missing something in the spec. >>>>>>>>> >>>>>>>> >>>>>>>> You are right, I only outlined scenarios where the accessType >>>>>>>> allows input or initialization.. >>>>>>>> In the outputOnly case it is not necessary to provide a fieldValue >>>>>>>> node at all since there is no value which can be provided. Providing the >>>>>>>> node would indeed be confusing, to both the user code reader and any X3D >>>>>>>> browser. >>>>>>>> I believe the spec. is silent on this case in any encoding. >>>>>>>> >>>>>>>> Best, Andreas >>>>>>>> >>>>>>>> Thanks for any clarification. >>>>>>>>> >>>>>>>>> I have finally enabled schematron on the project, but I'm finding >>>>>>>>> it hard to understand the messages, and modifications that I make, while >>>>>>>>> removing the immediate problems, seem to move the problems elsewhere. >>>>>>>>> >>>>>>>>> Explaining why I need a "startTime" fieldValue value is my main >>>>>>>>> lack of understanding, but perhaps I need a whole review of accessType. >>>>>>>>> >>>>>>>>> Castle Model Converter reports: >>>>>>>>> >>>>>>>>> castle-model-converter: Warning: X3D: X3D XML: >>>>>>>>> element references unknown field name "enabled" >>>>>>>>> castle-model-converter: Warning: X3D: X3D XML: >>>>>>>>> element references unknown field name "startTime" >>>>>>>>> castle-model-converter: Warning: X3D: X3D XML: >>>>>>>>> element references unknown field name "stopTime" >>>>>>>>> >>>>>>>>> I will try providing a field value in the ProtoInterface >>>>>>>>> >>>>>>>>> If I "cleanup" enabled, startTime and stopTime, I get: >>>>>>>>> >>>>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>>>>> "MenuItem", event "inputTrue" references (by "IS" clause) non-existing >>>>>>>>> event "enabled" >>>>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) non-existing >>>>>>>>> event "startTime" >>>>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) non-existing >>>>>>>>> event "stopTime" >>>>>>>>> >>>>>>>>> I guess what I conclude at this point is, startTime and stopTime >>>>>>>>> are bad DEF names, but what about enabled as a field? The dominoes are >>>>>>>>> falling. >>>>>>>>> >>>>>>>>> About your two scenarios in the other message, perhaps this is >>>>>>>>> revealing. >>>>>>>>> >>>>>>>>> See attached attempt to fix original issue, which resulted in the >>>>>>>>> above. >>>>>>>>> >>>>>>>>> John >>>>>>>>> >>>>>>>>> On Sun, Feb 2, 2025 at 3:59?PM Andreas Plesch < >>>>>>>>> andreasplesch at gmail.com> wrote: >>>>>>>>> >>>>>>>>>> I think x3dom, reasonably, expects a value for the fieldValue >>>>>>>>>> nodes: >>>>>>>>>> >>>>>>>>>> For example: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> and others. >>>>>>>>>> >>>>>>>>>> On Sun, Feb 2, 2025 at 5:42?AM John Carlson >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Andreas, Joe, >>>>>>>>>>> >>>>>>>>>>> Reset Button, Reset_Clock added. >>>>>>>>>>> >>>>>>>>>>> See attached zip for details, or visit link; >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>>>>>>> >>>>>>>>>>> For some reason, this link doesn't show the live scene? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>>>>>>> >>>>>>>>>>> Puzzled, haven't researched it yet. Looks good in Sunrize and >>>>>>>>>>> X_ITE, will try FreeWRL next. >>>>>>>>>>> >>>>>>>>>>> John >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Andreas Plesch >>>>>>>>>> Waltham, MA 02453 >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Andreas Plesch >>>>>>>> Waltham, MA 02453 >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Andreas Plesch >>>>>>> Waltham, MA 02453 >>>>>>> >>>>>> > > -- > Andreas Plesch > Waltham, MA 02453 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Sat Feb 15 13:49:28 2025 From: yottzumm at gmail.com (John Carlson) Date: Sat, 15 Feb 2025 15:49:28 -0600 Subject: [x3d-public] Displacer and normals ? In-Reply-To: References: Message-ID: Great idea, Andreas, being able to select a fraction of the mesh for animation. I?ll have to think about how to import and export animations from Blender in this way. John On Sat, Feb 15, 2025 at 3:35?PM Andreas Plesch via x3d-public < x3d-public at web3d.org> wrote: > Non-linear displacement paths > >> >> It would be probably feasible from an implementation perspective to have >> displacers with weight (key) ranges for piecewise linear interpolations to >> approximate curved displacement paths. Thinking about it, it may already be >> possible to design a CoordinateInterpolator of _displacement_ keyValues >> which gets routed to the displacement field of a displacer, with a constant >> weight of 1. So animation then happens by changing displacement values >> directly rather than weight values. This would allow for arbitrary >> displacement paths and does not need any changes, still allowing targeting >> vertex subsets and composing. Might be worth testing, seems interesting. >> > > This idea seems to work. Here is a simple example based on John's > Tongue.x3d > > > https://raw.githubusercontent.com/andreasplesch/x3dom/refs/heads/HAnim_displacers/test/functional/hanim/tongueCurved.x3d > [ Use Alt-Q to flip line wrapping of long lines. ] > > It adds an additional displacement step halfways through the animation > which has non-linear z displacements. > > Could be interesting. > > -Andreas > > -Andreas >> >> On Wed, Feb 12, 2025 at 10:58?PM Joe D Williams >> wrote: >> >>> I think degenerate triangles, ones that flip from ccw to cw, or overlap >>> or >>> >>> whatever messes up a triangle when any of all of its points get moved >>> >>> is purely result of author error(s) in setting the parameter(s). >>> >>> >>> >>> Whatever happens with normals of triangles moved or destroyed by >>> Displacer >>> >>> must match what happens with points moved by joint-driven skin >>> animations >>> >>> which can also mess up, and by points moved by CoordinateInterpolator, >>> >>> same as any morphing operation. >>> >>> Normals can also be set by the author each frame if desired. >>> >>> >>> >>> Maybe some help given in authortime but not any sort of >>> >>> enumerated error except undefined in runtime since this visual effect; >>> >>> it is just an artifact of bad data. >>> >>> Esp likey when deformable face is actually composed of multiple shapes >>> >>> and they must blend regardless of the combinations of shapes >>> >>> that move to make the motion for a pose. >>> >>> Always? much easier with single basic mesh for the face and and then >>> >>> add features and accessories animated individually? >>> >>> >>> >>> One of the limitations with Displacer is that it is just a single scaled >>> 3D vector, >>> >>> meaning it has a fixed relative direction regardless of the weight >>> applied. >>> >>> When a curved displacement is required, then point motion can be >>> >>> controlled using joint rotation, like the eyeball. >>> >>> In some cases,a CoordinateInterpolator may be used to move points >>> around. >>> >>> Texture position and rotation can be animated. >>> >>> >>> >>> Since all these Displacer nodes have been produced by finding the >>> >>> simple 3D vector difference between the first and last data point >>> >>> of a source CoordinateInterpolator it is likely that some displacements >>> >>> do not produce exact same movement of a point just because the >>> >>> original interpolator keyValue keyframe data points described a curved >>> path. >>> >>> >>> >>> Sure, we can update the 3D vector direction each frame if we want to, >>> >>> but I would like to see a Displacer which could use multiple sets of >>> vectors >>> >>> interpolated to produce computed keyframes like other interpolators. >>> >>> For each point there could be a set of vectors where the output value for >>> >>> point movement is the result of interpolation between >>> >>> adjacent key time (weight) keyValue 3D vectors. >>> >>> >>> >>> So, more fun with x3d HAnim >>> >>> Thanks, >>> >>> Joe >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: Extensible 3D (X3D) Graphics public discussion < >>> x3d-public at web3d.org> >>> Sent: Feb 12, 2025 9:11 AM >>> To: X3D Graphics public mailing list >>> Cc: Andreas Plesch >>> Subject: Re: [x3d-public] Displacer and normals ? >>> >>> >>> >>> Responses below: >>> >>> >>>> Date: Tue, 11 Feb 2025 15:58:40 -0600 >>>> From: John Carlson >>>> To: "Extensible 3D (X3D) Graphics public discussion" >>>> >>>> Subject: Re: [x3d-public] Displacer and normals ? >>>> >>>> Did you get the black tongue effect? I?ve seen that in Sunrize, and >>>> reported it there. Holger had a response about providing normals. >>> >>> >>> I found https://github.com/create3000/sunrize/issues/9 >>> >>> Yes, I think this is similar. x-ite/sunrize just may not automatically >>> recalculate normals for performance reasons which in some cases may be >>> beneficial by avoiding the effects of degenerate triangles. >>> >>> >>>> The displacers were taken from CoordinateInterpolators in the >>>> HumanoidAnimation/FacialAnimation X3D archive. >>>> >>>> https://www.web3d.org/x3d/content/examples/HumanoidAnimation/FacialAnimation/index.html >>>> Perhaps we could derive normals from those examples, realizing only one >>>> set >>>> of meshes is chosen for the final version. >>>> >>>> It?s relevant, because I will be providing a unified skin mesh for FACS, >>>> and it would be nice to provide normals. >>> >>> >>> I noticed the effect actually only in combined displacers/morphers, eg. >>> the Contempt combo. That brings up the future question of how pre-computed >>> normals from multiple displacers may be combined, maybe just by averaging >>> the slerped orientation from each. >>> There may have been studies on how to best recombine facial >>> subexpressions for a valid result. >>> >>> -Andreas >>> >>> >>>> >>>> On Tue, Feb 11, 2025 at 3:41?PM Andreas Plesch via x3d-public < >>>> x3d-public at web3d.org> wrote: >>>> >>>> > I noticed that some displacers cause degenerate or flipped triangles >>>> which >>>> > may cause rendering problems, mostly due to problems calculating >>>> > automatically a good normal vector. >>>> > >>>> > In general, for best rendering results, it is necessary to provide >>>> > precomputed normals. rather than rely on automatic normal >>>> calculations. Was >>>> > there a discussion on how to have displacers provide precomputed >>>> normals >>>> > along with the displacement of the vertices ? That would help with >>>> > rendering quality, and may be necessary for some use cases. >>>> > >>>> > This may be deemed a long term feature to consider. >>>> > >>>> > Perhaps an idea would be a MFRotation normalRotations field which has >>>> the >>>> > rotation required to rotate the normal (per vertex, or perhaps per >>>> face) >>>> > from the rest orientation to the final orientation. Weights are >>>> applied >>>> > with slerp. For animation authors it would be probably easier to be >>>> able to >>>> > just directly provide the final orientation. >>>> > >>>> > Any feedback or comment much welcome, -Andreas >>>> > >>>> > >>>> > -- >>>> > Andreas Plesch >>>> > Waltham, MA 02453 >>>> > _______________________________________________ >>>> > x3d-public mailing list >>>> > x3d-public at web3d.org >>>> > http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>> > >>>> -------------- next part -------------- >>>> An HTML attachment was scrubbed... >>>> URL: < >>>> http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20250211/a4be3c1a/attachment-0001.html >>>> > >>>> >>>> ------------------------------ >>>> >>>> Message: 3 >>>> Date: Wed, 12 Feb 2025 11:27:59 -0500 >>>> From: Andreas Plesch >>>> To: John Carlson >>>> Cc: Holger Seelig , X3D Graphics public >>>> mailing list , Joe D Williams >>>> >>>> Subject: Re: [x3d-public] Turning on and off simultaneous animations >>>> individually >>>> Message-ID: >>>> < >>>> CAKdk67vXRSz1pM4QLjcxuCQHfjY4LUT924cSmX7rPAasroPUCw at mail.gmail.com> >>>> Content-Type: text/plain; charset="utf-8" >>>> >>>> Hi, >>>> >>>> I took a first stab at Displacers in Segments for x3dom and use it now >>>> in >>>> the editor: >>>> >>>> >>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/ManyClocks.x3d >>>> >>>> This is experimental and mostly for testing purposes. If there is an >>>> example combining Displacers in both Joints and Segments that would be >>>> interesting as it is not necessarily expected to work. >>>> The experimental implementation is inefficient and expensive as it is >>>> weight_changed event driven. If you activate multiple displacers the >>>> frame >>>> rate starts to drop. It probably is not very useful at this point. >>>> >>>> Fee free to give it a try, -Andreas >>>> >>>> On Wed, Feb 5, 2025, 4:11?PM Andreas Plesch >>>> wrote: >>>> >>>> > Hi John, >>>> > >>>> > Thanks. I found the tongue.x3d example but if you can create another >>>> one >>>> > that would be helpful in general. >>>> > >>>> > You vastly overestimate my ability and availability ;) This would be a >>>> > longer term project. I have an idea what to do. >>>> > >>>> > Andreas >>>> > >>>> > >>>> > On Wed, Feb 5, 2025, 1:31?PM John Carlson wrote: >>>> > >>>> >> I had one I sent to Holger, probably derived from this one: >>>> >> >>>> >> >>>> >> >>>> https://github.com/coderextreme/ci2had/blob/main/resources/JinMouthStretch.x3d >>>> >> >>>> >> >>>> >> What I would do (again) is take out all the segments but the tongue. >>>> >> >>>> >> There?s no menus involved in this one. >>>> >> >>>> >> If you need further assistance, like a smaller example, I can help. >>>> Also >>>> >> all the Jin*.x3d FACS action units can also provide examples. >>>> >> >>>> >> I?ll be pretty unbusy today. I can allocate some time for creating a >>>> >> model, make sure it animates, etc. >>>> >> >>>> >> If you?re able to allocate some time today, great, we have an HAnim >>>> >> meeting tomorrow and showing off X3DOM editor using Displacers would >>>> be >>>> >> fantastic! >>>> >> >>>> >> Remember there?s a coord field in HAnimSegment that the >>>> HAnimDisplacer >>>> >> operates on! >>>> >> >>>> >> John >>>> >> >>>> >> On Wed, Feb 5, 2025 at 12:01?PM Andreas Plesch < >>>> andreasplesch at gmail.com> >>>> >> wrote: >>>> >> >>>> >>> Hi John, >>>> >>> >>>> >>> The reason is that Displacers are currently implemented in x3dom >>>> only >>>> >>> for Joints, but not for Segments, unfortunately. Do you know of a >>>> simple >>>> >>> but instructive test case of Segments with Displacers ? >>>> >>> >>>> >>> Andreas >>>> >>> >>>> >>> >>>> >>> On Tue, Feb 4, 2025, 2:33?PM John Carlson >>>> wrote: >>>> >>> >>>> >>>> I will try to test this in castle model converter. >>>> >>>> >>>> >>>> I did try setting a value for the outputOnly fields, but the >>>> converter >>>> >>>> wouldn?t shut up. >>>> >>>> >>>> >>>> The model below doesn?t seem to animate when one presses the menu >>>> >>>> items. Did you get it to animate? >>>> >>>> >>>> >>>> On Tue, Feb 4, 2025 at 12:27?PM Andreas Plesch < >>>> andreasplesch at gmail.com> >>>> >>>> wrote: >>>> >>>> >>>> >>>>> Hi John, all, >>>> >>>>> >>>> >>>>> It turns out that x3dom currently expects a default value for >>>> Proto >>>> >>>>> fields even for outputOnly fields. This is due to how Proto >>>> fields are >>>> >>>>> initialized. They always need to have a value. While the spec. >>>> does not >>>> >>>>> require this, it seems still good practice to always define a >>>> default value >>>> >>>>> in the ProtoInterface. There may be a case where an outputOnly >>>> field is >>>> >>>>> used in ISing where a valid value would be expected. There may be >>>> other >>>> >>>>> corner cases. >>>> >>>>> >>>> >>>>> Here is your example with added default values for outputOnly >>>> fields: >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/af5ff3148c1159f71d34fb78c1f63024/raw/b3d4470107ab74e301ed48448ab2a4f4154672e0/ManyClocks_John.x3d >>>> >>>>> >>>> >>>>> This could be fixed in x3dom, by always setting some default >>>> value. Is >>>> >>>>> there a list of recommended defaults for each data type if no >>>> other source >>>> >>>>> of defaults is available? For SFTime it seems to be -1. >>>> >>>>> >>>> >>>>> >>>> >>>>> -Andreas >>>> >>>>> >>>> >>>>> >>>> >>>>> On Mon, Feb 3, 2025 at 7:39?AM Andreas Plesch < >>>> andreasplesch at gmail.com> >>>> >>>>> wrote: >>>> >>>>> >>>> >>>>>> Hi John, >>>> >>>>>> >>>> >>>>>> On Mon, Feb 3, 2025 at 12:48?AM John Carlson >>> > >>>> >>>>>> wrote: >>>> >>>>>> >>>> >>>>>>> Andreas, "startTime" is an accessType outputOnly field, so why >>>> do I >>>> >>>>>>> need to provide a value attribute in fieldValue? I'm kind of >>>> confused. >>>> >>>>>>> I'm probably missing something in the spec. >>>> >>>>>>> >>>> >>>>>> >>>> >>>>>> You are right, I only outlined scenarios where the accessType >>>> allows >>>> >>>>>> input or initialization.. >>>> >>>>>> In the outputOnly case it is not necessary to provide a >>>> fieldValue >>>> >>>>>> node at all since there is no value which can be provided. >>>> Providing the >>>> >>>>>> node would indeed be confusing, to both the user code reader and >>>> any X3D >>>> >>>>>> browser. >>>> >>>>>> I believe the spec. is silent on this case in any encoding. >>>> >>>>>> >>>> >>>>>> Best, Andreas >>>> >>>>>> >>>> >>>>>> Thanks for any clarification. >>>> >>>>>>> >>>> >>>>>>> I have finally enabled schematron on the project, but I'm >>>> finding it >>>> >>>>>>> hard to understand the messages, and modifications that I make, >>>> while >>>> >>>>>>> removing the immediate problems, seem to move the problems >>>> elsewhere. >>>> >>>>>>> >>>> >>>>>>> Explaining why I need a "startTime" fieldValue value is my main >>>> lack >>>> >>>>>>> of understanding, but perhaps I need a whole review of >>>> accessType. >>>> >>>>>>> >>>> >>>>>>> Castle Model Converter reports: >>>> >>>>>>> >>>> >>>>>>> castle-model-converter: Warning: X3D: X3D XML: >>>> element >>>> >>>>>>> references unknown field name "enabled" >>>> >>>>>>> castle-model-converter: Warning: X3D: X3D XML: >>>> element >>>> >>>>>>> references unknown field name "startTime" >>>> >>>>>>> castle-model-converter: Warning: X3D: X3D XML: >>>> element >>>> >>>>>>> references unknown field name "stopTime" >>>> >>>>>>> >>>> >>>>>>> I will try providing a field value in the ProtoInterface >>>> >>>>>>> >>>> >>>>>>> If I "cleanup" enabled, startTime and stopTime, I get: >>>> >>>>>>> >>>> >>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>> >>>>>>> "MenuItem", event "inputTrue" references (by "IS" clause) >>>> non-existing >>>> >>>>>>> event "enabled" >>>> >>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>> >>>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) >>>> non-existing >>>> >>>>>>> event "startTime" >>>> >>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>> >>>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) >>>> non-existing >>>> >>>>>>> event "stopTime" >>>> >>>>>>> >>>> >>>>>>> I guess what I conclude at this point is, startTime and >>>> stopTime are >>>> >>>>>>> bad DEF names, but what about enabled as a field? The dominoes >>>> are falling. >>>> >>>>>>> >>>> >>>>>>> About your two scenarios in the other message, perhaps this is >>>> >>>>>>> revealing. >>>> >>>>>>> >>>> >>>>>>> See attached attempt to fix original issue, which resulted in >>>> the >>>> >>>>>>> above. >>>> >>>>>>> >>>> >>>>>>> John >>>> >>>>>>> >>>> >>>>>>> On Sun, Feb 2, 2025 at 3:59?PM Andreas Plesch < >>>> >>>>>>> andreasplesch at gmail.com> wrote: >>>> >>>>>>> >>>> >>>>>>>> I think x3dom, reasonably, expects a value for the fieldValue >>>> nodes: >>>> >>>>>>>> >>>> >>>>>>>> For example: >>>> >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> and others. >>>> >>>>>>>> >>>> >>>>>>>> On Sun, Feb 2, 2025 at 5:42?AM John Carlson < >>>> yottzumm at gmail.com> >>>> >>>>>>>> wrote: >>>> >>>>>>>> >>>> >>>>>>>>> Andreas, Joe, >>>> >>>>>>>>> >>>> >>>>>>>>> Reset Button, Reset_Clock added. >>>> >>>>>>>>> >>>> >>>>>>>>> See attached zip for details, or visit link; >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>> >>>>>>>>> >>>> >>>>>>>>> For some reason, this link doesn't show the live scene? >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>> >>>>>>>>> >>>> >>>>>>>>> Puzzled, haven't researched it yet. Looks good in Sunrize and >>>> >>>>>>>>> X_ITE, will try FreeWRL next. >>>> >>>>>>>>> >>>> >>>>>>>>> John >>>> >>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> -- >>>> >>>>>>>> Andreas Plesch >>>> >>>>>>>> Waltham, MA 02453 >>>> >>>>>>>> >>>> >>>>>>> >>>> >>>>>> >>>> >>>>>> -- >>>> >>>>>> Andreas Plesch >>>> >>>>>> Waltham, MA 02453 >>>> >>>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> -- >>>> >>>>> Andreas Plesch >>>> >>>>> Waltham, MA 02453 >>>> >>>>> >>>> >>>> >>>> -------------- next part -------------- >>>> An HTML attachment was scrubbed... >>>> URL: < >>>> http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20250212/6f37d6ce/attachment.html >>>> > >>>> >>>> ------------------------------ >>>> >>>> Subject: Digest Footer >>>> >>>> _______________________________________________ >>>> x3d-public mailing list >>>> x3d-public at web3d.org >>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>> >>>> >>>> ------------------------------ >>>> >>>> End of x3d-public Digest, Vol 191, Issue 57 >>>> ******************************************* >>> >>> >>> >>> -- >>> Andreas Plesch >>> Waltham, MA 02453 >>> >>> >>> >> >> >> -- >> Andreas Plesch >> Waltham, MA 02453 >> > > > -- > Andreas Plesch > Waltham, MA 02453 > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joedwil at earthlink.net Sat Feb 15 18:55:00 2025 From: joedwil at earthlink.net (joedwil at earthlink.net) Date: Sun, 16 Feb 2025 02:55:00 +0000 Subject: [x3d-public] HAnimDisplacer effect on coord.point Message-ID: <2eee59f2-28bb-9443-f1b8-9f25048d1283@earthlink.net> > coord.point changes are very very expensive quickly, Right, the processing time gets expensive as the number of points moved. If level 1 segment geometry where the mesh is driven directly by a joint, then it easier since weight is always 1. For level 2 skin, the the weight (radial movement) applied by maybe multiple joints needs to be computed for each point. Finally, for both levels, the displacements for selected set of points needs to be applied. This implies multiple passes on the subject coordinates? Whatever, these operations are common where the applications deal with a complete mesh and with sparse points of a mesh for blending. . > with reference to CoordinateInterpolator, These are useful when controlling all points of a target mesh. All points of a mesh must be included and same number of points at each keyframe. This style was used in first step of the current example x3d FACS because face geometry is made from multiple shapes. CoordinateInterpolater sets for each shape for each elemental action moved the points. This was simplified to using the same face for each action example and then replaced the CIs with sets of Displacers. Now have developed further to combine individual actions to make a specific expression which consists of multiple elemental movements. However, I think we want to evolve towards a basic single mesh face with some individual shapes for like teeth, hair, eyeballs, eyelids, tongue, maybe ears? and using joint nodes to control, where appropriate. Regardless of how the points are moved for the next frame, it has to be considered that geometry points will be moved directly by joint rotations, by a weighting algorithm using multiple joint rotation inputs, and by one or more scalar-driven Displacer inputs. Thanks for HAnim, Joe -----Message----- From: Holger Seelig Sent: Feb 9, 2025 11:23 AM To: Andreas Plesch Cc: X3D , Joseph D Williams , Carol McDonald Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point I don't think so, coord.point changes are very very expensive quickly, and as Michalis said earlier, with reference to CoordinateInterpolator, we should get rid of them. Holger-- Holger Seelig Leipzig, Germany holger.seelig at yahoo.de https://create3000.github.io/x_ite/ Am 09.02.2025 um 19:44 schrieb Andreas Plesch : Yes, that is an option. However,coord.point changes are very very expensive quickly, and as Michalis said earlier, with reference to CoordinateInterpolator, we should get rid of them. Andreas On Sun, Feb 9, 2025, 1:40?PM Holger Seelig wrote: X_ITE applies the HAnimDisplacers in the shader, thus no coord.point field has to be changed.Maybe that helps. Best regards, Holger -- Holger Seelig Leipzig, Germany holger.seelig at yahoo.de (mailto:holger.seelig at yahoo.de) https://create3000.github.io/x_ite/ Am 09.02.2025 um 19:33 schrieb Andreas Plesch via x3d-public : That would be the point field of a Coordinate node https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/rendering.html#Coordinate which is used by the coord field of https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimSegment Andreas On Sun, Feb 9, 2025, 12:36?PM Joe D Williams wrote: > coord node emit a point_changed event sorry,I don't see a field anywhere with that event. Displacer is likely to change several points when new weight is sent. All part of the cascade to produce the changed mesh? Thanks, Joe -----Original Message----- From: Andreas Plesch Sent: Feb 9, 2025 4:25 AM To: Brutzman, Donald (Don) (CIV) Cc: Extensible 3D (X3D) Graphics public discussion , Carol McDonald , Joe D Williams , John Carlson Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point Don, Joe and John Thanks for collecting these references. But I am not sure if there is an answer to my original question. Let me rephrase a bit the question: After a Displacer contained in a Segment node receives a set_weight input, should then the coord node emit a point_changed event ? I do not think HAnim is concerned about that, so it is really a X3D question. Thanks, Andreas On Sun, Feb 9, 2025, 12:49?AM Brutzman, Donald (Don) (CIV) wrote: Thanks for pointing in the right direction John. Direct links to functional requirements for Displacer in HAnim 2.0 specification: * HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, Clause 4 Concepts, 4.7 Displacer object * https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#DisplacerObject * HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, Clause 6 Object interfaces, 6.6 Displacer * https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer and * X3D 4.0 Architecture, Clause 26 Humanoid Animation (HAnim) component, 26.3.1 HAnimDisplacer * https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimDisplacer and informative * X3D Tooltips, HAnimDisplacer * https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimDisplacer Thanks for implementation efforts and careful scrutiny. Questions and potential issues/clarifications/corrections are always welcome. all the best, Don -- Don Brutzman Naval Postgraduate School, Code USW/Br brutzman at nps.edu (mailto:brutzman at nps.edu) Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149 X3D graphics, virtual worlds, navy robotics https://faculty.nps.edu/brutzman From: x3d-public on behalf of John Carlson via x3d-public Sent: Saturday, February 8, 2025 3:43 AM To: Extensible 3D (X3D) Graphics public discussion ; Carol McDonald ; Joe D Williams Cc: John Carlson ; Andreas Plesch Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point Here’s what HAnim spec says under Displacer: https://www.web3d.org/documents/specifications/19774/V2.0/index.html “For the Displacer objects that are contained in the displacers field of the Segment objects, the displacements are defined and applied in the Segment coordinate system. The base mesh for the morphed Segment is the original mesh defined in the Segment.” And here’s what it says under Segment: “ The coord field is used for Segment objects that have deformable meshes and shall contain coordinates referenced from the indexed mesh for the Segment object. The coordinates are given the same name as the Segment object, but with a "_coords" appended (e.g.,"skull_coords").” displacements are an offset from the mesh, with weight from 0 to 1. So weight times displacement is total offset from base mesh. 0 weight = no offset, 1 weight = full displacements offset The Coordinate point is maintained to handle weight = 0. Weight ranges from 0 to 1, but double check. Joe or Carol might know where to find it in the HAnim spec. I believe the answer is, “during rendering,”. Since weight can vary with animation, and so can displacements, AFAIK. More than one displacer can be applied to the mesh. I have not read the spec. John On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public wrote: https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer does not directly explain what the effect of the displacer on the coord.point field of the containing HAnimSegment is. But it mentions the coord.point field and seems to imply that the coord.point field is involved. So the question is if the Displacer should alter the coord.point field in order to achieve a graphical displacement, or if the Browser should only apply the displacements during rendering without a change in the coord.point field ? This is relevant if the coord.point field is accessed by routes or scripts, in addition to displacers. Thanks for any feedback or ideas, Andreas -- Andreas Plesch Waltham, MA 02453 _______________________________________________ x3d-public mailing list x3d-public at web3d.org (mailto:x3d-public at web3d.org) http://web3d.org/mailman/listinfo/x3d-public_web3d.org _______________________________________________ x3d-public mailing list x3d-public at web3d.org (mailto:x3d-public at web3d.org) http://web3d.org/mailman/listinfo/x3d-public_web3d.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From joedwil at earthlink.net Sat Feb 15 19:02:18 2025 From: joedwil at earthlink.net (joedwil at earthlink.net) Date: Sun, 16 Feb 2025 03:02:18 +0000 Subject: [x3d-public] Turning on and off simultaneous animations individually Message-ID: <7bc76808-bdde-e9b0-3f4d-f2356ba5a0b0@earthlink.net> This is great step. Is there a stop, reset all anims button? Thanks, Joe -----Original Message----- From: Andreas Plesch Sent: Feb 15, 2025 1:25 PM To: X3D Graphics public mailing list Cc: Joe D Williams , John Carlson Subject: Re: Turning on and off simultaneous animations individually Hi, the x3dom editor now uses an experimental version with much improved performance for HAnimDisplacers: https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d This experimental x3dom version is available at https://andreasplesch.github.io/x3dom/dist/ Feel free to use and test it. Some tests are available at https://andreasplesch.github.io/x3dom/test/ Have fun, -Andreas On Wed, Feb 12, 2025 at 11:27?AM Andreas Plesch wrote: Hi, I took a first stab at Displacers in Segments for x3dom and use it now in the editor: https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/ManyClocks.x3d This is experimental and mostly for testing purposes. If there is an example combining Displacers in both Joints and Segments that would be interesting as it is not necessarily expected to work. The experimental implementation is inefficient and expensive as it is weight_changed event driven. If you activate multiple displacers the frame rate starts to drop. It probably is not very useful at this point. Fee free to give it a try, -Andreas On Wed, Feb 5, 2025, 4:11?PM Andreas Plesch wrote: Hi John, Thanks. I found the tongue.x3d example but if you can create another one that would be helpful in general. You vastly overestimate my ability and availability ;) This would be a longer term project. I have an idea what to do. Andreas On Wed, Feb 5, 2025, 1:31?PM John Carlson wrote: I had one I sent to Holger, probably derived from this one: https://github.com/coderextreme/ci2had/blob/main/resources/JinMouthStretch.x3d What I would do (again) is take out all the segments but the tongue. There’s no menus involved in this one. If you need further assistance, like a smaller example, I can help. Also all the Jin*.x3d FACS action units can also provide examples. I’ll be pretty unbusy today. I can allocate some time for creating a model, make sure it animates, etc. If you’re able to allocate some time today, great, we have an HAnim meeting tomorrow and showing off X3DOM editor using Displacers would be fantastic! Remember there’s a coord field in HAnimSegment that the HAnimDisplacer operates on! John On Wed, Feb 5, 2025 at 12:01?PM Andreas Plesch wrote: Hi John, The reason is that Displacers are currently implemented in x3dom only for Joints, but not for Segments, unfortunately. Do you know of a simple but instructive test case of Segments with Displacers ? Andreas On Tue, Feb 4, 2025, 2:33?PM John Carlson wrote: I will try to test this in castle model converter. I did try setting a value for the outputOnly fields, but the converter wouldn’t shut up. The model below doesn’t seem to animate when one presses the menu items. Did you get it to animate? On Tue, Feb 4, 2025 at 12:27?PM Andreas Plesch wrote: Hi John, all, It turns out that x3dom currently expects a default value for Proto fields even for outputOnly fields. This is due to how Proto fields are initialized. They always need to have a value. While the spec. does not require this, it seems still good practice to always define a default value in the ProtoInterface. There may be a case where an outputOnly field is used in ISing where a valid value would be expected. There may be other corner cases. Here is your example with added default values for outputOnly fields: https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/af5ff3148c1159f71d34fb78c1f63024/raw/b3d4470107ab74e301ed48448ab2a4f4154672e0/ManyClocks_John.x3d This could be fixed in x3dom, by always setting some default value. Is there a list of recommended defaults for each data type if no other source of defaults is available? For SFTime it seems to be -1. -Andreas On Mon, Feb 3, 2025 at 7:39?AM Andreas Plesch wrote: Hi John, On Mon, Feb 3, 2025 at 12:48?AM John Carlson wrote: Andreas, "startTime" is an accessType outputOnly field, so why do I need to provide a value attribute in fieldValue? I'm kind of confused. I'm probably missing something in the spec. You are right, I only outlined scenarios where the accessType allows input or initialization.. In the outputOnly case it is not necessary to provide a fieldValue node at all since there is no value which can be provided. Providing the node would indeed be confusing, to both the user code reader and any X3D browser. I believe the spec. is silent on this case in any encoding. Best, Andreas Thanks for any clarification. I have finally enabled schematron on the project, but I'm finding it hard to understand the messages, and modifications that I make, while removing the immediate problems, seem to move the problems elsewhere. Explaining why I need a "startTime" fieldValue value is my main lack of understanding, but perhaps I need a whole review of accessType. Castle Model Converter reports: castle-model-converter: Warning: X3D: X3D XML: element references unknown field name "enabled" castle-model-converter: Warning: X3D: X3D XML: element references unknown field name "startTime" castle-model-converter: Warning: X3D: X3D XML: element references unknown field name "stopTime" I will try providing a field value in the ProtoInterface If I "cleanup" enabled, startTime and stopTime, I get: castle-model-converter: Warning: VRML/X3D: Within prototype "MenuItem", event "inputTrue" references (by "IS" clause) non-existing event "enabled" castle-model-converter: Warning: VRML/X3D: Within prototype "MenuItem", event "triggerTime" references (by "IS" clause) non-existing event "startTime" castle-model-converter: Warning: VRML/X3D: Within prototype "MenuItem", event "triggerTime" references (by "IS" clause) non-existing event "stopTime" I guess what I conclude at this point is, startTime and stopTime are bad DEF names, but what about enabled as a field? The dominoes are falling. About your two scenarios in the other message, perhaps this is revealing. See attached attempt to fix original issue, which resulted in the above. John On Sun, Feb 2, 2025 at 3:59?PM Andreas Plesch wrote: I think x3dom, reasonably, expects a value for the fieldValue nodes: For example: and others. On Sun, Feb 2, 2025 at 5:42?AM John Carlson wrote: Andreas, Joe, Reset Button, Reset_Clock added. See attached zip for details, or visit link; https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d For some reason, this link doesn't show the live scene? https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d Puzzled, haven't researched it yet. Looks good in Sunrize and X_ITE, will try FreeWRL next. John -- Andreas Plesch Waltham, MA 02453 -- Andreas Plesch Waltham, MA 02453 -- Andreas Plesch Waltham, MA 02453 -- Andreas Plesch Waltham, MA 02453 -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Sat Feb 15 19:46:58 2025 From: yottzumm at gmail.com (John Carlson) Date: Sat, 15 Feb 2025 21:46:58 -0600 Subject: [x3d-public] HAnimDisplacer effect on coord.point In-Reply-To: <2eee59f2-28bb-9443-f1b8-9f25048d1283@earthlink.net> References: <2eee59f2-28bb-9443-f1b8-9f25048d1283@earthlink.net> Message-ID: Okay, Joe. I can create a list of ?mesh? names, and maybe someone can figure out which meshes go together to form the face, then we can revisit how to merge the meshes? On Sat, Feb 15, 2025 at 8:55?PM Joe D Williams via x3d-public < x3d-public at web3d.org> wrote: > > coord.point changes are very very expensive quickly, > > > > Right, the processing time gets expensive as the number of points moved. > > If level 1 segment geometry where the mesh is driven directly by a joint, > then it easier since weight is always 1. > > For level 2 skin, the the weight (radial movement) applied by maybe > multiple joints needs to be computed for each point. > > Finally, for both levels, the displacements for selected set of points > needs to be applied. > > This implies multiple passes on the subject coordinates? > > Whatever, these operations are common where the applications deal with > > a complete mesh and with sparse points of a mesh for blending. . > > > > > with reference to CoordinateInterpolator, > > > > These are useful when controlling all points of a target mesh. > > All points of a mesh must be included and same number of points at each > keyframe. > > This style was used in first step of the current example x3d FACS because > > face geometry is made from multiple shapes. CoordinateInterpolater sets > > for each shape for each elemental action moved the points. > > This was simplified to using the same face for each action example > > and then replaced the CIs with sets of Displacers. > > Now have developed further to combine individual actions to make a > > specific expression which consists of multiple elemental movements. > > However, I think we want to evolve towards a basic single mesh face > > with some individual shapes for like teeth, hair, eyeballs, eyelids, > tongue, maybe ears? > > and using joint nodes to control, where appropriate. > > > > Regardless of how the points are moved for the next frame, it has to be > > considered that geometry points will be moved directly by joint > rotations, > > by a weighting algorithm using multiple joint rotation inputs, > > and by one or more scalar-driven Displacer inputs. > > > > Thanks for HAnim, > > Joe > > > > > > > > > > > > > > > > > > > > -----Message----- > > From: Holger Seelig > Sent: Feb 9, 2025 11:23 AM > To: Andreas Plesch > Cc: X3D , Joseph D Williams , > Carol McDonald > Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point > > > I don't think so, coord.point changes are very very expensive quickly, and > as Michalis said earlier, with reference to CoordinateInterpolator, we > should get rid of them. > > Holger > -- > Holger Seelig > Leipzig, Germany > > holger.seelig at yahoo.de > https://create3000.github.io/x_ite/ > > Am 09.02.2025 um 19:44 schrieb Andreas Plesch : > Yes, that is an option. However,coord.point changes are very very > expensive quickly, and as Michalis said earlier, with reference to > CoordinateInterpolator, we should get rid of them. > > Andreas > > On Sun, Feb 9, 2025, 1:40?PM Holger Seelig wrote: > >> X_ITE applies the HAnimDisplacers in the shader, thus no coord.point >> field has to be changed. >> Maybe that helps. >> >> Best regards, >> Holger >> >> -- >> Holger Seelig >> Leipzig, Germany >> >> holger.seelig at yahoo.de >> https://create3000.github.io/x_ite/ >> >> Am 09.02.2025 um 19:33 schrieb Andreas Plesch via x3d-public < >> x3d-public at web3d.org>: >> >> That would be the point field of a Coordinate node >> >> >> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/rendering.html#Coordinate >> >> which is used by the coord field of >> >> >> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimSegment >> >> Andreas >> >> On Sun, Feb 9, 2025, 12:36?PM Joe D Williams >> wrote: >> >>> > coord node emit a point_changed event >>> >>> >>> sorry,I don't see a field anywhere with that event. Displacer is likely >>> to change several points when new weight is sent. All part of the cascade >>> to produce the changed mesh? >>> Thanks, >>> Joe >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: Andreas Plesch >>> Sent: Feb 9, 2025 4:25 AM >>> To: Brutzman, Donald (Don) (CIV) >>> Cc: Extensible 3D (X3D) Graphics public discussion , >>> Carol McDonald , Joe D Williams < >>> joedwil at earthlink.net>, John Carlson >>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>> >>> >>> Don, Joe and John >>> >>> Thanks for collecting these references. >>> >>> But I am not sure if there is an answer to my original question. Let me >>> rephrase a bit the question: >>> >>> After a Displacer contained in a Segment node receives a set_weight >>> input, should then the coord node emit a point_changed event ? >>> >>> I do not think HAnim is concerned about that, so it is really a X3D >>> question. >>> >>> Thanks, Andreas >>> >>> On Sun, Feb 9, 2025, 12:49?AM Brutzman, Donald (Don) (CIV) < >>> brutzman at nps.edu> wrote: >>> >>>> Thanks for pointing in the right direction John. >>>> >>>> Direct links to functional requirements for Displacer in HAnim 2.0 >>>> specification: >>>> >>>> - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, >>>> Clause 4 Concepts, 4.7 Displacer object >>>> - >>>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#DisplacerObject >>>> >>>> - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, >>>> Clause 6 Object interfaces, 6.6 Displacer >>>> - >>>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer >>>> >>>> and >>>> >>>> - X3D 4.0 Architecture, Clause 26 Humanoid Animation (HAnim) >>>> component, 26.3.1 HAnimDisplacer >>>> - >>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimDisplacer >>>> >>>> and informative >>>> >>>> - X3D Tooltips, HAnimDisplacer >>>> - https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimDisplacer >>>> >>>> Thanks for implementation efforts and careful scrutiny. >>>> >>>> Questions and potential issues/clarifications/corrections are always >>>> welcome. >>>> >>>> >>>> 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 >>>> https://faculty.nps.edu/brutzman >>>> >>>> >>>> >>>> ------------------------------ >>>> *From:* x3d-public on behalf of John >>>> Carlson via x3d-public >>>> *Sent:* Saturday, February 8, 2025 3:43 AM >>>> *To:* Extensible 3D (X3D) Graphics public discussion < >>>> x3d-public at web3d.org>; Carol McDonald ; Joe D >>>> Williams >>>> *Cc:* John Carlson ; Andreas Plesch < >>>> andreasplesch at gmail.com> >>>> *Subject:* Re: [x3d-public] HAnimDisplacer effect on coord.point >>>> >>>> Here?s what HAnim spec says under Displacer: >>>> >>>> https://www.web3d.org/documents/specifications/19774/V2.0/index.html >>>> >>>> ?For the *Displacer* objects that are contained in the *displacers* field >>>> of the *Segment* objects, the *displacements* are defined and applied >>>> in the *Segment* coordinate system. The base mesh for the morphed >>>> *Segment* is the original mesh defined in the *Segment*.? >>>> >>>> And here?s what it says under Segment: >>>> >>>> ? >>>> >>>> The *coord* field is used for *Segment* objects that have deformable >>>> meshes and shall contain coordinates referenced from the indexed mesh for >>>> the *Segment* object. The coordinates are given the same name as the >>>> *Segment* object, but with a "_coords" appended (e.g.,"skull_coords").? >>>> displacements are an offset from the mesh, with weight from 0 to 1. >>>> So weight times displacement is total offset from base mesh. 0 weight = no >>>> offset, 1 weight = full displacements offset >>>> >>>> The Coordinate point is maintained to handle weight = 0. Weight ranges >>>> from 0 to 1, but double check. >>>> >>>> Joe or Carol might know where to find it in the HAnim spec. >>>> >>>> I believe the answer is, ?during rendering,?. Since weight can vary >>>> with animation, and so can displacements, AFAIK. More than one displacer >>>> can be applied to the mesh. >>>> >>>> I have not read the spec. >>>> >>>> John >>>> >>>> >>>> >>>> On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public < >>>> x3d-public at web3d.org> wrote: >>>> >>>> >>>> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer >>>> >>>> does not directly explain what the effect of the displacer on the >>>> coord.point field of the containing HAnimSegment is. But it mentions the >>>> coord.point field and seems to imply that the coord.point field is involved. >>>> >>>> So the question is if the Displacer should alter the coord.point field >>>> in order to achieve a graphical displacement, or if the Browser should only >>>> apply the displacements during rendering without a change in the >>>> coord.point field ? >>>> >>>> This is relevant if the coord.point field is accessed by routes or >>>> scripts, in addition to displacers. >>>> >>>> Thanks for any feedback or ideas, >>>> >>>> Andreas >>>> >>>> -- >>>> Andreas Plesch >>>> Waltham, MA 02453 >>>> _______________________________________________ >>>> x3d-public mailing list >>>> x3d-public at web3d.org >>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>> >>>> >>> >> _______________________________________________ >> x3d-public mailing list >> x3d-public at web3d.org >> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >> >> > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Sat Feb 15 19:47:36 2025 From: yottzumm at gmail.com (John Carlson) Date: Sat, 15 Feb 2025 21:47:36 -0600 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: <7bc76808-bdde-e9b0-3f4d-f2356ba5a0b0@earthlink.net> References: <7bc76808-bdde-e9b0-3f4d-f2356ba5a0b0@earthlink.net> Message-ID: Yes, at the bottom of the emotions menu. John On Sat, Feb 15, 2025 at 9:02?PM wrote: > This is great step. Is there a stop, reset all anims button? > > Thanks, > > Joe > > > > -----Original Message----- > From: Andreas Plesch > Sent: Feb 15, 2025 1:25 PM > To: X3D Graphics public mailing list > Cc: Joe D Williams , John Carlson < > yottzumm at gmail.com> > Subject: Re: Turning on and off simultaneous animations individually > > > Hi, > > the x3dom editor now uses an experimental version with much improved > performance for HAnimDisplacers: > > > https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d > > This experimental x3dom version is available at > > https://andreasplesch.github.io/x3dom/dist/ > > Feel free to use and test it. Some tests are available at > > https://andreasplesch.github.io/x3dom/test/ > > Have fun, -Andreas > > On Wed, Feb 12, 2025 at 11:27?AM Andreas Plesch > wrote: > >> Hi, >> >> I took a first stab at Displacers in Segments for x3dom and use it now in >> the editor: >> >> >> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/ManyClocks.x3d >> >> This is experimental and mostly for testing purposes. If there is an >> example combining Displacers in both Joints and Segments that would be >> interesting as it is not necessarily expected to work. >> The experimental implementation is inefficient and expensive as it is >> weight_changed event driven. If you activate multiple displacers the frame >> rate starts to drop. It probably is not very useful at this point. >> >> Fee free to give it a try, -Andreas >> >> On Wed, Feb 5, 2025, 4:11?PM Andreas Plesch >> wrote: >> >>> Hi John, >>> >>> Thanks. I found the tongue.x3d example but if you can create another one >>> that would be helpful in general. >>> >>> You vastly overestimate my ability and availability ;) This would be a >>> longer term project. I have an idea what to do. >>> >>> Andreas >>> >>> >>> On Wed, Feb 5, 2025, 1:31?PM John Carlson wrote: >>> >>>> I had one I sent to Holger, probably derived from this one: >>>> >>>> >>>> https://github.com/coderextreme/ci2had/blob/main/resources/JinMouthStretch.x3d >>>> >>>> >>>> What I would do (again) is take out all the segments but the tongue. >>>> >>>> There?s no menus involved in this one. >>>> >>>> If you need further assistance, like a smaller example, I can help. >>>> Also all the Jin*.x3d FACS action units can also provide examples. >>>> >>>> I?ll be pretty unbusy today. I can allocate some time for creating a >>>> model, make sure it animates, etc. >>>> >>>> If you?re able to allocate some time today, great, we have an HAnim >>>> meeting tomorrow and showing off X3DOM editor using Displacers would be >>>> fantastic! >>>> >>>> Remember there?s a coord field in HAnimSegment that the HAnimDisplacer >>>> operates on! >>>> >>>> John >>>> >>>> On Wed, Feb 5, 2025 at 12:01?PM Andreas Plesch >>>> wrote: >>>> >>>>> Hi John, >>>>> >>>>> The reason is that Displacers are currently implemented in x3dom only >>>>> for Joints, but not for Segments, unfortunately. Do you know of a simple >>>>> but instructive test case of Segments with Displacers ? >>>>> >>>>> >>>>> Andreas >>>>> >>>>> >>>>> On Tue, Feb 4, 2025, 2:33?PM John Carlson wrote: >>>>> >>>>>> I will try to test this in castle model converter. >>>>>> >>>>>> I did try setting a value for the outputOnly fields, but the >>>>>> converter wouldn?t shut up. >>>>>> >>>>>> The model below doesn?t seem to animate when one presses the menu >>>>>> items. Did you get it to animate? >>>>>> >>>>>> On Tue, Feb 4, 2025 at 12:27?PM Andreas Plesch < >>>>>> andreasplesch at gmail.com> wrote: >>>>>> >>>>>>> Hi John, all, >>>>>>> >>>>>>> It turns out that x3dom currently expects a default value for Proto >>>>>>> fields even for outputOnly fields. This is due to how Proto fields are >>>>>>> initialized. They always need to have a value. While the spec. does not >>>>>>> require this, it seems still good practice to always define a default value >>>>>>> in the ProtoInterface. There may be a case where an outputOnly field is >>>>>>> used in ISing where a valid value would be expected. There may be other >>>>>>> corner cases. >>>>>>> >>>>>>> Here is your example with added default values for outputOnly fields: >>>>>>> >>>>>>> >>>>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/af5ff3148c1159f71d34fb78c1f63024/raw/b3d4470107ab74e301ed48448ab2a4f4154672e0/ManyClocks_John.x3d >>>>>>> >>>>>>> This could be fixed in x3dom, by always setting some default value. >>>>>>> Is there a list of recommended defaults for each data type if no other >>>>>>> source of defaults is available? For SFTime it seems to be -1. >>>>>>> >>>>>>> >>>>>>> -Andreas >>>>>>> >>>>>>> >>>>>>> On Mon, Feb 3, 2025 at 7:39?AM Andreas Plesch < >>>>>>> andreasplesch at gmail.com> wrote: >>>>>>> >>>>>>>> Hi John, >>>>>>>> >>>>>>>> On Mon, Feb 3, 2025 at 12:48?AM John Carlson >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Andreas, "startTime" is an accessType outputOnly field, so why do >>>>>>>>> I need to provide a value attribute in fieldValue? I'm kind of confused. >>>>>>>>> I'm probably missing something in the spec. >>>>>>>>> >>>>>>>> >>>>>>>> You are right, I only outlined scenarios where the accessType >>>>>>>> allows input or initialization.. >>>>>>>> In the outputOnly case it is not necessary to provide a fieldValue >>>>>>>> node at all since there is no value which can be provided. Providing the >>>>>>>> node would indeed be confusing, to both the user code reader and any X3D >>>>>>>> browser. >>>>>>>> I believe the spec. is silent on this case in any encoding. >>>>>>>> >>>>>>>> Best, Andreas >>>>>>>> >>>>>>>> >>>>>>>>> Thanks for any clarification. >>>>>>>>> >>>>>>>>> I have finally enabled schematron on the project, but I'm finding >>>>>>>>> it hard to understand the messages, and modifications that I make, while >>>>>>>>> removing the immediate problems, seem to move the problems elsewhere. >>>>>>>>> >>>>>>>>> Explaining why I need a "startTime" fieldValue value is my main >>>>>>>>> lack of understanding, but perhaps I need a whole review of accessType. >>>>>>>>> >>>>>>>>> Castle Model Converter reports: >>>>>>>>> >>>>>>>>> castle-model-converter: Warning: X3D: X3D XML: >>>>>>>>> element references unknown field name "enabled" >>>>>>>>> castle-model-converter: Warning: X3D: X3D XML: >>>>>>>>> element references unknown field name "startTime" >>>>>>>>> castle-model-converter: Warning: X3D: X3D XML: >>>>>>>>> element references unknown field name "stopTime" >>>>>>>>> >>>>>>>>> I will try providing a field value in the ProtoInterface >>>>>>>>> >>>>>>>>> If I "cleanup" enabled, startTime and stopTime, I get: >>>>>>>>> >>>>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>>>>> "MenuItem", event "inputTrue" references (by "IS" clause) non-existing >>>>>>>>> event "enabled" >>>>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) non-existing >>>>>>>>> event "startTime" >>>>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) non-existing >>>>>>>>> event "stopTime" >>>>>>>>> >>>>>>>>> I guess what I conclude at this point is, startTime and stopTime >>>>>>>>> are bad DEF names, but what about enabled as a field? The dominoes are >>>>>>>>> falling. >>>>>>>>> >>>>>>>>> About your two scenarios in the other message, perhaps this is >>>>>>>>> revealing. >>>>>>>>> >>>>>>>>> See attached attempt to fix original issue, which resulted in the >>>>>>>>> above. >>>>>>>>> >>>>>>>>> John >>>>>>>>> >>>>>>>>> On Sun, Feb 2, 2025 at 3:59?PM Andreas Plesch < >>>>>>>>> andreasplesch at gmail.com> wrote: >>>>>>>>> >>>>>>>>>> I think x3dom, reasonably, expects a value for the fieldValue >>>>>>>>>> nodes: >>>>>>>>>> >>>>>>>>>> For example: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> and others. >>>>>>>>>> >>>>>>>>>> On Sun, Feb 2, 2025 at 5:42?AM John Carlson >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Andreas, Joe, >>>>>>>>>>> >>>>>>>>>>> Reset Button, Reset_Clock added. >>>>>>>>>>> >>>>>>>>>>> See attached zip for details, or visit link; >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>>>>>>> >>>>>>>>>>> For some reason, this link doesn't show the live scene? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>>>>>>> >>>>>>>>>>> Puzzled, haven't researched it yet. Looks good in Sunrize and >>>>>>>>>>> X_ITE, will try FreeWRL next. >>>>>>>>>>> >>>>>>>>>>> John >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Andreas Plesch >>>>>>>>>> Waltham, MA 02453 >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Andreas Plesch >>>>>>>> Waltham, MA 02453 >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Andreas Plesch >>>>>>> Waltham, MA 02453 >>>>>>> >>>>>> > > -- > Andreas Plesch > Waltham, MA 02453 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joedwil at earthlink.net Sat Feb 15 20:04:24 2025 From: joedwil at earthlink.net (joedwil at earthlink.net) Date: Sun, 16 Feb 2025 04:04:24 +0000 Subject: [x3d-public] SFRotation default value spec. inconsistency Message-ID: Doesn't this mean that the _best_ default value, for no rotation, is 'legally' for unit quaternion = 0 0 0 1 because the square root of the sum of the squares of all four components does = 1 ? 0 0 0 0 would not be a legal unit quaternion. While the axis-angle default is 0 0 1 0 as appears in Part 1 is mostly for convenience since many value combinations can produce zero rotation? Also sure shows why axis-angle is so much easier to work with when typing numbers, pitch and yaw and roll for all. Thanks, Joe -----Original Message----- From: Andreas Plesch Sent: Feb 14, 2025 11:36 AM To: Holger Seelig Cc: X3D , Joseph D Williams Subject: Re: [x3d-public] SFRotation default value spec. inconsistency Let me just add for clarity that the length (or norm) of a quaternion includes the fourth, the scalar component. The norm is the square root of the sum of the squares of all four components. Only unit quaternions represent rotations. A (0,0,0,0) quaternion does not represent any rotation (but of course exists outside of rotations). Andreas PS: To add back in some fuzziness, a unit quaternion can only represent a rotation up to 360 degrees. I think there is a mechanism to use non-unit quaternions for larger rotations. On Fri, Feb 14, 2025 at 10:22?AM Holger Seelig wrote: All quaternions must be normalized to be a legal rotation, so the length of the quaternion must always be one. Holger-- Holger Seelig Leipzig, Germany holger.seelig at yahoo.de (mailto:holger.seelig at yahoo.de) https://create3000.github.io/x_ite/ Am 14.02.2025 um 15:38 schrieb Joe D Williams via x3d-public : > So, sensibly, a zero rotation around any axis corresponds to the "zero unit Quaternion" (0, 0, 0, 1 XYZW), Right. Not sure but 0 0 0 0 for unit quaternion might not be legal. I think the values must compute to1 to be legal? Thanks, Joe -----Original Message----- From: Andreas Plesch Sent: Feb 10, 2025 12:37 PM To: Joe D Williams Cc: Extensible 3D (X3D) Graphics public discussion Subject: Re: [x3d-public] SFRotation default value spec. inconsistency https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#_node_rotation has indeed (0, 0, 0, 1 XYZW) as a default value. This is difficult to interpret as a rotation around an axis since the corresponding axis would be at first glance (0 0 0). x3dom converts quaternion (0, 0, 0, 1 XYZW) to (axis),angle (0,0,0),0 as does https://www.andre-gaschler.com/rotationconverter/ . On the other hand both SFRotation (0 0 1 0) and SFRotation (0 1 0 0) are also represented by quaternion (0, 0, 0, 1 XYZW). So, sensibly, a zero rotation around any axis corresponds to the "zero unit Quaternion" (0, 0, 0, 1 XYZW), making it a useful default value for quaternions. But that does not help with choosing a default axis for the SFRotation value. This will rarely matter. A use case may be when a SFRotation is initialized to the X3D default in a Proto but then only the angle is modified by a Proto script with the assumption that the axis is (0 0 1). -Andreas On Mon, Feb 10, 2025 at 12:57?PM Joe D Williams wrote: not zerp, zero -----Original Message----- From: Extensible 3D (X3D) Graphics public discussion Sent: Feb 10, 2025 9:50 AM To: Extensible 3D (X3D) Graphics public discussion , X3D Graphics public mailing list Cc: Joe D Williams , Andreas Plesch Subject: Re: [x3d-public] SFRotation default value spec. inconsistency I think the 0 0 1 0 should be used everywhere for default axis-angle. I thinkI see 'zerp' unit quaternions (as in gltf as 0 0 0 1 XYZW) Thanks, Joe -----Original Message----- From: Extensible 3D (X3D) Graphics public discussion Sent: Feb 10, 2025 8:44 AM To: X3D Graphics public mailing list Cc: Andreas Plesch Subject: Re: [x3d-public] SFRotation default value spec. inconsistency The JS SAI spec. at https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#FieldServices does not list functions for SFColorRGBA, only SFColor. There may be an earlier report. -Andreas On Mon, Feb 10, 2025 at 11:31?AM Andreas Plesch wrote: https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/fieldTypes.html#SFRotationAndMFRotation specifies that (0 0 1 0) is the value of an uninitialized SFRotation given as (x y z a). However, the JS SAI spec. in table 7.18 in https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#SFRotationInstanceCreationFunction effectively makes (0 1 0 0) the default value if no parameters are provided. The inconsistency does not have much of an impact since both are 0 rotations but I believe (0 1 0 0) - a 0 rotation around y - may have been intended as the default. -Andreas -- Andreas Plesch Waltham, MA 02453 -- Andreas Plesch Waltham, MA 02453 -- Andreas Plesch Waltham, MA 02453 _______________________________________________ x3d-public mailing list x3d-public at web3d.org (mailto:x3d-public at web3d.org) http://web3d.org/mailman/listinfo/x3d-public_web3d.org -- Andreas Plesch Waltham, MA 02453 -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Sat Feb 15 20:19:39 2025 From: yottzumm at gmail.com (John Carlson) Date: Sat, 15 Feb 2025 22:19:39 -0600 Subject: [x3d-public] HAnimDisplacer effect on coord.point In-Reply-To: References: <2eee59f2-28bb-9443-f1b8-9f25048d1283@earthlink.net> Message-ID: Here are a list of all mesh roots (prefixes) in FACS. I can attach suffixes to get at different nodes inside the segments, including coord, IFS and displacer. If we merge meshes to create a face mesh, likely segments will merge too, and displacers, or at least coordIndex will be redone in displacer, if we maintain more than one per mesh. If there are additional mesh merges, let me know. If you want a bare list of names, I can do that too. def_prefixes = ["Lower_teeth", "Hair", "__0", "__2", "__4", "Center_lower_vermillion_lip", "Chin", "Glabella", "Left_bulbar_conjunctiva", "Left_cheek", "Left_dorsum", "Left_ear", "Left_eyebrow", "Left_forehead", "Left_lower_eyelid", "Left_lower_vermillion_lip", "Left_nasolabial_cheek", "Left_nostril", "Left_pupil", "Left_temple", "Left_upper_cutaneous_lip", "Left_upper_eyelid", "Left_upper_vermillion_lip", "Left_upper_vermillion_lip001", "Mid_forehead", "Mid_nasal_dorsum", "Mid_upper_vermillion_lip", "Nasal_tip", "Neck", "Occipital_scalp", "Philtrum", "Right_bulbar_conjunctiva", "Right_cheek", "Right_dorsum", "Right_ear", "Right_eyebrow", "Right_forehead", "Right_lower_eyelid", "Right_lower_vermillion_lip", "Right_nasolabial_cheek", "Right_nostril", "Right_pupil", "Right_temple", "Right_upper_cutaneous_lip", "Right_upper_eyelid", "Right_upper_vermillion_lip", "Tongue", "Upper_teeth"] On Sat, Feb 15, 2025 at 9:46?PM John Carlson wrote: > Okay, Joe. > > I can create a list of ?mesh? names, and maybe someone can figure out > which meshes go together to form the face, then we can revisit how to merge > the meshes? > > On Sat, Feb 15, 2025 at 8:55?PM Joe D Williams via x3d-public < > x3d-public at web3d.org> wrote: > >> > coord.point changes are very very expensive quickly, >> >> >> >> Right, the processing time gets expensive as the number of points moved. >> >> If level 1 segment geometry where the mesh is driven directly by a joint, >> then it easier since weight is always 1. >> >> For level 2 skin, the the weight (radial movement) applied by maybe >> multiple joints needs to be computed for each point. >> >> Finally, for both levels, the displacements for selected set of points >> needs to be applied. >> >> This implies multiple passes on the subject coordinates? >> >> Whatever, these operations are common where the applications deal with >> >> a complete mesh and with sparse points of a mesh for blending. . >> >> >> >> > with reference to CoordinateInterpolator, >> >> >> >> These are useful when controlling all points of a target mesh. >> >> All points of a mesh must be included and same number of points at each >> keyframe. >> >> This style was used in first step of the current example x3d FACS because >> >> face geometry is made from multiple shapes. CoordinateInterpolater sets >> >> for each shape for each elemental action moved the points. >> >> This was simplified to using the same face for each action example >> >> and then replaced the CIs with sets of Displacers. >> >> Now have developed further to combine individual actions to make a >> >> specific expression which consists of multiple elemental movements. >> >> However, I think we want to evolve towards a basic single mesh face >> >> with some individual shapes for like teeth, hair, eyeballs, eyelids, >> tongue, maybe ears? >> >> and using joint nodes to control, where appropriate. >> >> >> >> Regardless of how the points are moved for the next frame, it has to be >> >> considered that geometry points will be moved directly by joint >> rotations, >> >> by a weighting algorithm using multiple joint rotation inputs, >> >> and by one or more scalar-driven Displacer inputs. >> >> >> >> Thanks for HAnim, >> >> Joe >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -----Message----- >> >> From: Holger Seelig >> Sent: Feb 9, 2025 11:23 AM >> To: Andreas Plesch >> Cc: X3D , Joseph D Williams , >> Carol McDonald >> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >> >> >> I don't think so, coord.point changes are very very expensive quickly, >> and as Michalis said earlier, with reference to CoordinateInterpolator, we >> should get rid of them. >> >> Holger >> -- >> Holger Seelig >> Leipzig, Germany >> >> holger.seelig at yahoo.de >> https://create3000.github.io/x_ite/ >> >> Am 09.02.2025 um 19:44 schrieb Andreas Plesch : >> Yes, that is an option. However,coord.point changes are very very >> expensive quickly, and as Michalis said earlier, with reference to >> CoordinateInterpolator, we should get rid of them. >> >> Andreas >> >> On Sun, Feb 9, 2025, 1:40?PM Holger Seelig >> wrote: >> >>> X_ITE applies the HAnimDisplacers in the shader, thus no coord.point >>> field has to be changed. >>> Maybe that helps. >>> >>> Best regards, >>> Holger >>> >>> -- >>> Holger Seelig >>> Leipzig, Germany >>> >>> holger.seelig at yahoo.de >>> https://create3000.github.io/x_ite/ >>> >>> Am 09.02.2025 um 19:33 schrieb Andreas Plesch via x3d-public < >>> x3d-public at web3d.org>: >>> >>> That would be the point field of a Coordinate node >>> >>> >>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/rendering.html#Coordinate >>> >>> which is used by the coord field of >>> >>> >>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimSegment >>> >>> Andreas >>> >>> On Sun, Feb 9, 2025, 12:36?PM Joe D Williams >>> wrote: >>> >>>> > coord node emit a point_changed event >>>> >>>> >>>> sorry,I don't see a field anywhere with that event. Displacer is likely >>>> to change several points when new weight is sent. All part of the cascade >>>> to produce the changed mesh? >>>> Thanks, >>>> Joe >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Andreas Plesch >>>> Sent: Feb 9, 2025 4:25 AM >>>> To: Brutzman, Donald (Don) (CIV) >>>> Cc: Extensible 3D (X3D) Graphics public discussion < >>>> x3d-public at web3d.org>, Carol McDonald , Joe D >>>> Williams , John Carlson >>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>> >>>> >>>> Don, Joe and John >>>> >>>> Thanks for collecting these references. >>>> >>>> But I am not sure if there is an answer to my original question. Let me >>>> rephrase a bit the question: >>>> >>>> After a Displacer contained in a Segment node receives a set_weight >>>> input, should then the coord node emit a point_changed event ? >>>> >>>> I do not think HAnim is concerned about that, so it is really a X3D >>>> question. >>>> >>>> Thanks, Andreas >>>> >>>> On Sun, Feb 9, 2025, 12:49?AM Brutzman, Donald (Don) (CIV) < >>>> brutzman at nps.edu> wrote: >>>> >>>>> Thanks for pointing in the right direction John. >>>>> >>>>> Direct links to functional requirements for Displacer in HAnim 2.0 >>>>> specification: >>>>> >>>>> - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, >>>>> Clause 4 Concepts, 4.7 Displacer object >>>>> - >>>>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#DisplacerObject >>>>> >>>>> - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, >>>>> Clause 6 Object interfaces, 6.6 Displacer >>>>> - >>>>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer >>>>> >>>>> and >>>>> >>>>> - X3D 4.0 Architecture, Clause 26 Humanoid Animation (HAnim) >>>>> component, 26.3.1 HAnimDisplacer >>>>> - >>>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimDisplacer >>>>> >>>>> and informative >>>>> >>>>> - X3D Tooltips, HAnimDisplacer >>>>> - https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimDisplacer >>>>> >>>>> Thanks for implementation efforts and careful scrutiny. >>>>> >>>>> Questions and potential issues/clarifications/corrections are always >>>>> welcome. >>>>> >>>>> >>>>> 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 >>>>> https://faculty.nps.edu/brutzman >>>>> >>>>> >>>>> >>>>> ------------------------------ >>>>> *From:* x3d-public on behalf of John >>>>> Carlson via x3d-public >>>>> *Sent:* Saturday, February 8, 2025 3:43 AM >>>>> *To:* Extensible 3D (X3D) Graphics public discussion < >>>>> x3d-public at web3d.org>; Carol McDonald ; Joe D >>>>> Williams >>>>> *Cc:* John Carlson ; Andreas Plesch < >>>>> andreasplesch at gmail.com> >>>>> *Subject:* Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>> >>>>> Here?s what HAnim spec says under Displacer: >>>>> >>>>> https://www.web3d.org/documents/specifications/19774/V2.0/index.html >>>>> >>>>> ?For the *Displacer* objects that are contained in the *displacers* field >>>>> of the *Segment* objects, the *displacements* are defined and applied >>>>> in the *Segment* coordinate system. The base mesh for the morphed >>>>> *Segment* is the original mesh defined in the *Segment*.? >>>>> >>>>> And here?s what it says under Segment: >>>>> >>>>> ? >>>>> >>>>> The *coord* field is used for *Segment* objects that have deformable >>>>> meshes and shall contain coordinates referenced from the indexed mesh for >>>>> the *Segment* object. The coordinates are given the same name as the >>>>> *Segment* object, but with a "_coords" appended (e.g.,"skull_coords" >>>>> ).? >>>>> displacements are an offset from the mesh, with weight from 0 to 1. >>>>> So weight times displacement is total offset from base mesh. 0 weight = no >>>>> offset, 1 weight = full displacements offset >>>>> >>>>> The Coordinate point is maintained to handle weight = 0. Weight >>>>> ranges from 0 to 1, but double check. >>>>> >>>>> Joe or Carol might know where to find it in the HAnim spec. >>>>> >>>>> I believe the answer is, ?during rendering,?. Since weight can vary >>>>> with animation, and so can displacements, AFAIK. More than one displacer >>>>> can be applied to the mesh. >>>>> >>>>> I have not read the spec. >>>>> >>>>> John >>>>> >>>>> >>>>> >>>>> On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public < >>>>> x3d-public at web3d.org> wrote: >>>>> >>>>> >>>>> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer >>>>> >>>>> does not directly explain what the effect of the displacer on the >>>>> coord.point field of the containing HAnimSegment is. But it mentions the >>>>> coord.point field and seems to imply that the coord.point field is involved. >>>>> >>>>> So the question is if the Displacer should alter the coord.point field >>>>> in order to achieve a graphical displacement, or if the Browser should only >>>>> apply the displacements during rendering without a change in the >>>>> coord.point field ? >>>>> >>>>> This is relevant if the coord.point field is accessed by routes or >>>>> scripts, in addition to displacers. >>>>> >>>>> Thanks for any feedback or ideas, >>>>> >>>>> Andreas >>>>> >>>>> -- >>>>> Andreas Plesch >>>>> Waltham, MA 02453 >>>>> _______________________________________________ >>>>> x3d-public mailing list >>>>> x3d-public at web3d.org >>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>>> >>>>> >>>> >>> _______________________________________________ >>> x3d-public mailing list >>> x3d-public at web3d.org >>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>> >>> >> _______________________________________________ >> x3d-public mailing list >> x3d-public at web3d.org >> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Sat Feb 15 20:59:37 2025 From: yottzumm at gmail.com (John Carlson) Date: Sat, 15 Feb 2025 22:59:37 -0600 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: <7bc76808-bdde-e9b0-3f4d-f2356ba5a0b0@earthlink.net> References: <7bc76808-bdde-e9b0-3f4d-f2356ba5a0b0@earthlink.net> Message-ID: BTW, I?m meditating on how to release the Reset button once it?s pressed, currently, one has to press it again. Any insights welcome! John On Sat, Feb 15, 2025 at 9:02?PM wrote: > This is great step. Is there a stop, reset all anims button? > > Thanks, > > Joe > > > > -----Original Message----- > From: Andreas Plesch > Sent: Feb 15, 2025 1:25 PM > To: X3D Graphics public mailing list > Cc: Joe D Williams , John Carlson < > yottzumm at gmail.com> > Subject: Re: Turning on and off simultaneous animations individually > > > Hi, > > the x3dom editor now uses an experimental version with much improved > performance for HAnimDisplacers: > > > https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d > > This experimental x3dom version is available at > > https://andreasplesch.github.io/x3dom/dist/ > > Feel free to use and test it. Some tests are available at > > https://andreasplesch.github.io/x3dom/test/ > > Have fun, -Andreas > > On Wed, Feb 12, 2025 at 11:27?AM Andreas Plesch > wrote: > >> Hi, >> >> I took a first stab at Displacers in Segments for x3dom and use it now in >> the editor: >> >> >> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/ManyClocks.x3d >> >> This is experimental and mostly for testing purposes. If there is an >> example combining Displacers in both Joints and Segments that would be >> interesting as it is not necessarily expected to work. >> The experimental implementation is inefficient and expensive as it is >> weight_changed event driven. If you activate multiple displacers the frame >> rate starts to drop. It probably is not very useful at this point. >> >> Fee free to give it a try, -Andreas >> >> On Wed, Feb 5, 2025, 4:11?PM Andreas Plesch >> wrote: >> >>> Hi John, >>> >>> Thanks. I found the tongue.x3d example but if you can create another one >>> that would be helpful in general. >>> >>> You vastly overestimate my ability and availability ;) This would be a >>> longer term project. I have an idea what to do. >>> >>> Andreas >>> >>> >>> On Wed, Feb 5, 2025, 1:31?PM John Carlson wrote: >>> >>>> I had one I sent to Holger, probably derived from this one: >>>> >>>> >>>> https://github.com/coderextreme/ci2had/blob/main/resources/JinMouthStretch.x3d >>>> >>>> >>>> What I would do (again) is take out all the segments but the tongue. >>>> >>>> There?s no menus involved in this one. >>>> >>>> If you need further assistance, like a smaller example, I can help. >>>> Also all the Jin*.x3d FACS action units can also provide examples. >>>> >>>> I?ll be pretty unbusy today. I can allocate some time for creating a >>>> model, make sure it animates, etc. >>>> >>>> If you?re able to allocate some time today, great, we have an HAnim >>>> meeting tomorrow and showing off X3DOM editor using Displacers would be >>>> fantastic! >>>> >>>> Remember there?s a coord field in HAnimSegment that the HAnimDisplacer >>>> operates on! >>>> >>>> John >>>> >>>> On Wed, Feb 5, 2025 at 12:01?PM Andreas Plesch >>>> wrote: >>>> >>>>> Hi John, >>>>> >>>>> The reason is that Displacers are currently implemented in x3dom only >>>>> for Joints, but not for Segments, unfortunately. Do you know of a simple >>>>> but instructive test case of Segments with Displacers ? >>>>> >>>>> >>>>> Andreas >>>>> >>>>> >>>>> On Tue, Feb 4, 2025, 2:33?PM John Carlson wrote: >>>>> >>>>>> I will try to test this in castle model converter. >>>>>> >>>>>> I did try setting a value for the outputOnly fields, but the >>>>>> converter wouldn?t shut up. >>>>>> >>>>>> The model below doesn?t seem to animate when one presses the menu >>>>>> items. Did you get it to animate? >>>>>> >>>>>> On Tue, Feb 4, 2025 at 12:27?PM Andreas Plesch < >>>>>> andreasplesch at gmail.com> wrote: >>>>>> >>>>>>> Hi John, all, >>>>>>> >>>>>>> It turns out that x3dom currently expects a default value for Proto >>>>>>> fields even for outputOnly fields. This is due to how Proto fields are >>>>>>> initialized. They always need to have a value. While the spec. does not >>>>>>> require this, it seems still good practice to always define a default value >>>>>>> in the ProtoInterface. There may be a case where an outputOnly field is >>>>>>> used in ISing where a valid value would be expected. There may be other >>>>>>> corner cases. >>>>>>> >>>>>>> Here is your example with added default values for outputOnly fields: >>>>>>> >>>>>>> >>>>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/af5ff3148c1159f71d34fb78c1f63024/raw/b3d4470107ab74e301ed48448ab2a4f4154672e0/ManyClocks_John.x3d >>>>>>> >>>>>>> This could be fixed in x3dom, by always setting some default value. >>>>>>> Is there a list of recommended defaults for each data type if no other >>>>>>> source of defaults is available? For SFTime it seems to be -1. >>>>>>> >>>>>>> >>>>>>> -Andreas >>>>>>> >>>>>>> >>>>>>> On Mon, Feb 3, 2025 at 7:39?AM Andreas Plesch < >>>>>>> andreasplesch at gmail.com> wrote: >>>>>>> >>>>>>>> Hi John, >>>>>>>> >>>>>>>> On Mon, Feb 3, 2025 at 12:48?AM John Carlson >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Andreas, "startTime" is an accessType outputOnly field, so why do >>>>>>>>> I need to provide a value attribute in fieldValue? I'm kind of confused. >>>>>>>>> I'm probably missing something in the spec. >>>>>>>>> >>>>>>>> >>>>>>>> You are right, I only outlined scenarios where the accessType >>>>>>>> allows input or initialization.. >>>>>>>> In the outputOnly case it is not necessary to provide a fieldValue >>>>>>>> node at all since there is no value which can be provided. Providing the >>>>>>>> node would indeed be confusing, to both the user code reader and any X3D >>>>>>>> browser. >>>>>>>> I believe the spec. is silent on this case in any encoding. >>>>>>>> >>>>>>>> Best, Andreas >>>>>>>> >>>>>>>> >>>>>>>>> Thanks for any clarification. >>>>>>>>> >>>>>>>>> I have finally enabled schematron on the project, but I'm finding >>>>>>>>> it hard to understand the messages, and modifications that I make, while >>>>>>>>> removing the immediate problems, seem to move the problems elsewhere. >>>>>>>>> >>>>>>>>> Explaining why I need a "startTime" fieldValue value is my main >>>>>>>>> lack of understanding, but perhaps I need a whole review of accessType. >>>>>>>>> >>>>>>>>> Castle Model Converter reports: >>>>>>>>> >>>>>>>>> castle-model-converter: Warning: X3D: X3D XML: >>>>>>>>> element references unknown field name "enabled" >>>>>>>>> castle-model-converter: Warning: X3D: X3D XML: >>>>>>>>> element references unknown field name "startTime" >>>>>>>>> castle-model-converter: Warning: X3D: X3D XML: >>>>>>>>> element references unknown field name "stopTime" >>>>>>>>> >>>>>>>>> I will try providing a field value in the ProtoInterface >>>>>>>>> >>>>>>>>> If I "cleanup" enabled, startTime and stopTime, I get: >>>>>>>>> >>>>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>>>>> "MenuItem", event "inputTrue" references (by "IS" clause) non-existing >>>>>>>>> event "enabled" >>>>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) non-existing >>>>>>>>> event "startTime" >>>>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) non-existing >>>>>>>>> event "stopTime" >>>>>>>>> >>>>>>>>> I guess what I conclude at this point is, startTime and stopTime >>>>>>>>> are bad DEF names, but what about enabled as a field? The dominoes are >>>>>>>>> falling. >>>>>>>>> >>>>>>>>> About your two scenarios in the other message, perhaps this is >>>>>>>>> revealing. >>>>>>>>> >>>>>>>>> See attached attempt to fix original issue, which resulted in the >>>>>>>>> above. >>>>>>>>> >>>>>>>>> John >>>>>>>>> >>>>>>>>> On Sun, Feb 2, 2025 at 3:59?PM Andreas Plesch < >>>>>>>>> andreasplesch at gmail.com> wrote: >>>>>>>>> >>>>>>>>>> I think x3dom, reasonably, expects a value for the fieldValue >>>>>>>>>> nodes: >>>>>>>>>> >>>>>>>>>> For example: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> and others. >>>>>>>>>> >>>>>>>>>> On Sun, Feb 2, 2025 at 5:42?AM John Carlson >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Andreas, Joe, >>>>>>>>>>> >>>>>>>>>>> Reset Button, Reset_Clock added. >>>>>>>>>>> >>>>>>>>>>> See attached zip for details, or visit link; >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>>>>>>> >>>>>>>>>>> For some reason, this link doesn't show the live scene? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>>>>>>> >>>>>>>>>>> Puzzled, haven't researched it yet. Looks good in Sunrize and >>>>>>>>>>> X_ITE, will try FreeWRL next. >>>>>>>>>>> >>>>>>>>>>> John >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Andreas Plesch >>>>>>>>>> Waltham, MA 02453 >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Andreas Plesch >>>>>>>> Waltham, MA 02453 >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Andreas Plesch >>>>>>> Waltham, MA 02453 >>>>>>> >>>>>> > > -- > Andreas Plesch > Waltham, MA 02453 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreasplesch at gmail.com Sat Feb 15 21:11:43 2025 From: andreasplesch at gmail.com (Andreas Plesch) Date: Sun, 16 Feb 2025 00:11:43 -0500 Subject: [x3d-public] SFRotation default value spec. inconsistency In-Reply-To: References: Message-ID: I agree, probably the best default value for a unit quaternion is 0 0 0 1. However, X3D does not concern itself with quaternions, only axis-angle rotations. So the original question remains: Part 1 has axis-angle 0 0 1 0 as default while the JS SAI spec. has 0 1 0 0. Should both list the same default value ? If yes, which one ? I would vote for 0 1 0 0 since rotations around Y seem more common. -Andreas On Sat, Feb 15, 2025 at 11:04?PM wrote: > Doesn't this mean that the _best_ default value, for no rotation, is > 'legally' for unit quaternion = 0 0 0 1 > > because the square root of the sum of the squares of all four components > does = 1 ? > > 0 0 0 0 would not be a legal unit quaternion. > > While the axis-angle default is 0 0 1 0 as appears in Part 1 is mostly for > convenience > > since many value combinations can produce zero rotation? > > Also sure shows why axis-angle is so much easier to work with when typing > numbers, > > pitch and yaw and roll for all. > > Thanks, > > Joe > > > > -----Original Message----- > From: Andreas Plesch > Sent: Feb 14, 2025 11:36 AM > To: Holger Seelig > Cc: X3D , Joseph D Williams > Subject: Re: [x3d-public] SFRotation default value spec. inconsistency > > > Let me just add for clarity that the length (or norm) of a quaternion > includes the fourth, the scalar component. The norm is the square root of > the sum of the squares of all four components. > > Only unit quaternions represent rotations. A (0,0,0,0) quaternion does not > represent any rotation (but of course exists outside of rotations). > > Andreas > > PS: To add back in some fuzziness, a unit quaternion can only represent a > rotation up to 360 degrees. I think there is a mechanism to use non-unit > quaternions for larger rotations. > > On Fri, Feb 14, 2025 at 10:22?AM Holger Seelig > wrote: > >> All quaternions must be normalized to be a legal rotation, so the length >> of the quaternion must always be one. >> >> Holger >> -- >> Holger Seelig >> Leipzig, Germany >> >> holger.seelig at yahoo.de >> https://create3000.github.io/x_ite/ >> >> Am 14.02.2025 um 15:38 schrieb Joe D Williams via x3d-public < >> x3d-public at web3d.org>: >> >> > So, sensibly, a zero rotation around any axis corresponds to the "zero >> unit Quaternion" (0, 0, 0, 1 XYZW), >> >> >> Right. Not sure but 0 0 0 0 for unit quaternion might not be legal. I >> think the values must compute to1 to be legal? >> Thanks, >> Joe >> >> >> >> >> >> -----Original Message----- >> From: Andreas Plesch >> Sent: Feb 10, 2025 12:37 PM >> To: Joe D Williams >> Cc: Extensible 3D (X3D) Graphics public discussion >> Subject: Re: [x3d-public] SFRotation default value spec. inconsistency >> >> >> https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#_node_rotation >> has indeed (0, 0, 0, 1 XYZW) as a default value. >> >> This is difficult to interpret as a rotation around an axis since the >> corresponding axis would be at first glance (0 0 0). >> >> x3dom converts quaternion (0, 0, 0, 1 XYZW) to (axis),angle (0,0,0),0 as >> does https://www.andre-gaschler.com/rotationconverter/ . >> >> On the other hand both SFRotation (0 0 1 0) and SFRotation (0 1 0 0) are >> also represented by quaternion (0, 0, 0, 1 XYZW). >> >> So, sensibly, a zero rotation around any axis corresponds to the "zero >> unit Quaternion" (0, 0, 0, 1 XYZW), making it a useful default value for >> quaternions. But that does not help with choosing a default axis for the >> SFRotation value. >> >> This will rarely matter. A use case may be when a SFRotation is >> initialized to the X3D default in a Proto but then only the angle is >> modified by a Proto script with the assumption that the axis is (0 0 1). >> >> -Andreas >> >> On Mon, Feb 10, 2025 at 12:57?PM Joe D Williams >> wrote: >> >>> not zerp, zero >>> >>> -----Original Message----- >>> From: Extensible 3D (X3D) Graphics public discussion < >>> x3d-public at web3d.org> >>> Sent: Feb 10, 2025 9:50 AM >>> To: Extensible 3D (X3D) Graphics public discussion , >>> X3D Graphics public mailing list >>> Cc: Joe D Williams , Andreas Plesch < >>> andreasplesch at gmail.com> >>> Subject: Re: [x3d-public] SFRotation default value spec. inconsistency >>> >>> >>> I think the 0 0 1 0 should be used everywhere for default axis-angle. >>> I thinkI see 'zerp' unit quaternions (as in gltf as 0 0 0 1 XYZW) >>> Thanks, >>> Joe >>> >>> >>> >>> -----Original Message----- >>> From: Extensible 3D (X3D) Graphics public discussion < >>> x3d-public at web3d.org> >>> Sent: Feb 10, 2025 8:44 AM >>> To: X3D Graphics public mailing list >>> Cc: Andreas Plesch >>> Subject: Re: [x3d-public] SFRotation default value spec. inconsistency >>> >>> >>> The JS SAI spec. at >>> https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#FieldServices >>> >>> does not list functions for SFColorRGBA, only SFColor. There may be an >>> earlier report. -Andreas >>> >>> On Mon, Feb 10, 2025 at 11:31?AM Andreas Plesch >>> wrote: >>> >>>> >>>> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/fieldTypes.html#SFRotationAndMFRotation >>>> >>>> specifies that (0 0 1 0) is the value of an uninitialized SFRotation >>>> given as (x y z a). >>>> >>>> However, the JS SAI spec. in table 7.18 in >>>> https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#SFRotationInstanceCreationFunction >>>> >>>> effectively makes (0 1 0 0) the default value if no parameters are >>>> provided. >>>> >>>> The inconsistency does not have much of an impact since both are 0 >>>> rotations but I believe (0 1 0 0) - a 0 rotation around y - may have been >>>> intended as the default. >>>> >>>> -Andreas >>>> >>>> -- >>>> Andreas Plesch >>>> Waltham, MA 02453 >>>> >>> >>> >>> -- >>> Andreas Plesch >>> Waltham, MA 02453 >>> >>> >>> >>> >>> >> >> >> -- >> Andreas Plesch >> Waltham, MA 02453 >> >> >> _______________________________________________ >> x3d-public mailing list >> x3d-public at web3d.org >> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >> >> > > -- > Andreas Plesch > Waltham, MA 02453 > > > -- Andreas Plesch Waltham, MA 02453 -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger.seelig at yahoo.de Sun Feb 16 00:33:13 2025 From: holger.seelig at yahoo.de (Holger Seelig) Date: Sun, 16 Feb 2025 09:33:13 +0100 Subject: [x3d-public] SFRotation default value spec. inconsistency In-Reply-To: References: Message-ID: <91CD8C49-BC84-4B5A-81C0-85B1DEC709B2@yahoo.de> I think the default value is 0 0 1 0 for rotations. It?s already the case for the old JavaScript VRML 2.0 spec: https://www.web3d.org/documents/specifications/14772/V2.0/part1/fieldsRef.html#SFRotation As well as the Field Type Reference say 0 0 1 0: https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/fieldTypes.html#SFRotationAndMFRotation On the other hand all rotation values in the spec have a 0 0 1 0 rotation as well: https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/Architecture.html Holger -- Holger Seelig Leipzig, Germany holger.seelig at yahoo.de https://create3000.github.io/x_ite/ > Am 16.02.2025 um 06:11 schrieb Andreas Plesch : > > I agree, probably the best default value for a unit quaternion is 0 0 0 1. > > However, X3D does not concern itself with quaternions, only axis-angle rotations. > > So the original question remains: Part 1 has axis-angle 0 0 1 0 as default while the JS SAI spec. has 0 1 0 0. Should both list the same default value ? > > If yes, which one ? I would vote for 0 1 0 0 since rotations around Y seem more common. > > -Andreas > > On Sat, Feb 15, 2025 at 11:04?PM > wrote: >> Doesn't this mean that the _best_ default value, for no rotation, is 'legally' for unit quaternion = 0 0 0 1 >> because the square root of the sum of the squares of all four components does = 1 ? >> 0 0 0 0 would not be a legal unit quaternion. >> While the axis-angle default is 0 0 1 0 as appears in Part 1 is mostly for convenience >> since many value combinations can produce zero rotation? >> Also sure shows why axis-angle is so much easier to work with when typing numbers, >> pitch and yaw and roll for all. >> Thanks, >> Joe >> >> -----Original Message----- >> From: Andreas Plesch > >> Sent: Feb 14, 2025 11:36 AM >> To: Holger Seelig > >> Cc: X3D >, Joseph D Williams > >> Subject: Re: [x3d-public] SFRotation default value spec. inconsistency >> >> >> Let me just add for clarity that the length (or norm) of a quaternion includes the fourth, the scalar component. The norm is the square root of the sum of the squares of all four components. >> >> Only unit quaternions represent rotations. A (0,0,0,0) quaternion does not represent any rotation (but of course exists outside of rotations). >> >> Andreas >> >> PS: To add back in some fuzziness, a unit quaternion can only represent a rotation up to 360 degrees. I think there is a mechanism to use non-unit quaternions for larger rotations. >> >> On Fri, Feb 14, 2025 at 10:22?AM Holger Seelig > wrote: >>> All quaternions must be normalized to be a legal rotation, so the length of the quaternion must always be one. >>> >>> Holger >>> -- >>> Holger Seelig >>> Leipzig, Germany >>> >>> holger.seelig at yahoo.de >>> https://create3000.github.io/x_ite/ >>> >>> Am 14.02.2025 um 15:38 schrieb Joe D Williams via x3d-public >: >>> >>> > So, sensibly, a zero rotation around any axis corresponds to the "zero unit Quaternion" (0, 0, 0, 1 XYZW), >>> >>> Right. Not sure but 0 0 0 0 for unit quaternion might not be legal. I think the values must compute to1 to be legal? >>> Thanks, >>> Joe >>> >>> >>> -----Original Message----- >>> From: Andreas Plesch > >>> Sent: Feb 10, 2025 12:37 PM >>> To: Joe D Williams > >>> Cc: Extensible 3D (X3D) Graphics public discussion > >>> Subject: Re: [x3d-public] SFRotation default value spec. inconsistency >>> >>> >>> https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#_node_rotation >>> has indeed (0, 0, 0, 1 XYZW) as a default value. >>> >>> This is difficult to interpret as a rotation around an axis since the corresponding axis would be at first glance (0 0 0). >>> >>> x3dom converts quaternion (0, 0, 0, 1 XYZW) to (axis),angle (0,0,0),0 as does https://www.andre-gaschler.com/rotationconverter/ . >>> >>> On the other hand both SFRotation (0 0 1 0) and SFRotation (0 1 0 0) are also represented by quaternion (0, 0, 0, 1 XYZW). >>> >>> So, sensibly, a zero rotation around any axis corresponds to the "zero unit Quaternion" (0, 0, 0, 1 XYZW), making it a useful default value for quaternions. But that does not help with choosing a default axis for the SFRotation value. >>> >>> This will rarely matter. A use case may be when a SFRotation is initialized to the X3D default in a Proto but then only the angle is modified by a Proto script with the assumption that the axis is (0 0 1). >>> >>> -Andreas >>> >>> On Mon, Feb 10, 2025 at 12:57?PM Joe D Williams > wrote: >>>> not zerp, zero >>>> -----Original Message----- >>>> From: Extensible 3D (X3D) Graphics public discussion > >>>> Sent: Feb 10, 2025 9:50 AM >>>> To: Extensible 3D (X3D) Graphics public discussion >, X3D Graphics public mailing list > >>>> Cc: Joe D Williams >, Andreas Plesch > >>>> Subject: Re: [x3d-public] SFRotation default value spec. inconsistency >>>> >>>> >>>> I think the 0 0 1 0 should be used everywhere for default axis-angle. >>>> I thinkI see 'zerp' unit quaternions (as in gltf as 0 0 0 1 XYZW) >>>> Thanks, >>>> Joe >>>> >>>> -----Original Message----- >>>> From: Extensible 3D (X3D) Graphics public discussion > >>>> Sent: Feb 10, 2025 8:44 AM >>>> To: X3D Graphics public mailing list > >>>> Cc: Andreas Plesch > >>>> Subject: Re: [x3d-public] SFRotation default value spec. inconsistency >>>> >>>> >>>> The JS SAI spec. at https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#FieldServices >>>> >>>> does not list functions for SFColorRGBA, only SFColor. There may be an earlier report. -Andreas >>>> >>>> On Mon, Feb 10, 2025 at 11:31?AM Andreas Plesch > wrote: >>>>> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/fieldTypes.html#SFRotationAndMFRotation >>>>> >>>>> specifies that (0 0 1 0) is the value of an uninitialized SFRotation given as (x y z a). >>>>> >>>>> However, the JS SAI spec. in table 7.18 in https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#SFRotationInstanceCreationFunction >>>>> >>>>> effectively makes (0 1 0 0) the default value if no parameters are provided. >>>>> >>>>> The inconsistency does not have much of an impact since both are 0 rotations but I believe (0 1 0 0) - a 0 rotation around y - may have been intended as the default. >>>>> >>>>> -Andreas >>>>> >>>>> -- >>>>> Andreas Plesch >>>>> Waltham, MA 02453 >>>> >>>> >>>> >>>> -- >>>> Andreas Plesch >>>> Waltham, MA 02453 >>>> >>>> >>> >>> >>> >>> -- >>> Andreas Plesch >>> Waltham, MA 02453 >>> >>> _______________________________________________ >>> x3d-public mailing list >>> x3d-public at web3d.org >>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >> >> >> >> -- >> Andreas Plesch >> Waltham, MA 02453 >> > > > > -- > Andreas Plesch > Waltham, MA 02453 -------------- next part -------------- An HTML attachment was scrubbed... URL: From joedwil at earthlink.net Sun Feb 16 09:00:02 2025 From: joedwil at earthlink.net (joedwil at earthlink.net) Date: Sun, 16 Feb 2025 17:00:02 +0000 Subject: [x3d-public] SFRotation default value spec. inconsistency Message-ID: <5141b4a5-e819-4cac-03cb-fc05fddde96e@earthlink.net> > Should both (all, everywhere) list the same default value ? Yes, would be my vote. Thanks, Joe -----Original Message----- From: Holger Seelig Sent: Feb 16, 2025 12:33 AM To: Andreas Plesch Cc: Joseph D Williams , X3D Subject: Re: [x3d-public] SFRotation default value spec. inconsistency I think the default value is 0 0 1 0 for rotations. It’s already the case for the old JavaScript VRML 2.0 spec: https://www.web3d.org/documents/specifications/14772/V2.0/part1/fieldsRef.html#SFRotation As well as the Field Type Reference say 0 0 1 0: https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/fieldTypes.html#SFRotationAndMFRotation On the other hand all rotation values in the spec have a 0 0 1 0 rotation as well: https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/Architecture.html Holger -- Holger Seelig Leipzig, Germany holger.seelig at yahoo.de https://create3000.github.io/x_ite/ Am 16.02.2025 um 06:11 schrieb Andreas Plesch : I agree, probably the best default value for a unit quaternion is 0 0 0 1. However, X3D does not concern itself with quaternions, only axis-angle rotations. So the original question remains: Part 1 has axis-angle 0 0 1 0 as default while the JS SAI spec. has 0 1 0 0. Should both list the same default value ? If yes, which one ? I would vote for 0 1 0 0 since rotations around Y seem more common. -Andreas On Sat, Feb 15, 2025 at 11:04?PM wrote: Doesn't this mean that the _best_ default value, for no rotation, is 'legally' for unit quaternion = 0 0 0 1 because the square root of the sum of the squares of all four components does = 1 ? 0 0 0 0 would not be a legal unit quaternion. While the axis-angle default is 0 0 1 0 as appears in Part 1 is mostly for convenience since many value combinations can produce zero rotation? Also sure shows why axis-angle is so much easier to work with when typing numbers, pitch and yaw and roll for all. Thanks, Joe -----Original Message----- From: Andreas Plesch Sent: Feb 14, 2025 11:36 AM To: Holger Seelig Cc: X3D , Joseph D Williams Subject: Re: [x3d-public] SFRotation default value spec. inconsistency Let me just add for clarity that the length (or norm) of a quaternion includes the fourth, the scalar component. The norm is the square root of the sum of the squares of all four components. Only unit quaternions represent rotations. A (0,0,0,0) quaternion does not represent any rotation (but of course exists outside of rotations). Andreas PS: To add back in some fuzziness, a unit quaternion can only represent a rotation up to 360 degrees. I think there is a mechanism to use non-unit quaternions for larger rotations. On Fri, Feb 14, 2025 at 10:22?AM Holger Seelig wrote: All quaternions must be normalized to be a legal rotation, so the length of the quaternion must always be one. Holger-- Holger Seelig Leipzig, Germany holger.seelig at yahoo.de (mailto:holger.seelig at yahoo.de) https://create3000.github.io/x_ite/ Am 14.02.2025 um 15:38 schrieb Joe D Williams via x3d-public : > So, sensibly, a zero rotation around any axis corresponds to the "zero unit Quaternion" (0, 0, 0, 1 XYZW), Right. Not sure but 0 0 0 0 for unit quaternion might not be legal. I think the values must compute to1 to be legal? Thanks, Joe -----Original Message----- From: Andreas Plesch Sent: Feb 10, 2025 12:37 PM To: Joe D Williams Cc: Extensible 3D (X3D) Graphics public discussion Subject: Re: [x3d-public] SFRotation default value spec. inconsistency https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#_node_rotation has indeed (0, 0, 0, 1 XYZW) as a default value. This is difficult to interpret as a rotation around an axis since the corresponding axis would be at first glance (0 0 0). x3dom converts quaternion (0, 0, 0, 1 XYZW) to (axis),angle (0,0,0),0 as does https://www.andre-gaschler.com/rotationconverter/ . On the other hand both SFRotation (0 0 1 0) and SFRotation (0 1 0 0) are also represented by quaternion (0, 0, 0, 1 XYZW). So, sensibly, a zero rotation around any axis corresponds to the "zero unit Quaternion" (0, 0, 0, 1 XYZW), making it a useful default value for quaternions. But that does not help with choosing a default axis for the SFRotation value. This will rarely matter. A use case may be when a SFRotation is initialized to the X3D default in a Proto but then only the angle is modified by a Proto script with the assumption that the axis is (0 0 1). -Andreas On Mon, Feb 10, 2025 at 12:57?PM Joe D Williams wrote: not zerp, zero -----Original Message----- From: Extensible 3D (X3D) Graphics public discussion Sent: Feb 10, 2025 9:50 AM To: Extensible 3D (X3D) Graphics public discussion , X3D Graphics public mailing list Cc: Joe D Williams , Andreas Plesch Subject: Re: [x3d-public] SFRotation default value spec. inconsistency I think the 0 0 1 0 should be used everywhere for default axis-angle. I thinkI see 'zerp' unit quaternions (as in gltf as 0 0 0 1 XYZW) Thanks, Joe -----Original Message----- From: Extensible 3D (X3D) Graphics public discussion Sent: Feb 10, 2025 8:44 AM To: X3D Graphics public mailing list Cc: Andreas Plesch Subject: Re: [x3d-public] SFRotation default value spec. inconsistency The JS SAI spec. at https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#FieldServices does not list functions for SFColorRGBA, only SFColor. There may be an earlier report. -Andreas On Mon, Feb 10, 2025 at 11:31?AM Andreas Plesch wrote: https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/fieldTypes.html#SFRotationAndMFRotation specifies that (0 0 1 0) is the value of an uninitialized SFRotation given as (x y z a). However, the JS SAI spec. in table 7.18 in https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#SFRotationInstanceCreationFunction effectively makes (0 1 0 0) the default value if no parameters are provided. The inconsistency does not have much of an impact since both are 0 rotations but I believe (0 1 0 0) - a 0 rotation around y - may have been intended as the default. -Andreas -- Andreas Plesch Waltham, MA 02453 -- Andreas Plesch Waltham, MA 02453 -- Andreas Plesch Waltham, MA 02453 _______________________________________________ x3d-public mailing list x3d-public at web3d.org (mailto:x3d-public at web3d.org) http://web3d.org/mailman/listinfo/x3d-public_web3d.org -- Andreas Plesch Waltham, MA 02453 -- Andreas Plesch Waltham, MA 02453 -------------- next part -------------- An HTML attachment was scrubbed... URL: From joedwil at earthlink.net Sun Feb 16 09:03:53 2025 From: joedwil at earthlink.net (joedwil at earthlink.net) Date: Sun, 16 Feb 2025 17:03:53 +0000 Subject: [x3d-public] Turning on and off simultaneous animations individually Message-ID: I think that menu needs to be made as a HUD (see jin animations menu) so the menu stays in view when navigating, even just bringing the face closer. For that, ProximitySensor needs to work. x3dom? Thanks, Joe -----Original Message----- From: John Carlson Sent: Feb 15, 2025 7:47 PM To: Cc: Andreas Plesch , X3D Graphics public mailing list Subject: Re: Turning on and off simultaneous animations individually Yes, at the bottom of the emotions menu. John On Sat, Feb 15, 2025 at 9:02?PM wrote: This is great step. Is there a stop, reset all anims button? Thanks, Joe -----Original Message----- From: Andreas Plesch Sent: Feb 15, 2025 1:25 PM To: X3D Graphics public mailing list Cc: Joe D Williams , John Carlson Subject: Re: Turning on and off simultaneous animations individually Hi, the x3dom editor now uses an experimental version with much improved performance for HAnimDisplacers: https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d This experimental x3dom version is available at https://andreasplesch.github.io/x3dom/dist/ Feel free to use and test it. Some tests are available at https://andreasplesch.github.io/x3dom/test/ Have fun, -Andreas On Wed, Feb 12, 2025 at 11:27?AM Andreas Plesch wrote: Hi, I took a first stab at Displacers in Segments for x3dom and use it now in the editor: https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/ManyClocks.x3d This is experimental and mostly for testing purposes. If there is an example combining Displacers in both Joints and Segments that would be interesting as it is not necessarily expected to work. The experimental implementation is inefficient and expensive as it is weight_changed event driven. If you activate multiple displacers the frame rate starts to drop. It probably is not very useful at this point. Fee free to give it a try, -Andreas On Wed, Feb 5, 2025, 4:11?PM Andreas Plesch wrote: Hi John, Thanks. I found the tongue.x3d example but if you can create another one that would be helpful in general. You vastly overestimate my ability and availability ;) This would be a longer term project. I have an idea what to do. Andreas On Wed, Feb 5, 2025, 1:31?PM John Carlson wrote: I had one I sent to Holger, probably derived from this one: https://github.com/coderextreme/ci2had/blob/main/resources/JinMouthStretch.x3d What I would do (again) is take out all the segments but the tongue. There’s no menus involved in this one. If you need further assistance, like a smaller example, I can help. Also all the Jin*.x3d FACS action units can also provide examples. I’ll be pretty unbusy today. I can allocate some time for creating a model, make sure it animates, etc. If you’re able to allocate some time today, great, we have an HAnim meeting tomorrow and showing off X3DOM editor using Displacers would be fantastic! Remember there’s a coord field in HAnimSegment that the HAnimDisplacer operates on! John On Wed, Feb 5, 2025 at 12:01?PM Andreas Plesch wrote: Hi John, The reason is that Displacers are currently implemented in x3dom only for Joints, but not for Segments, unfortunately. Do you know of a simple but instructive test case of Segments with Displacers ? Andreas On Tue, Feb 4, 2025, 2:33?PM John Carlson wrote: I will try to test this in castle model converter. I did try setting a value for the outputOnly fields, but the converter wouldn’t shut up. The model below doesn’t seem to animate when one presses the menu items. Did you get it to animate? On Tue, Feb 4, 2025 at 12:27?PM Andreas Plesch wrote: Hi John, all, It turns out that x3dom currently expects a default value for Proto fields even for outputOnly fields. This is due to how Proto fields are initialized. They always need to have a value. While the spec. does not require this, it seems still good practice to always define a default value in the ProtoInterface. There may be a case where an outputOnly field is used in ISing where a valid value would be expected. There may be other corner cases. Here is your example with added default values for outputOnly fields: https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/af5ff3148c1159f71d34fb78c1f63024/raw/b3d4470107ab74e301ed48448ab2a4f4154672e0/ManyClocks_John.x3d This could be fixed in x3dom, by always setting some default value. Is there a list of recommended defaults for each data type if no other source of defaults is available? For SFTime it seems to be -1. -Andreas On Mon, Feb 3, 2025 at 7:39?AM Andreas Plesch wrote: Hi John, On Mon, Feb 3, 2025 at 12:48?AM John Carlson wrote: Andreas, "startTime" is an accessType outputOnly field, so why do I need to provide a value attribute in fieldValue? I'm kind of confused. I'm probably missing something in the spec. You are right, I only outlined scenarios where the accessType allows input or initialization.. In the outputOnly case it is not necessary to provide a fieldValue node at all since there is no value which can be provided. Providing the node would indeed be confusing, to both the user code reader and any X3D browser. I believe the spec. is silent on this case in any encoding. Best, Andreas Thanks for any clarification. I have finally enabled schematron on the project, but I'm finding it hard to understand the messages, and modifications that I make, while removing the immediate problems, seem to move the problems elsewhere. Explaining why I need a "startTime" fieldValue value is my main lack of understanding, but perhaps I need a whole review of accessType. Castle Model Converter reports: castle-model-converter: Warning: X3D: X3D XML: element references unknown field name "enabled" castle-model-converter: Warning: X3D: X3D XML: element references unknown field name "startTime" castle-model-converter: Warning: X3D: X3D XML: element references unknown field name "stopTime" I will try providing a field value in the ProtoInterface If I "cleanup" enabled, startTime and stopTime, I get: castle-model-converter: Warning: VRML/X3D: Within prototype "MenuItem", event "inputTrue" references (by "IS" clause) non-existing event "enabled" castle-model-converter: Warning: VRML/X3D: Within prototype "MenuItem", event "triggerTime" references (by "IS" clause) non-existing event "startTime" castle-model-converter: Warning: VRML/X3D: Within prototype "MenuItem", event "triggerTime" references (by "IS" clause) non-existing event "stopTime" I guess what I conclude at this point is, startTime and stopTime are bad DEF names, but what about enabled as a field? The dominoes are falling. About your two scenarios in the other message, perhaps this is revealing. See attached attempt to fix original issue, which resulted in the above. John On Sun, Feb 2, 2025 at 3:59?PM Andreas Plesch wrote: I think x3dom, reasonably, expects a value for the fieldValue nodes: For example: and others. On Sun, Feb 2, 2025 at 5:42?AM John Carlson wrote: Andreas, Joe, Reset Button, Reset_Clock added. See attached zip for details, or visit link; https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d For some reason, this link doesn't show the live scene? https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d Puzzled, haven't researched it yet. Looks good in Sunrize and X_ITE, will try FreeWRL next. John -- Andreas Plesch Waltham, MA 02453 -- Andreas Plesch Waltham, MA 02453 -- Andreas Plesch Waltham, MA 02453 -- Andreas Plesch Waltham, MA 02453 -------------- next part -------------- An HTML attachment was scrubbed... URL: From joedwil at earthlink.net Sun Feb 16 09:09:31 2025 From: joedwil at earthlink.net (joedwil at earthlink.net) Date: Sun, 16 Feb 2025 17:09:31 +0000 Subject: [x3d-public] SFRotation default value spec. inconsistency Message-ID: > I would vote for 0 1 0 0 since rotations around Y seem more common First,oldest use is in Part 1, way back to origin of VRML standard. Is Yaw really more popular or common than Pitch or Roll? For me, Please let's stick with oldest history and update more recent. Thanks Joe -----Original Message----- From: Andreas Plesch Sent: Feb 15, 2025 9:12 PM To: Cc: Holger Seelig , X3D Subject: Re: [x3d-public] SFRotation default value spec. inconsistency I agree, probably the best default value for a unit quaternion is 0 0 0 1. However, X3D does not concern itself with quaternions, only axis-angle rotations. So the original question remains: Part 1 has axis-angle 0 0 1 0 as default while the JS SAI spec. has 0 1 0 0. Should both list the same default value ? If yes, which one ? I would vote for 0 1 0 0 since rotations around Y seem more common. -Andreas On Sat, Feb 15, 2025 at 11:04?PM wrote: Doesn't this mean that the _best_ default value, for no rotation, is 'legally' for unit quaternion = 0 0 0 1 because the square root of the sum of the squares of all four components does = 1 ? 0 0 0 0 would not be a legal unit quaternion. While the axis-angle default is 0 0 1 0 as appears in Part 1 is mostly for convenience since many value combinations can produce zero rotation? Also sure shows why axis-angle is so much easier to work with when typing numbers, pitch and yaw and roll for all. Thanks, Joe -----Original Message----- From: Andreas Plesch Sent: Feb 14, 2025 11:36 AM To: Holger Seelig Cc: X3D , Joseph D Williams Subject: Re: [x3d-public] SFRotation default value spec. inconsistency Let me just add for clarity that the length (or norm) of a quaternion includes the fourth, the scalar component. The norm is the square root of the sum of the squares of all four components. Only unit quaternions represent rotations. A (0,0,0,0) quaternion does not represent any rotation (but of course exists outside of rotations). Andreas PS: To add back in some fuzziness, a unit quaternion can only represent a rotation up to 360 degrees. I think there is a mechanism to use non-unit quaternions for larger rotations. On Fri, Feb 14, 2025 at 10:22?AM Holger Seelig wrote: All quaternions must be normalized to be a legal rotation, so the length of the quaternion must always be one. Holger-- Holger Seelig Leipzig, Germany holger.seelig at yahoo.de (mailto:holger.seelig at yahoo.de) https://create3000.github.io/x_ite/ Am 14.02.2025 um 15:38 schrieb Joe D Williams via x3d-public : > So, sensibly, a zero rotation around any axis corresponds to the "zero unit Quaternion" (0, 0, 0, 1 XYZW), Right. Not sure but 0 0 0 0 for unit quaternion might not be legal. I think the values must compute to1 to be legal? Thanks, Joe -----Original Message----- From: Andreas Plesch Sent: Feb 10, 2025 12:37 PM To: Joe D Williams Cc: Extensible 3D (X3D) Graphics public discussion Subject: Re: [x3d-public] SFRotation default value spec. inconsistency https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#_node_rotation has indeed (0, 0, 0, 1 XYZW) as a default value. This is difficult to interpret as a rotation around an axis since the corresponding axis would be at first glance (0 0 0). x3dom converts quaternion (0, 0, 0, 1 XYZW) to (axis),angle (0,0,0),0 as does https://www.andre-gaschler.com/rotationconverter/ . On the other hand both SFRotation (0 0 1 0) and SFRotation (0 1 0 0) are also represented by quaternion (0, 0, 0, 1 XYZW). So, sensibly, a zero rotation around any axis corresponds to the "zero unit Quaternion" (0, 0, 0, 1 XYZW), making it a useful default value for quaternions. But that does not help with choosing a default axis for the SFRotation value. This will rarely matter. A use case may be when a SFRotation is initialized to the X3D default in a Proto but then only the angle is modified by a Proto script with the assumption that the axis is (0 0 1). -Andreas On Mon, Feb 10, 2025 at 12:57?PM Joe D Williams wrote: not zerp, zero -----Original Message----- From: Extensible 3D (X3D) Graphics public discussion Sent: Feb 10, 2025 9:50 AM To: Extensible 3D (X3D) Graphics public discussion , X3D Graphics public mailing list Cc: Joe D Williams , Andreas Plesch Subject: Re: [x3d-public] SFRotation default value spec. inconsistency I think the 0 0 1 0 should be used everywhere for default axis-angle. I thinkI see 'zerp' unit quaternions (as in gltf as 0 0 0 1 XYZW) Thanks, Joe -----Original Message----- From: Extensible 3D (X3D) Graphics public discussion Sent: Feb 10, 2025 8:44 AM To: X3D Graphics public mailing list Cc: Andreas Plesch Subject: Re: [x3d-public] SFRotation default value spec. inconsistency The JS SAI spec. at https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#FieldServices does not list functions for SFColorRGBA, only SFColor. There may be an earlier report. -Andreas On Mon, Feb 10, 2025 at 11:31?AM Andreas Plesch wrote: https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/fieldTypes.html#SFRotationAndMFRotation specifies that (0 0 1 0) is the value of an uninitialized SFRotation given as (x y z a). However, the JS SAI spec. in table 7.18 in https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#SFRotationInstanceCreationFunction effectively makes (0 1 0 0) the default value if no parameters are provided. The inconsistency does not have much of an impact since both are 0 rotations but I believe (0 1 0 0) - a 0 rotation around y - may have been intended as the default. -Andreas -- Andreas Plesch Waltham, MA 02453 -- Andreas Plesch Waltham, MA 02453 -- Andreas Plesch Waltham, MA 02453 _______________________________________________ x3d-public mailing list x3d-public at web3d.org (mailto:x3d-public at web3d.org) http://web3d.org/mailman/listinfo/x3d-public_web3d.org -- Andreas Plesch Waltham, MA 02453 -- Andreas Plesch Waltham, MA 02453 -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger.seelig at yahoo.de Sun Feb 16 09:21:09 2025 From: holger.seelig at yahoo.de (Holger Seelig) Date: Sun, 16 Feb 2025 18:21:09 +0100 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Sun Feb 16 17:20:16 2025 From: yottzumm at gmail.com (John Carlson) Date: Sun, 16 Feb 2025 19:20:16 -0600 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: Message-ID: Yes, I will try. On Sun, Feb 16, 2025 at 11:04?AM wrote: > I think that menu needs to be made as a HUD (see jin animations menu) so > the menu stays in view when navigating, even just bringing the face closer. > > For that, ProximitySensor needs to work. x3dom? > > Thanks, > > Joe > > > > -----Original Message----- > From: John Carlson > Sent: Feb 15, 2025 7:47 PM > To: > Cc: Andreas Plesch , X3D Graphics public mailing > list > Subject: Re: Turning on and off simultaneous animations individually > > > Yes, at the bottom of the emotions menu. > > John > > On Sat, Feb 15, 2025 at 9:02?PM wrote: > >> This is great step. Is there a stop, reset all anims button? >> >> Thanks, >> >> Joe >> >> >> >> -----Original Message----- >> From: Andreas Plesch >> Sent: Feb 15, 2025 1:25 PM >> To: X3D Graphics public mailing list >> Cc: Joe D Williams , John Carlson < >> yottzumm at gmail.com> >> Subject: Re: Turning on and off simultaneous animations individually >> >> >> Hi, >> >> the x3dom editor now uses an experimental version with much improved >> performance for HAnimDisplacers: >> >> >> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >> >> This experimental x3dom version is available at >> >> https://andreasplesch.github.io/x3dom/dist/ >> >> Feel free to use and test it. Some tests are available at >> >> https://andreasplesch.github.io/x3dom/test/ >> >> Have fun, -Andreas >> >> On Wed, Feb 12, 2025 at 11:27?AM Andreas Plesch >> wrote: >> >>> Hi, >>> >>> I took a first stab at Displacers in Segments for x3dom and use it now >>> in the editor: >>> >>> >>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/ManyClocks.x3d >>> >>> This is experimental and mostly for testing purposes. If there is an >>> example combining Displacers in both Joints and Segments that would be >>> interesting as it is not necessarily expected to work. >>> The experimental implementation is inefficient and expensive as it is >>> weight_changed event driven. If you activate multiple displacers the frame >>> rate starts to drop. It probably is not very useful at this point. >>> >>> Fee free to give it a try, -Andreas >>> >>> On Wed, Feb 5, 2025, 4:11?PM Andreas Plesch >>> wrote: >>> >>>> Hi John, >>>> >>>> Thanks. I found the tongue.x3d example but if you can create another >>>> one that would be helpful in general. >>>> >>>> You vastly overestimate my ability and availability ;) This would be a >>>> longer term project. I have an idea what to do. >>>> >>>> Andreas >>>> >>>> >>>> On Wed, Feb 5, 2025, 1:31?PM John Carlson wrote: >>>> >>>>> I had one I sent to Holger, probably derived from this one: >>>>> >>>>> >>>>> https://github.com/coderextreme/ci2had/blob/main/resources/JinMouthStretch.x3d >>>>> >>>>> >>>>> What I would do (again) is take out all the segments but the tongue. >>>>> >>>>> There?s no menus involved in this one. >>>>> >>>>> If you need further assistance, like a smaller example, I can help. >>>>> Also all the Jin*.x3d FACS action units can also provide examples. >>>>> >>>>> I?ll be pretty unbusy today. I can allocate some time for creating a >>>>> model, make sure it animates, etc. >>>>> >>>>> If you?re able to allocate some time today, great, we have an HAnim >>>>> meeting tomorrow and showing off X3DOM editor using Displacers would be >>>>> fantastic! >>>>> >>>>> Remember there?s a coord field in HAnimSegment that the HAnimDisplacer >>>>> operates on! >>>>> >>>>> John >>>>> >>>>> On Wed, Feb 5, 2025 at 12:01?PM Andreas Plesch < >>>>> andreasplesch at gmail.com> wrote: >>>>> >>>>>> Hi John, >>>>>> >>>>>> The reason is that Displacers are currently implemented in x3dom only >>>>>> for Joints, but not for Segments, unfortunately. Do you know of a simple >>>>>> but instructive test case of Segments with Displacers ? >>>>>> >>>>>> >>>>>> Andreas >>>>>> >>>>>> >>>>>> On Tue, Feb 4, 2025, 2:33?PM John Carlson wrote: >>>>>> >>>>>>> I will try to test this in castle model converter. >>>>>>> >>>>>>> I did try setting a value for the outputOnly fields, but the >>>>>>> converter wouldn?t shut up. >>>>>>> >>>>>>> The model below doesn?t seem to animate when one presses the menu >>>>>>> items. Did you get it to animate? >>>>>>> >>>>>>> On Tue, Feb 4, 2025 at 12:27?PM Andreas Plesch < >>>>>>> andreasplesch at gmail.com> wrote: >>>>>>> >>>>>>>> Hi John, all, >>>>>>>> >>>>>>>> It turns out that x3dom currently expects a default value for Proto >>>>>>>> fields even for outputOnly fields. This is due to how Proto fields are >>>>>>>> initialized. They always need to have a value. While the spec. does not >>>>>>>> require this, it seems still good practice to always define a default value >>>>>>>> in the ProtoInterface. There may be a case where an outputOnly field is >>>>>>>> used in ISing where a valid value would be expected. There may be other >>>>>>>> corner cases. >>>>>>>> >>>>>>>> Here is your example with added default values for outputOnly >>>>>>>> fields: >>>>>>>> >>>>>>>> >>>>>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/af5ff3148c1159f71d34fb78c1f63024/raw/b3d4470107ab74e301ed48448ab2a4f4154672e0/ManyClocks_John.x3d >>>>>>>> >>>>>>>> This could be fixed in x3dom, by always setting some default value. >>>>>>>> Is there a list of recommended defaults for each data type if no other >>>>>>>> source of defaults is available? For SFTime it seems to be -1. >>>>>>>> >>>>>>>> >>>>>>>> -Andreas >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Feb 3, 2025 at 7:39?AM Andreas Plesch < >>>>>>>> andreasplesch at gmail.com> wrote: >>>>>>>> >>>>>>>>> Hi John, >>>>>>>>> >>>>>>>>> On Mon, Feb 3, 2025 at 12:48?AM John Carlson >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Andreas, "startTime" is an accessType outputOnly field, so why do >>>>>>>>>> I need to provide a value attribute in fieldValue? I'm kind of confused. >>>>>>>>>> I'm probably missing something in the spec. >>>>>>>>>> >>>>>>>>> >>>>>>>>> You are right, I only outlined scenarios where the accessType >>>>>>>>> allows input or initialization.. >>>>>>>>> In the outputOnly case it is not necessary to provide a fieldValue >>>>>>>>> node at all since there is no value which can be provided. Providing the >>>>>>>>> node would indeed be confusing, to both the user code reader and any X3D >>>>>>>>> browser. >>>>>>>>> I believe the spec. is silent on this case in any encoding. >>>>>>>>> >>>>>>>>> Best, Andreas >>>>>>>>> >>>>>>>>> >>>>>>>>>> Thanks for any clarification. >>>>>>>>>> >>>>>>>>>> I have finally enabled schematron on the project, but I'm finding >>>>>>>>>> it hard to understand the messages, and modifications that I make, while >>>>>>>>>> removing the immediate problems, seem to move the problems elsewhere. >>>>>>>>>> >>>>>>>>>> Explaining why I need a "startTime" fieldValue value is my main >>>>>>>>>> lack of understanding, but perhaps I need a whole review of accessType. >>>>>>>>>> >>>>>>>>>> Castle Model Converter reports: >>>>>>>>>> >>>>>>>>>> castle-model-converter: Warning: X3D: X3D XML: >>>>>>>>>> element references unknown field name "enabled" >>>>>>>>>> castle-model-converter: Warning: X3D: X3D XML: >>>>>>>>>> element references unknown field name "startTime" >>>>>>>>>> castle-model-converter: Warning: X3D: X3D XML: >>>>>>>>>> element references unknown field name "stopTime" >>>>>>>>>> >>>>>>>>>> I will try providing a field value in the ProtoInterface >>>>>>>>>> >>>>>>>>>> If I "cleanup" enabled, startTime and stopTime, I get: >>>>>>>>>> >>>>>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>>>>>> "MenuItem", event "inputTrue" references (by "IS" clause) non-existing >>>>>>>>>> event "enabled" >>>>>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) non-existing >>>>>>>>>> event "startTime" >>>>>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) non-existing >>>>>>>>>> event "stopTime" >>>>>>>>>> >>>>>>>>>> I guess what I conclude at this point is, startTime and stopTime >>>>>>>>>> are bad DEF names, but what about enabled as a field? The dominoes are >>>>>>>>>> falling. >>>>>>>>>> >>>>>>>>>> About your two scenarios in the other message, perhaps this is >>>>>>>>>> revealing. >>>>>>>>>> >>>>>>>>>> See attached attempt to fix original issue, which resulted in the >>>>>>>>>> above. >>>>>>>>>> >>>>>>>>>> John >>>>>>>>>> >>>>>>>>>> On Sun, Feb 2, 2025 at 3:59?PM Andreas Plesch < >>>>>>>>>> andreasplesch at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> I think x3dom, reasonably, expects a value for the fieldValue >>>>>>>>>>> nodes: >>>>>>>>>>> >>>>>>>>>>> For example: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> and others. >>>>>>>>>>> >>>>>>>>>>> On Sun, Feb 2, 2025 at 5:42?AM John Carlson >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Andreas, Joe, >>>>>>>>>>>> >>>>>>>>>>>> Reset Button, Reset_Clock added. >>>>>>>>>>>> >>>>>>>>>>>> See attached zip for details, or visit link; >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>>>>>>>> >>>>>>>>>>>> For some reason, this link doesn't show the live scene? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>>>>>>>> >>>>>>>>>>>> Puzzled, haven't researched it yet. Looks good in Sunrize and >>>>>>>>>>>> X_ITE, will try FreeWRL next. >>>>>>>>>>>> >>>>>>>>>>>> John >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Andreas Plesch >>>>>>>>>>> Waltham, MA 02453 >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Andreas Plesch >>>>>>>>> Waltham, MA 02453 >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Andreas Plesch >>>>>>>> Waltham, MA 02453 >>>>>>>> >>>>>>> >> >> -- >> Andreas Plesch >> Waltham, MA 02453 >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Sun Feb 16 17:32:57 2025 From: yottzumm at gmail.com (John Carlson) Date: Sun, 16 Feb 2025 19:32:57 -0600 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: Message-ID: JSONverse is an example of Layer/LayerSet, based off of Christoph V.?s tprev.x3d I believe Jin FACS started off as Layer/LayerSet, but I rapidly realized 3D might be easier. I don?t quite understand Layer/LayerSet conceptually. If someone could develop a Layer/LayerSet menu item, perhaps based off the MenuItem proto found in recent versions of FACS/ci2had, that would be terrific. John On Sun, Feb 16, 2025 at 11:23?AM Holger Seelig wrote: > Using Layer and LayerSet for the HUD and the scene would be great. Don?t > known any X3D example with layers. > > Holger > > Am 16.02.2025 um 18:04 schrieb Joe D Williams via x3d-public < > x3d-public at web3d.org>: > > ? > > I think that menu needs to be made as a HUD (see jin animations menu) so > the menu stays in view when navigating, even just bringing the face closer. > > For that, ProximitySensor needs to work. x3dom? > > Thanks, > > Joe > > > > -----Original Message----- > From: John Carlson > Sent: Feb 15, 2025 7:47 PM > To: > Cc: Andreas Plesch , X3D Graphics public mailing > list > Subject: Re: Turning on and off simultaneous animations individually > > > Yes, at the bottom of the emotions menu. > > John > > On Sat, Feb 15, 2025 at 9:02?PM wrote: > >> This is great step. Is there a stop, reset all anims button? >> >> Thanks, >> >> Joe >> >> >> >> -----Original Message----- >> From: Andreas Plesch >> Sent: Feb 15, 2025 1:25 PM >> To: X3D Graphics public mailing list >> Cc: Joe D Williams , John Carlson < >> yottzumm at gmail.com> >> Subject: Re: Turning on and off simultaneous animations individually >> >> >> Hi, >> >> the x3dom editor now uses an experimental version with much improved >> performance for HAnimDisplacers: >> >> >> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >> >> This experimental x3dom version is available at >> >> https://andreasplesch.github.io/x3dom/dist/ >> >> Feel free to use and test it. Some tests are available at >> >> https://andreasplesch.github.io/x3dom/test/ >> >> Have fun, -Andreas >> >> On Wed, Feb 12, 2025 at 11:27?AM Andreas Plesch >> wrote: >> >>> Hi, >>> >>> I took a first stab at Displacers in Segments for x3dom and use it now >>> in the editor: >>> >>> >>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/ManyClocks.x3d >>> >>> This is experimental and mostly for testing purposes. If there is an >>> example combining Displacers in both Joints and Segments that would be >>> interesting as it is not necessarily expected to work. >>> The experimental implementation is inefficient and expensive as it is >>> weight_changed event driven. If you activate multiple displacers the frame >>> rate starts to drop. It probably is not very useful at this point. >>> >>> Fee free to give it a try, -Andreas >>> >>> On Wed, Feb 5, 2025, 4:11?PM Andreas Plesch >>> wrote: >>> >>>> Hi John, >>>> >>>> Thanks. I found the tongue.x3d example but if you can create another >>>> one that would be helpful in general. >>>> >>>> You vastly overestimate my ability and availability ;) This would be a >>>> longer term project. I have an idea what to do. >>>> >>>> Andreas >>>> >>>> >>>> On Wed, Feb 5, 2025, 1:31?PM John Carlson wrote: >>>> >>>>> I had one I sent to Holger, probably derived from this one: >>>>> >>>>> >>>>> https://github.com/coderextreme/ci2had/blob/main/resources/JinMouthStretch.x3d >>>>> >>>>> >>>>> What I would do (again) is take out all the segments but the tongue. >>>>> >>>>> There?s no menus involved in this one. >>>>> >>>>> If you need further assistance, like a smaller example, I can help. >>>>> Also all the Jin*.x3d FACS action units can also provide examples. >>>>> >>>>> I?ll be pretty unbusy today. I can allocate some time for creating a >>>>> model, make sure it animates, etc. >>>>> >>>>> If you?re able to allocate some time today, great, we have an HAnim >>>>> meeting tomorrow and showing off X3DOM editor using Displacers would be >>>>> fantastic! >>>>> >>>>> Remember there?s a coord field in HAnimSegment that the HAnimDisplacer >>>>> operates on! >>>>> >>>>> John >>>>> >>>>> On Wed, Feb 5, 2025 at 12:01?PM Andreas Plesch < >>>>> andreasplesch at gmail.com> wrote: >>>>> >>>>>> Hi John, >>>>>> >>>>>> The reason is that Displacers are currently implemented in x3dom only >>>>>> for Joints, but not for Segments, unfortunately. Do you know of a simple >>>>>> but instructive test case of Segments with Displacers ? >>>>>> >>>>>> >>>>>> Andreas >>>>>> >>>>>> >>>>>> On Tue, Feb 4, 2025, 2:33?PM John Carlson wrote: >>>>>> >>>>>>> I will try to test this in castle model converter. >>>>>>> >>>>>>> I did try setting a value for the outputOnly fields, but the >>>>>>> converter wouldn?t shut up. >>>>>>> >>>>>>> The model below doesn?t seem to animate when one presses the menu >>>>>>> items. Did you get it to animate? >>>>>>> >>>>>>> On Tue, Feb 4, 2025 at 12:27?PM Andreas Plesch < >>>>>>> andreasplesch at gmail.com> wrote: >>>>>>> >>>>>>>> Hi John, all, >>>>>>>> >>>>>>>> It turns out that x3dom currently expects a default value for Proto >>>>>>>> fields even for outputOnly fields. This is due to how Proto fields are >>>>>>>> initialized. They always need to have a value. While the spec. does not >>>>>>>> require this, it seems still good practice to always define a default value >>>>>>>> in the ProtoInterface. There may be a case where an outputOnly field is >>>>>>>> used in ISing where a valid value would be expected. There may be other >>>>>>>> corner cases. >>>>>>>> >>>>>>>> Here is your example with added default values for outputOnly >>>>>>>> fields: >>>>>>>> >>>>>>>> >>>>>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/af5ff3148c1159f71d34fb78c1f63024/raw/b3d4470107ab74e301ed48448ab2a4f4154672e0/ManyClocks_John.x3d >>>>>>>> >>>>>>>> This could be fixed in x3dom, by always setting some default value. >>>>>>>> Is there a list of recommended defaults for each data type if no other >>>>>>>> source of defaults is available? For SFTime it seems to be -1. >>>>>>>> >>>>>>>> >>>>>>>> -Andreas >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Feb 3, 2025 at 7:39?AM Andreas Plesch < >>>>>>>> andreasplesch at gmail.com> wrote: >>>>>>>> >>>>>>>>> Hi John, >>>>>>>>> >>>>>>>>> On Mon, Feb 3, 2025 at 12:48?AM John Carlson >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Andreas, "startTime" is an accessType outputOnly field, so why do >>>>>>>>>> I need to provide a value attribute in fieldValue? I'm kind of confused. >>>>>>>>>> I'm probably missing something in the spec. >>>>>>>>>> >>>>>>>>> >>>>>>>>> You are right, I only outlined scenarios where the accessType >>>>>>>>> allows input or initialization.. >>>>>>>>> In the outputOnly case it is not necessary to provide a fieldValue >>>>>>>>> node at all since there is no value which can be provided. Providing the >>>>>>>>> node would indeed be confusing, to both the user code reader and any X3D >>>>>>>>> browser. >>>>>>>>> I believe the spec. is silent on this case in any encoding. >>>>>>>>> >>>>>>>>> Best, Andreas >>>>>>>>> >>>>>>>>> >>>>>>>>>> Thanks for any clarification. >>>>>>>>>> >>>>>>>>>> I have finally enabled schematron on the project, but I'm finding >>>>>>>>>> it hard to understand the messages, and modifications that I make, while >>>>>>>>>> removing the immediate problems, seem to move the problems elsewhere. >>>>>>>>>> >>>>>>>>>> Explaining why I need a "startTime" fieldValue value is my main >>>>>>>>>> lack of understanding, but perhaps I need a whole review of accessType. >>>>>>>>>> >>>>>>>>>> Castle Model Converter reports: >>>>>>>>>> >>>>>>>>>> castle-model-converter: Warning: X3D: X3D XML: >>>>>>>>>> element references unknown field name "enabled" >>>>>>>>>> castle-model-converter: Warning: X3D: X3D XML: >>>>>>>>>> element references unknown field name "startTime" >>>>>>>>>> castle-model-converter: Warning: X3D: X3D XML: >>>>>>>>>> element references unknown field name "stopTime" >>>>>>>>>> >>>>>>>>>> I will try providing a field value in the ProtoInterface >>>>>>>>>> >>>>>>>>>> If I "cleanup" enabled, startTime and stopTime, I get: >>>>>>>>>> >>>>>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>>>>>> "MenuItem", event "inputTrue" references (by "IS" clause) non-existing >>>>>>>>>> event "enabled" >>>>>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) non-existing >>>>>>>>>> event "startTime" >>>>>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) non-existing >>>>>>>>>> event "stopTime" >>>>>>>>>> >>>>>>>>>> I guess what I conclude at this point is, startTime and stopTime >>>>>>>>>> are bad DEF names, but what about enabled as a field? The dominoes are >>>>>>>>>> falling. >>>>>>>>>> >>>>>>>>>> About your two scenarios in the other message, perhaps this is >>>>>>>>>> revealing. >>>>>>>>>> >>>>>>>>>> See attached attempt to fix original issue, which resulted in the >>>>>>>>>> above. >>>>>>>>>> >>>>>>>>>> John >>>>>>>>>> >>>>>>>>>> On Sun, Feb 2, 2025 at 3:59?PM Andreas Plesch < >>>>>>>>>> andreasplesch at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> I think x3dom, reasonably, expects a value for the fieldValue >>>>>>>>>>> nodes: >>>>>>>>>>> >>>>>>>>>>> For example: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> and others. >>>>>>>>>>> >>>>>>>>>>> On Sun, Feb 2, 2025 at 5:42?AM John Carlson >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Andreas, Joe, >>>>>>>>>>>> >>>>>>>>>>>> Reset Button, Reset_Clock added. >>>>>>>>>>>> >>>>>>>>>>>> See attached zip for details, or visit link; >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>>>>>>>> >>>>>>>>>>>> For some reason, this link doesn't show the live scene? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>>>>>>>> >>>>>>>>>>>> Puzzled, haven't researched it yet. Looks good in Sunrize and >>>>>>>>>>>> X_ITE, will try FreeWRL next. >>>>>>>>>>>> >>>>>>>>>>>> John >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Andreas Plesch >>>>>>>>>>> Waltham, MA 02453 >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Andreas Plesch >>>>>>>>> Waltham, MA 02453 >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Andreas Plesch >>>>>>>> Waltham, MA 02453 >>>>>>>> >>>>>>> >> >> -- >> Andreas Plesch >> Waltham, MA 02453 >> >> >> > > > _______________________________________________ > > > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gpugroup at gmail.com Sun Feb 16 17:49:02 2025 From: gpugroup at gmail.com (GPU Group) Date: Sun, 16 Feb 2025 18:49:02 -0700 Subject: [x3d-public] Turning on and off simultaneous animations individually In-Reply-To: References: Message-ID: " Don?t known any X3D example with layers." https://freewrl.sourceforge.io/tests/35_Layering/ might be something relevant in here, swirl_layer.x3d looks interesting, has a little HUD, I think it came from an old browser (Swirl?) -Doug On Sun, Feb 16, 2025 at 10:24?AM Holger Seelig via x3d-public < x3d-public at web3d.org> wrote: > Using Layer and LayerSet for the HUD and the scene would be great. Don?t > known any X3D example with layers. > > Holger > > Am 16.02.2025 um 18:04 schrieb Joe D Williams via x3d-public < > x3d-public at web3d.org>: > > ? > > I think that menu needs to be made as a HUD (see jin animations menu) so > the menu stays in view when navigating, even just bringing the face closer. > > For that, ProximitySensor needs to work. x3dom? > > Thanks, > > Joe > > > > -----Original Message----- > From: John Carlson > Sent: Feb 15, 2025 7:47 PM > To: > Cc: Andreas Plesch , X3D Graphics public mailing > list > Subject: Re: Turning on and off simultaneous animations individually > > > Yes, at the bottom of the emotions menu. > > John > > On Sat, Feb 15, 2025 at 9:02?PM wrote: > >> This is great step. Is there a stop, reset all anims button? >> >> Thanks, >> >> Joe >> >> >> >> -----Original Message----- >> From: Andreas Plesch >> Sent: Feb 15, 2025 1:25 PM >> To: X3D Graphics public mailing list >> Cc: Joe D Williams , John Carlson < >> yottzumm at gmail.com> >> Subject: Re: Turning on and off simultaneous animations individually >> >> >> Hi, >> >> the x3dom editor now uses an experimental version with much improved >> performance for HAnimDisplacers: >> >> >> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >> >> This experimental x3dom version is available at >> >> https://andreasplesch.github.io/x3dom/dist/ >> >> Feel free to use and test it. Some tests are available at >> >> https://andreasplesch.github.io/x3dom/test/ >> >> Have fun, -Andreas >> >> On Wed, Feb 12, 2025 at 11:27?AM Andreas Plesch >> wrote: >> >>> Hi, >>> >>> I took a first stab at Displacers in Segments for x3dom and use it now >>> in the editor: >>> >>> >>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/ManyClocks.x3d >>> >>> This is experimental and mostly for testing purposes. If there is an >>> example combining Displacers in both Joints and Segments that would be >>> interesting as it is not necessarily expected to work. >>> The experimental implementation is inefficient and expensive as it is >>> weight_changed event driven. If you activate multiple displacers the frame >>> rate starts to drop. It probably is not very useful at this point. >>> >>> Fee free to give it a try, -Andreas >>> >>> On Wed, Feb 5, 2025, 4:11?PM Andreas Plesch >>> wrote: >>> >>>> Hi John, >>>> >>>> Thanks. I found the tongue.x3d example but if you can create another >>>> one that would be helpful in general. >>>> >>>> You vastly overestimate my ability and availability ;) This would be a >>>> longer term project. I have an idea what to do. >>>> >>>> Andreas >>>> >>>> >>>> On Wed, Feb 5, 2025, 1:31?PM John Carlson wrote: >>>> >>>>> I had one I sent to Holger, probably derived from this one: >>>>> >>>>> >>>>> https://github.com/coderextreme/ci2had/blob/main/resources/JinMouthStretch.x3d >>>>> >>>>> >>>>> What I would do (again) is take out all the segments but the tongue. >>>>> >>>>> There?s no menus involved in this one. >>>>> >>>>> If you need further assistance, like a smaller example, I can help. >>>>> Also all the Jin*.x3d FACS action units can also provide examples. >>>>> >>>>> I?ll be pretty unbusy today. I can allocate some time for creating a >>>>> model, make sure it animates, etc. >>>>> >>>>> If you?re able to allocate some time today, great, we have an HAnim >>>>> meeting tomorrow and showing off X3DOM editor using Displacers would be >>>>> fantastic! >>>>> >>>>> Remember there?s a coord field in HAnimSegment that the HAnimDisplacer >>>>> operates on! >>>>> >>>>> John >>>>> >>>>> On Wed, Feb 5, 2025 at 12:01?PM Andreas Plesch < >>>>> andreasplesch at gmail.com> wrote: >>>>> >>>>>> Hi John, >>>>>> >>>>>> The reason is that Displacers are currently implemented in x3dom only >>>>>> for Joints, but not for Segments, unfortunately. Do you know of a simple >>>>>> but instructive test case of Segments with Displacers ? >>>>>> >>>>>> >>>>>> Andreas >>>>>> >>>>>> >>>>>> On Tue, Feb 4, 2025, 2:33?PM John Carlson wrote: >>>>>> >>>>>>> I will try to test this in castle model converter. >>>>>>> >>>>>>> I did try setting a value for the outputOnly fields, but the >>>>>>> converter wouldn?t shut up. >>>>>>> >>>>>>> The model below doesn?t seem to animate when one presses the menu >>>>>>> items. Did you get it to animate? >>>>>>> >>>>>>> On Tue, Feb 4, 2025 at 12:27?PM Andreas Plesch < >>>>>>> andreasplesch at gmail.com> wrote: >>>>>>> >>>>>>>> Hi John, all, >>>>>>>> >>>>>>>> It turns out that x3dom currently expects a default value for Proto >>>>>>>> fields even for outputOnly fields. This is due to how Proto fields are >>>>>>>> initialized. They always need to have a value. While the spec. does not >>>>>>>> require this, it seems still good practice to always define a default value >>>>>>>> in the ProtoInterface. There may be a case where an outputOnly field is >>>>>>>> used in ISing where a valid value would be expected. There may be other >>>>>>>> corner cases. >>>>>>>> >>>>>>>> Here is your example with added default values for outputOnly >>>>>>>> fields: >>>>>>>> >>>>>>>> >>>>>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/af5ff3148c1159f71d34fb78c1f63024/raw/b3d4470107ab74e301ed48448ab2a4f4154672e0/ManyClocks_John.x3d >>>>>>>> >>>>>>>> This could be fixed in x3dom, by always setting some default value. >>>>>>>> Is there a list of recommended defaults for each data type if no other >>>>>>>> source of defaults is available? For SFTime it seems to be -1. >>>>>>>> >>>>>>>> >>>>>>>> -Andreas >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Feb 3, 2025 at 7:39?AM Andreas Plesch < >>>>>>>> andreasplesch at gmail.com> wrote: >>>>>>>> >>>>>>>>> Hi John, >>>>>>>>> >>>>>>>>> On Mon, Feb 3, 2025 at 12:48?AM John Carlson >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Andreas, "startTime" is an accessType outputOnly field, so why do >>>>>>>>>> I need to provide a value attribute in fieldValue? I'm kind of confused. >>>>>>>>>> I'm probably missing something in the spec. >>>>>>>>>> >>>>>>>>> >>>>>>>>> You are right, I only outlined scenarios where the accessType >>>>>>>>> allows input or initialization.. >>>>>>>>> In the outputOnly case it is not necessary to provide a fieldValue >>>>>>>>> node at all since there is no value which can be provided. Providing the >>>>>>>>> node would indeed be confusing, to both the user code reader and any X3D >>>>>>>>> browser. >>>>>>>>> I believe the spec. is silent on this case in any encoding. >>>>>>>>> >>>>>>>>> Best, Andreas >>>>>>>>> >>>>>>>>> >>>>>>>>>> Thanks for any clarification. >>>>>>>>>> >>>>>>>>>> I have finally enabled schematron on the project, but I'm finding >>>>>>>>>> it hard to understand the messages, and modifications that I make, while >>>>>>>>>> removing the immediate problems, seem to move the problems elsewhere. >>>>>>>>>> >>>>>>>>>> Explaining why I need a "startTime" fieldValue value is my main >>>>>>>>>> lack of understanding, but perhaps I need a whole review of accessType. >>>>>>>>>> >>>>>>>>>> Castle Model Converter reports: >>>>>>>>>> >>>>>>>>>> castle-model-converter: Warning: X3D: X3D XML: >>>>>>>>>> element references unknown field name "enabled" >>>>>>>>>> castle-model-converter: Warning: X3D: X3D XML: >>>>>>>>>> element references unknown field name "startTime" >>>>>>>>>> castle-model-converter: Warning: X3D: X3D XML: >>>>>>>>>> element references unknown field name "stopTime" >>>>>>>>>> >>>>>>>>>> I will try providing a field value in the ProtoInterface >>>>>>>>>> >>>>>>>>>> If I "cleanup" enabled, startTime and stopTime, I get: >>>>>>>>>> >>>>>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>>>>>> "MenuItem", event "inputTrue" references (by "IS" clause) non-existing >>>>>>>>>> event "enabled" >>>>>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) non-existing >>>>>>>>>> event "startTime" >>>>>>>>>> castle-model-converter: Warning: VRML/X3D: Within prototype >>>>>>>>>> "MenuItem", event "triggerTime" references (by "IS" clause) non-existing >>>>>>>>>> event "stopTime" >>>>>>>>>> >>>>>>>>>> I guess what I conclude at this point is, startTime and stopTime >>>>>>>>>> are bad DEF names, but what about enabled as a field? The dominoes are >>>>>>>>>> falling. >>>>>>>>>> >>>>>>>>>> About your two scenarios in the other message, perhaps this is >>>>>>>>>> revealing. >>>>>>>>>> >>>>>>>>>> See attached attempt to fix original issue, which resulted in the >>>>>>>>>> above. >>>>>>>>>> >>>>>>>>>> John >>>>>>>>>> >>>>>>>>>> On Sun, Feb 2, 2025 at 3:59?PM Andreas Plesch < >>>>>>>>>> andreasplesch at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> I think x3dom, reasonably, expects a value for the fieldValue >>>>>>>>>>> nodes: >>>>>>>>>>> >>>>>>>>>>> For example: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> and others. >>>>>>>>>>> >>>>>>>>>>> On Sun, Feb 2, 2025 at 5:42?AM John Carlson >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Andreas, Joe, >>>>>>>>>>>> >>>>>>>>>>>> Reset Button, Reset_Clock added. >>>>>>>>>>>> >>>>>>>>>>>> See attached zip for details, or visit link; >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>>>>>>>> >>>>>>>>>>>> For some reason, this link doesn't show the live scene? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d >>>>>>>>>>>> >>>>>>>>>>>> Puzzled, haven't researched it yet. Looks good in Sunrize and >>>>>>>>>>>> X_ITE, will try FreeWRL next. >>>>>>>>>>>> >>>>>>>>>>>> John >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Andreas Plesch >>>>>>>>>>> Waltham, MA 02453 >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Andreas Plesch >>>>>>>>> Waltham, MA 02453 >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Andreas Plesch >>>>>>>> Waltham, MA 02453 >>>>>>>> >>>>>>> >> >> -- >> Andreas Plesch >> Waltham, MA 02453 >> >> >> > > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.valentin at gmx.at Sun Feb 16 18:26:24 2025 From: christoph.valentin at gmx.at (Christoph Valentin) Date: Mon, 17 Feb 2025 02:26:24 +0000 Subject: [x3d-public] =?utf-8?q?Re=3A__Turning_on_and_off_simultaneous_an?= =?utf-8?q?imations_individually?= In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From joedwil at earthlink.net Mon Feb 17 14:34:57 2025 From: joedwil at earthlink.net (joedwil at earthlink.net) Date: Mon, 17 Feb 2025 22:34:57 +0000 Subject: [x3d-public] Fw: [MSF All] Revolutionizing Education and Training with Virtual Worlds and AI Message-ID: The event is open to the public especially any "immersive tech-curious" folks. Joe -----Forwarded Message----- From: Sent: Feb 17, 2025 9:12 AM To: General Subject: [MSF All] Revolutionizing Education and Training with Virtual Worlds and AI General Members (and Everyone), An event has been edited on your workgroup's calendar. Revolutionizing Education and Training with Virtual Worlds and AI (https://portal.metaverse-standards.org/wg/General/calendar/event/542/2025-02-20) Thursday, February 20, 2025 11:00 AM - 12:00 PM EST Hope you will join us on Thursday! Please note everyone needs to register in order to receive the Zoom link: https://metaverse-standards.org/event/revolutionizing-education-and-training-with-virtual-worlds-and-ai/ ~~~ Please join us on February 20th @ 11 AM Eastern US for an exciting event where you'll discover the magic of virtual worlds transforming into interactive labs and explore the future of professional development through immersive AI-powered experiences. Presenters: * Eddie Borbón, STEAM Educator and Digital Artist * Nelly V. Tacheva, Professor at Rutgers University and CEO of Tangra Moderated by Michael Brock, Product Manager and Education Lead at PrecisionOS Learn more and register here (https://metaverse-standards.org/event/revolutionizing-education-and-training-with-virtual-worlds-and-ai/). The event is open to the public. Help us spread the word, please! * Engage and share on social media * Invite coworkers and friends who might be interested in this topic (K-12 & Academia educators, L&D professionals, instruction, immersive tech-curious) We look forward to seeing you there! Best, Nelly V. Tacheva, Tangra Metaverse Educational Register Chair ~~~ This group was formed to inform stakeholders about the current landscape of Metaverse education - best practices, challenges, and emerging trends. Meeting Recordings (https://tools.metaverse-standards.org/documents/apps/files/?dir=/Forum%20Zoom%20Recordings/Educational-Register/Meeting-Recordings/2024&fileid=28418) Meeting Slides (https://portal.metaverse-standards.org/wg/educational_register/document/folder/3084) The General Administration Add to Calendar -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: attachment-1 Type: text/calendar Size: 8157 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: MSF-educational_register-542-Revolutionizing-Educ.ics Type: application/ics Size: 8155 bytes Desc: not available URL: From brutzman at nps.edu Mon Feb 17 21:08:26 2025 From: brutzman at nps.edu (Brutzman, Donald (Don) (CIV)) Date: Tue, 18 Feb 2025 05:08:26 +0000 Subject: [x3d-public] SFRotation default value spec. inconsistency In-Reply-To: References: Message-ID: Thanks for discussion and for noticing the difference. Related references: * 19777-1 X3D ECMAScript language binding, clause 7 Function definitions, 7.6.6 SFRotation * https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#SFRotation * Table 7.18 ? SFRotation instance creation functions * SFRotation (numeric x, numeric y, numeric z, numeric angle) x, y, and z are the axis of the rotation. angle is the angle of the rotation (in radians). Missing values default to 0.0, except y, which defaults to 1.0. * X3D Architecture, clause 5 Field type reference, 5.3.13 SFRotation and MFRotation * https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/fieldTypes.html#SFRotationAndMFRotation * "The default value of an uninitialized SFRotation field is (0 0 1 0). The default value of an MFRotation field is the empty list." Yes they must be the same, so that X3D models are equivalent no matter what file encoding or programming-language binding are used. The X3D Architecture takes precedence. So we will change 19777-1 to match and the highlighted y above will become z. I too think that a default of (0 1 0 0) makes more sense, animation rotations are most often around the vertical (y) axis. However, the community has discussed this many times over the years. We always landed on (0 0 1 0) for backwards-compatibility reasons, not wanting to break legacy X3D and VRML models. Incidentally here is the X3D tooltips entry. Improvements and refinements always welcome. * X3D Tooltips: SFRotation * https://www.web3d.org/x3d/tooltips/X3dTooltips.html#SFRotation * SFRotation Single-Field rotation value using 3-tuple axis, radian angle form Default value 0 0 1 0. Model authors and authoring tools may prefer the equivalent zero-rotation default value 0 1 0 0 since rotation about the vertical Y-axis is most common. Example values: 0 1 0 1.57 Warning: initial 3-tuple axis vector cannot hold a zero-magnitude vector. Warning: comma characters within attribute values are not allowed, and do not pass strict validation. Hint: see Wikipedia: Radian, Rotation matrix and Rotation formalisms in three dimensions. XML Schema, X3D regexes, Java SAI, X3DJ To keep track of this erratum, I have entered a new issue in the Mantis issue tracker. * Mantis 1488: (ECMAScript) 7.6.6 SFRotation default value needs to be (0 0 1 0) * https://mantis.web3d.org/view.php?id=1488 I hope this make sense and sounds good. Have fun with X3D - or else!! ? 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 https://faculty.nps.edu/brutzman ________________________________ From: x3d-public on behalf of Joe D Williams via x3d-public Sent: Sunday, February 16, 2025 9:09 AM To: Andreas Plesch Cc: joedwil at earthlink.net ; X3D Subject: Re: [x3d-public] SFRotation default value spec. inconsistency > I would vote for 0 1 0 0 since rotations around Y seem more common First,oldest use is in Part 1, way back to origin of VRML standard. Is Yaw really more popular or common than Pitch or Roll? For me, Please let's stick with oldest history and update more recent. Thanks Joe -----Original Message----- From: Andreas Plesch Sent: Feb 15, 2025 9:12 PM To: Cc: Holger Seelig , X3D Subject: Re: [x3d-public] SFRotation default value spec. inconsistency I agree, probably the best default value for a unit quaternion is 0 0 0 1. However, X3D does not concern itself with quaternions, only axis-angle rotations. So the original question remains: Part 1 has axis-angle 0 0 1 0 as default while the JS SAI spec. has 0 1 0 0. Should both list the same default value ? If yes, which one ? I would vote for 0 1 0 0 since rotations around Y seem more common. -Andreas On Sat, Feb 15, 2025 at 11:04?PM > wrote: Doesn't this mean that the _best_ default value, for no rotation, is 'legally' for unit quaternion = 0 0 0 1 because the square root of the sum of the squares of all four components does = 1 ? 0 0 0 0 would not be a legal unit quaternion. While the axis-angle default is 0 0 1 0 as appears in Part 1 is mostly for convenience since many value combinations can produce zero rotation? Also sure shows why axis-angle is so much easier to work with when typing numbers, pitch and yaw and roll for all. Thanks, Joe -----Original Message----- From: Andreas Plesch > Sent: Feb 14, 2025 11:36 AM To: Holger Seelig > Cc: X3D >, Joseph D Williams > Subject: Re: [x3d-public] SFRotation default value spec. inconsistency Let me just add for clarity that the length (or norm) of a quaternion includes the fourth, the scalar component. The norm is the square root of the sum of the squares of all four components. Only unit quaternions represent rotations. A (0,0,0,0) quaternion does not represent any rotation (but of course exists outside of rotations). Andreas PS: To add back in some fuzziness, a unit quaternion can only represent a rotation up to 360 degrees. I think there is a mechanism to use non-unit quaternions for larger rotations. On Fri, Feb 14, 2025 at 10:22?AM Holger Seelig > wrote: All quaternions must be normalized to be a legal rotation, so the length of the quaternion must always be one. Holger -- Holger Seelig Leipzig, Germany holger.seelig at yahoo.de https://create3000.github.io/x_ite/ Am 14.02.2025 um 15:38 schrieb Joe D Williams via x3d-public >: > So, sensibly, a zero rotation around any axis corresponds to the "zero unit Quaternion" (0, 0, 0, 1 XYZW), Right. Not sure but 0 0 0 0 for unit quaternion might not be legal. I think the values must compute to1 to be legal? Thanks, Joe -----Original Message----- From: Andreas Plesch > Sent: Feb 10, 2025 12:37 PM To: Joe D Williams > Cc: Extensible 3D (X3D) Graphics public discussion > Subject: Re: [x3d-public] SFRotation default value spec. inconsistency https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#_node_rotation has indeed (0, 0, 0, 1 XYZW) as a default value. This is difficult to interpret as a rotation around an axis since the corresponding axis would be at first glance (0 0 0). x3dom converts quaternion (0, 0, 0, 1 XYZW) to (axis),angle (0,0,0),0 as does https://www.andre-gaschler.com/rotationconverter/ . On the other hand both SFRotation (0 0 1 0) and SFRotation (0 1 0 0) are also represented by quaternion (0, 0, 0, 1 XYZW). So, sensibly, a zero rotation around any axis corresponds to the "zero unit Quaternion" (0, 0, 0, 1 XYZW), making it a useful default value for quaternions. But that does not help with choosing a default axis for the SFRotation value. This will rarely matter. A use case may be when a SFRotation is initialized to the X3D default in a Proto but then only the angle is modified by a Proto script with the assumption that the axis is (0 0 1). -Andreas On Mon, Feb 10, 2025 at 12:57?PM Joe D Williams > wrote: not zerp, zero -----Original Message----- From: Extensible 3D (X3D) Graphics public discussion > Sent: Feb 10, 2025 9:50 AM To: Extensible 3D (X3D) Graphics public discussion >, X3D Graphics public mailing list > Cc: Joe D Williams >, Andreas Plesch > Subject: Re: [x3d-public] SFRotation default value spec. inconsistency I think the 0 0 1 0 should be used everywhere for default axis-angle. I thinkI see 'zerp' unit quaternions (as in gltf as 0 0 0 1 XYZW) Thanks, Joe -----Original Message----- From: Extensible 3D (X3D) Graphics public discussion > Sent: Feb 10, 2025 8:44 AM To: X3D Graphics public mailing list > Cc: Andreas Plesch > Subject: Re: [x3d-public] SFRotation default value spec. inconsistency The JS SAI spec. at https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#FieldServices does not list functions for SFColorRGBA, only SFColor. There may be an earlier report. -Andreas On Mon, Feb 10, 2025 at 11:31?AM Andreas Plesch > wrote: https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/fieldTypes.html#SFRotationAndMFRotation specifies that (0 0 1 0) is the value of an uninitialized SFRotation given as (x y z a). However, the JS SAI spec. in table 7.18 in https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#SFRotationInstanceCreationFunction effectively makes (0 1 0 0) the default value if no parameters are provided. The inconsistency does not have much of an impact since both are 0 rotations but I believe (0 1 0 0) - a 0 rotation around y - may have been intended as the default. -Andreas -- Andreas Plesch Waltham, MA 02453 -- Andreas Plesch Waltham, MA 02453 -- Andreas Plesch Waltham, MA 02453 _______________________________________________ x3d-public mailing list x3d-public at web3d.org http://web3d.org/mailman/listinfo/x3d-public_web3d.org -- Andreas Plesch Waltham, MA 02453 -- Andreas Plesch Waltham, MA 02453 -------------- next part -------------- An HTML attachment was scrubbed... URL: From brutzman at nps.edu Mon Feb 17 21:17:34 2025 From: brutzman at nps.edu (Brutzman, Donald (Don) (CIV)) Date: Tue, 18 Feb 2025 05:17:34 +0000 Subject: [x3d-public] HAnimDisplacer effect on coord.point In-Reply-To: <2eee59f2-28bb-9443-f1b8-9f25048d1283@earthlink.net> References: <2eee59f2-28bb-9443-f1b8-9f25048d1283@earthlink.net> Message-ID: Wondering, do we have a simple excerpted example that we can look at yet? That will help guide these discussions. Don't need a full human body animation in all its displaceable glory... 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 https://faculty.nps.edu/brutzman ________________________________ From: x3d-public on behalf of Joe D Williams via x3d-public Sent: Saturday, February 15, 2025 6:55 PM To: Holger Seelig ; Andreas Plesch Cc: joedwil at earthlink.net ; X3D ; Carol McDonald Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point > coord.point changes are very very expensive quickly, Right, the processing time gets expensive as the number of points moved. If level 1 segment geometry where the mesh is driven directly by a joint, then it easier since weight is always 1. For level 2 skin, the the weight (radial movement) applied by maybe multiple joints needs to be computed for each point. Finally, for both levels, the displacements for selected set of points needs to be applied. This implies multiple passes on the subject coordinates? Whatever, these operations are common where the applications deal with a complete mesh and with sparse points of a mesh for blending. . > with reference to CoordinateInterpolator, These are useful when controlling all points of a target mesh. All points of a mesh must be included and same number of points at each keyframe. This style was used in first step of the current example x3d FACS because face geometry is made from multiple shapes. CoordinateInterpolater sets for each shape for each elemental action moved the points. This was simplified to using the same face for each action example and then replaced the CIs with sets of Displacers. Now have developed further to combine individual actions to make a specific expression which consists of multiple elemental movements. However, I think we want to evolve towards a basic single mesh face with some individual shapes for like teeth, hair, eyeballs, eyelids, tongue, maybe ears? and using joint nodes to control, where appropriate. Regardless of how the points are moved for the next frame, it has to be considered that geometry points will be moved directly by joint rotations, by a weighting algorithm using multiple joint rotation inputs, and by one or more scalar-driven Displacer inputs. Thanks for HAnim, Joe -----Message----- From: Holger Seelig Sent: Feb 9, 2025 11:23 AM To: Andreas Plesch Cc: X3D , Joseph D Williams , Carol McDonald Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point I don't think so, coord.point changes are very very expensive quickly, and as Michalis said earlier, with reference to CoordinateInterpolator, we should get rid of them. Holger -- Holger Seelig Leipzig, Germany holger.seelig at yahoo.de https://create3000.github.io/x_ite/ Am 09.02.2025 um 19:44 schrieb Andreas Plesch : Yes, that is an option. However,coord.point changes are very very expensive quickly, and as Michalis said earlier, with reference to CoordinateInterpolator, we should get rid of them. Andreas On Sun, Feb 9, 2025, 1:40?PM Holger Seelig > wrote: X_ITE applies the HAnimDisplacers in the shader, thus no coord.point field has to be changed. Maybe that helps. Best regards, Holger -- Holger Seelig Leipzig, Germany holger.seelig at yahoo.de https://create3000.github.io/x_ite/ Am 09.02.2025 um 19:33 schrieb Andreas Plesch via x3d-public >: That would be the point field of a Coordinate node https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/rendering.html#Coordinate which is used by the coord field of https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimSegment Andreas On Sun, Feb 9, 2025, 12:36?PM Joe D Williams > wrote: > coord node emit a point_changed event sorry,I don't see a field anywhere with that event. Displacer is likely to change several points when new weight is sent. All part of the cascade to produce the changed mesh? Thanks, Joe -----Original Message----- From: Andreas Plesch > Sent: Feb 9, 2025 4:25 AM To: Brutzman, Donald (Don) (CIV) > Cc: Extensible 3D (X3D) Graphics public discussion >, Carol McDonald >, Joe D Williams >, John Carlson > Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point Don, Joe and John Thanks for collecting these references. But I am not sure if there is an answer to my original question. Let me rephrase a bit the question: After a Displacer contained in a Segment node receives a set_weight input, should then the coord node emit a point_changed event ? I do not think HAnim is concerned about that, so it is really a X3D question. Thanks, Andreas On Sun, Feb 9, 2025, 12:49?AM Brutzman, Donald (Don) (CIV) > wrote: Thanks for pointing in the right direction John. Direct links to functional requirements for Displacer in HAnim 2.0 specification: * HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, Clause 4 Concepts, 4.7 Displacer object * https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#DisplacerObject * HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, Clause 6 Object interfaces, 6.6 Displacer * https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer and * X3D 4.0 Architecture, Clause 26 Humanoid Animation (HAnim) component, 26.3.1 HAnimDisplacer * https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimDisplacer and informative * X3D Tooltips, HAnimDisplacer * https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimDisplacer Thanks for implementation efforts and careful scrutiny. Questions and potential issues/clarifications/corrections are always welcome. 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 https://faculty.nps.edu/brutzman ________________________________ From: x3d-public > on behalf of John Carlson via x3d-public > Sent: Saturday, February 8, 2025 3:43 AM To: Extensible 3D (X3D) Graphics public discussion >; Carol McDonald >; Joe D Williams > Cc: John Carlson >; Andreas Plesch > Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point Here?s what HAnim spec says under Displacer: https://www.web3d.org/documents/specifications/19774/V2.0/index.html ?For the Displacer objects that are contained in the displacers field of the Segment objects, the displacements are defined and applied in the Segment coordinate system. The base mesh for the morphed Segment is the original mesh defined in the Segment.? And here?s what it says under Segment: ? The coord field is used for Segment objects that have deformable meshes and shall contain coordinates referenced from the indexed mesh for the Segment object. The coordinates are given the same name as the Segment object, but with a "_coords" appended (e.g.,"skull_coords").? displacements are an offset from the mesh, with weight from 0 to 1. So weight times displacement is total offset from base mesh. 0 weight = no offset, 1 weight = full displacements offset The Coordinate point is maintained to handle weight = 0. Weight ranges from 0 to 1, but double check. Joe or Carol might know where to find it in the HAnim spec. I believe the answer is, ?during rendering,?. Since weight can vary with animation, and so can displacements, AFAIK. More than one displacer can be applied to the mesh. I have not read the spec. John On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public > wrote: https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer does not directly explain what the effect of the displacer on the coord.point field of the containing HAnimSegment is. But it mentions the coord.point field and seems to imply that the coord.point field is involved. So the question is if the Displacer should alter the coord.point field in order to achieve a graphical displacement, or if the Browser should only apply the displacements during rendering without a change in the coord.point field ? This is relevant if the coord.point field is accessed by routes or scripts, in addition to displacers. Thanks for any feedback or ideas, Andreas -- Andreas Plesch Waltham, MA 02453 _______________________________________________ x3d-public mailing list x3d-public at web3d.org http://web3d.org/mailman/listinfo/x3d-public_web3d.org _______________________________________________ x3d-public mailing list x3d-public at web3d.org http://web3d.org/mailman/listinfo/x3d-public_web3d.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From joedwil at earthlink.net Tue Feb 18 07:16:48 2025 From: joedwil at earthlink.net (Joe D Williams) Date: Tue, 18 Feb 2025 15:16:48 +0000 Subject: [x3d-public] SFRotation default value spec. inconsistency Message-ID: > ... may prefer the equivalent zero-rotation default value 0 1 0 0 since rotation about the vertical Y-axis is most common. Example values: 0 1 0 1.57 actually, when you start to do hanim it is quickly found that from I-pose, most motions like walk and run and throw each need mainly pitch, X-axis rotation, but most are combinations of some pitch and yaw and roll, x and y and z. The example showing 0 1 0 0 Yaw moves the head and other twists of the skeleton. Z rotation is used a lot for arm raises along with wrist and finger rolls. Thanks Don. So the Transform rotation and Viewpoint orientation and any other use of rotation and orientation are treated as default zero when angle is zero, or, if all x, y, and z are zero. Yes, it is some Fun, Joe -----Original Message----- From: Brutzman, Donald (Don) (CIV) Sent: Feb 17, 2025 9:08 PM To: Andreas Plesch , Joseph D Williams Cc: Extensible 3D (X3D) Graphics public discussion Subject: Re: [x3d-public] SFRotation default value spec. inconsistency Thanks for discussion and for noticing the difference. Related references: * 19777-1 X3D ECMAScript language binding, clause 7 Function definitions, 7.6.6 SFRotation * https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#SFRotation * Table 7.18 — SFRotation instance creation functions * SFRotation (numeric x, numeric y, numeric z, numeric angle) x, y, and z are the axis of the rotation. angle is the angle of the rotation (in radians). Missing values default to 0.0, except y, which defaults to 1.0. * X3D Architecture, clause 5 Field type reference, 5.3.13 SFRotation and MFRotation * https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/fieldTypes.html#SFRotationAndMFRotation * "The default value of an uninitialized SFRotation field is (0 0 1 0). The default value of an MFRotation field is the empty list." Yes they must be the same, so that X3D models are equivalent no matter what file encoding or programming-language binding are used. The X3D Architecture takes precedence. So we will change 19777-1 to match and the highlighted y above will become z. I too think that a default of (0 1 0 0) makes more sense, animation rotations are most often around the vertical (y) axis. However, the community has discussed this many times over the years. We always landed on (0 0 1 0) for backwards-compatibility reasons, not wanting to break legacy X3D and VRML models. Incidentally here is the X3D tooltips entry. Improvements and refinements always welcome. * X3D Tooltips: SFRotation * https://www.web3d.org/x3d/tooltips/X3dTooltips.html#SFRotation * SFRotation (https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/fieldTypes.html#SFRotationAndMFRotation) Single-Field rotation value using 3-tuple axis, radian angle form Default value 0 0 1 0. Model authors and authoring tools may prefer the equivalent zero-rotation default value 0 1 0 0 since rotation about the vertical Y-axis is most common. Example values: 0 1 0 1.57 Warning: initial 3-tuple axis vector cannot hold a zero-magnitude vector. Warning: comma characters within attribute values are not allowed, and do not pass strict validation. Hint: see Wikipedia: Radian (https://en.wikipedia.org/wiki/Radian), Rotation matrix (https://en.wikipedia.org/wiki/Rotation_matrix) and Rotation formalisms in three dimensions (https://en.wikipedia.org/wiki/Rotation_formalisms_in_three_dimensions). XML Schema (https://www.web3d.org/specifications/X3dSchemaDocumentation4.0/x3d-4.0_SFRotation.html), X3D regexes (https://www.web3d.org/specifications/X3dRegularExpressions.html#SFRotation), Java SAI (https://www.web3d.org/specifications/JavaLanguageBinding/Part2/nodeTypeInterfaces.html#SFRotation), X3DJ (https://www.web3d.org/specifications/java/javadoc/org/web3d/x3d/jsail/fields/SFRotation.html) To keep track of this erratum, I have entered a new issue in the Mantis issue tracker. * Mantis 1488: (ECMAScript) 7.6.6 SFRotation default value needs to be (0 0 1 0) * https://mantis.web3d.org/view.php?id=1488 I hope this make sense and sounds good. Have fun with X3D - or else!! ? 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 https://faculty.nps.edu/brutzman From: x3d-public on behalf of Joe D Williams via x3d-public Sent: Sunday, February 16, 2025 9:09 AM To: Andreas Plesch Cc: joedwil at earthlink.net ; X3D Subject: Re: [x3d-public] SFRotation default value spec. inconsistency > I would vote for 0 1 0 0 since rotations around Y seem more common First,oldest use is in Part 1, way back to origin of VRML standard. Is Yaw really more popular or common than Pitch or Roll? For me, Please let's stick with oldest history and update more recent. Thanks Joe -----Original Message----- From: Andreas Plesch Sent: Feb 15, 2025 9:12 PM To: Cc: Holger Seelig , X3D Subject: Re: [x3d-public] SFRotation default value spec. inconsistency I agree, probably the best default value for a unit quaternion is 0 0 0 1. However, X3D does not concern itself with quaternions, only axis-angle rotations. So the original question remains: Part 1 has axis-angle 0 0 1 0 as default while the JS SAI spec. has 0 1 0 0. Should both list the same default value ? If yes, which one ? I would vote for 0 1 0 0 since rotations around Y seem more common. -Andreas On Sat, Feb 15, 2025 at 11:04?PM wrote: Doesn't this mean that the _best_ default value, for no rotation, is 'legally' for unit quaternion = 0 0 0 1 because the square root of the sum of the squares of all four components does = 1 ? 0 0 0 0 would not be a legal unit quaternion. While the axis-angle default is 0 0 1 0 as appears in Part 1 is mostly for convenience since many value combinations can produce zero rotation? Also sure shows why axis-angle is so much easier to work with when typing numbers, pitch and yaw and roll for all. Thanks, Joe -----Original Message----- From: Andreas Plesch Sent: Feb 14, 2025 11:36 AM To: Holger Seelig Cc: X3D , Joseph D Williams Subject: Re: [x3d-public] SFRotation default value spec. inconsistency Let me just add for clarity that the length (or norm) of a quaternion includes the fourth, the scalar component. The norm is the square root of the sum of the squares of all four components. Only unit quaternions represent rotations. A (0,0,0,0) quaternion does not represent any rotation (but of course exists outside of rotations). Andreas PS: To add back in some fuzziness, a unit quaternion can only represent a rotation up to 360 degrees. I think there is a mechanism to use non-unit quaternions for larger rotations. On Fri, Feb 14, 2025 at 10:22?AM Holger Seelig wrote: All quaternions must be normalized to be a legal rotation, so the length of the quaternion must always be one. Holger-- Holger Seelig Leipzig, Germany holger.seelig at yahoo.de (mailto:holger.seelig at yahoo.de) https://create3000.github.io/x_ite/ Am 14.02.2025 um 15:38 schrieb Joe D Williams via x3d-public : > So, sensibly, a zero rotation around any axis corresponds to the "zero unit Quaternion" (0, 0, 0, 1 XYZW), Right. Not sure but 0 0 0 0 for unit quaternion might not be legal. I think the values must compute to1 to be legal? Thanks, Joe -----Original Message----- From: Andreas Plesch Sent: Feb 10, 2025 12:37 PM To: Joe D Williams Cc: Extensible 3D (X3D) Graphics public discussion Subject: Re: [x3d-public] SFRotation default value spec. inconsistency https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#_node_rotation has indeed (0, 0, 0, 1 XYZW) as a default value. This is difficult to interpret as a rotation around an axis since the corresponding axis would be at first glance (0 0 0). x3dom converts quaternion (0, 0, 0, 1 XYZW) to (axis),angle (0,0,0),0 as does https://www.andre-gaschler.com/rotationconverter/ (https://www.andre-gaschler.com/rotationconverter/) . On the other hand both SFRotation (0 0 1 0) and SFRotation (0 1 0 0) are also represented by quaternion (0, 0, 0, 1 XYZW). So, sensibly, a zero rotation around any axis corresponds to the "zero unit Quaternion" (0, 0, 0, 1 XYZW), making it a useful default value for quaternions. But that does not help with choosing a default axis for the SFRotation value. This will rarely matter. A use case may be when a SFRotation is initialized to the X3D default in a Proto but then only the angle is modified by a Proto script with the assumption that the axis is (0 0 1). -Andreas On Mon, Feb 10, 2025 at 12:57?PM Joe D Williams wrote: not zerp, zero -----Original Message----- From: Extensible 3D (X3D) Graphics public discussion Sent: Feb 10, 2025 9:50 AM To: Extensible 3D (X3D) Graphics public discussion , X3D Graphics public mailing list Cc: Joe D Williams , Andreas Plesch Subject: Re: [x3d-public] SFRotation default value spec. inconsistency I think the 0 0 1 0 should be used everywhere for default axis-angle. I thinkI see 'zerp' unit quaternions (as in gltf as 0 0 0 1 XYZW) Thanks, Joe -----Original Message----- From: Extensible 3D (X3D) Graphics public discussion Sent: Feb 10, 2025 8:44 AM To: X3D Graphics public mailing list Cc: Andreas Plesch Subject: Re: [x3d-public] SFRotation default value spec. inconsistency The JS SAI spec. at https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#FieldServices (https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#FieldServices) does not list functions for SFColorRGBA, only SFColor. There may be an earlier report. -Andreas On Mon, Feb 10, 2025 at 11:31?AM Andreas Plesch wrote: https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/fieldTypes.html#SFRotationAndMFRotation specifies that (0 0 1 0) is the value of an uninitialized SFRotation given as (x y z a). However, the JS SAI spec. in table 7.18 in https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#SFRotationInstanceCreationFunction (https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#SFRotationInstanceCreationFunction) effectively makes (0 1 0 0) the default value if no parameters are provided. The inconsistency does not have much of an impact since both are 0 rotations but I believe (0 1 0 0) - a 0 rotation around y - may have been intended as the default. -Andreas -- Andreas Plesch Waltham, MA 02453 -- Andreas Plesch Waltham, MA 02453 -- Andreas Plesch Waltham, MA 02453 _______________________________________________ x3d-public mailing list x3d-public at web3d.org (mailto:x3d-public at web3d.org) http://web3d.org/mailman/listinfo/x3d-public_web3d.org -- Andreas Plesch Waltham, MA 02453 -- Andreas Plesch Waltham, MA 02453 -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreasplesch at gmail.com Tue Feb 18 11:13:01 2025 From: andreasplesch at gmail.com (Andreas Plesch) Date: Tue, 18 Feb 2025 14:13:01 -0500 Subject: [x3d-public] HAnimDisplacer effect on coord.point In-Reply-To: References: <2eee59f2-28bb-9443-f1b8-9f25048d1283@earthlink.net> Message-ID: Hi Don, I noticed that in the message thread below my response to Holger's first note on displacement shaders somehow includes his followup which would require time traveling. My actual response was simply: "Yes, that is an option. However, the question is if it should be changed so it is available for other purposes." It refers to the COORD.point field. Here is an example of "other purposes": https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/andreasplesch/x3dom/refs/heads/HAnim_displacers/test/functional/hanim/pointOutput_Tongue.x3d [Alt-Q for toggling long line wrapping]. This takes the displacer modified COORD.point field from the HAnimSegment and uses it in a PositionInterpolator to keep an animated object on the tongue while portions of the tongue are displaced. There are not too many nodes which can take an MFVec3f value as input, so many real use cases would probably involve a script. But a script would still require the X3D browser to update the COORD.point field. Giving access to the displaced vertices in an HAnimSegment (and other HAnim geometry) is expensive and I am uncertain if the added value for scene authors is worth the substantial performance penalty. x3dom can currently do it because it just uses slow javascript (in a streamlined way) for displacing. A shader based solution is much faster for rendering while still expensive in exposing updated point coordinates to the scene. In any case, it may be helpful to clarify in the spec. if a Displacer modifies the X3D value of the COORD.point field or just affects the graphical representation of associated Shapes without modifying values. Perhaps this could become an advanced level capability. -Andreas On Tue, Feb 18, 2025 at 12:17?AM Brutzman, Donald (Don) (CIV) < brutzman at nps.edu> wrote: > Wondering, do we have a simple excerpted example that we can look at yet? > That will help guide these discussions. > > Don't need a full human body animation in all its displaceable glory... > > > 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 > https://faculty.nps.edu/brutzman > > > > ------------------------------ > *From:* x3d-public on behalf of Joe D > Williams via x3d-public > *Sent:* Saturday, February 15, 2025 6:55 PM > *To:* Holger Seelig ; Andreas Plesch < > andreasplesch at gmail.com> > *Cc:* joedwil at earthlink.net ; X3D < > x3d-public at web3d.org>; Carol McDonald > *Subject:* Re: [x3d-public] HAnimDisplacer effect on coord.point > > > > coord.point changes are very very expensive quickly, > > > > Right, the processing time gets expensive as the number of points moved. > > If level 1 segment geometry where the mesh is driven directly by a joint, > then it easier since weight is always 1. > > For level 2 skin, the the weight (radial movement) applied by maybe > multiple joints needs to be computed for each point. > > Finally, for both levels, the displacements for selected set of points > needs to be applied. > > This implies multiple passes on the subject coordinates? > > Whatever, these operations are common where the applications deal with > > a complete mesh and with sparse points of a mesh for blending. . > > > > > with reference to CoordinateInterpolator, > > > > These are useful when controlling all points of a target mesh. > > All points of a mesh must be included and same number of points at each > keyframe. > > This style was used in first step of the current example x3d FACS because > > face geometry is made from multiple shapes. CoordinateInterpolater sets > > for each shape for each elemental action moved the points. > > This was simplified to using the same face for each action example > > and then replaced the CIs with sets of Displacers. > > Now have developed further to combine individual actions to make a > > specific expression which consists of multiple elemental movements. > > However, I think we want to evolve towards a basic single mesh face > > with some individual shapes for like teeth, hair, eyeballs, eyelids, > tongue, maybe ears? > > and using joint nodes to control, where appropriate. > > > > Regardless of how the points are moved for the next frame, it has to be > > considered that geometry points will be moved directly by joint > rotations, > > by a weighting algorithm using multiple joint rotation inputs, > > and by one or more scalar-driven Displacer inputs. > > > > Thanks for HAnim, > > Joe > > > > > > > > > > > > > > > > > > > > -----Message----- > > From: Holger Seelig > Sent: Feb 9, 2025 11:23 AM > To: Andreas Plesch > Cc: X3D , Joseph D Williams , > Carol McDonald > Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point > > > I don't think so, coord.point changes are very very expensive quickly, and > as Michalis said earlier, with reference to CoordinateInterpolator, we > should get rid of them. > > Holger > -- > Holger Seelig > Leipzig, Germany > > holger.seelig at yahoo.de > https://create3000.github.io/x_ite/ > > Am 09.02.2025 um 19:44 schrieb Andreas Plesch : > Yes, that is an option. However,coord.point changes are very very > expensive quickly, and as Michalis said earlier, with reference to > CoordinateInterpolator, we should get rid of them. > > Andreas > > On Sun, Feb 9, 2025, 1:40?PM Holger Seelig wrote: > > X_ITE applies the HAnimDisplacers in the shader, thus no coord.point field > has to be changed. > Maybe that helps. > > Best regards, > Holger > > -- > Holger Seelig > Leipzig, Germany > > holger.seelig at yahoo.de > https://create3000.github.io/x_ite/ > > Am 09.02.2025 um 19:33 schrieb Andreas Plesch via x3d-public < > x3d-public at web3d.org>: > > That would be the point field of a Coordinate node > > > https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/rendering.html#Coordinate > > which is used by the coord field of > > > https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimSegment > > Andreas > > On Sun, Feb 9, 2025, 12:36?PM Joe D Williams > wrote: > > > coord node emit a point_changed event > > > sorry,I don't see a field anywhere with that event. Displacer is likely to > change several points when new weight is sent. All part of the cascade to > produce the changed mesh? > Thanks, > Joe > > > > > > -----Original Message----- > From: Andreas Plesch > Sent: Feb 9, 2025 4:25 AM > To: Brutzman, Donald (Don) (CIV) > Cc: Extensible 3D (X3D) Graphics public discussion , > Carol McDonald , Joe D Williams , > John Carlson > Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point > > > Don, Joe and John > > Thanks for collecting these references. > > But I am not sure if there is an answer to my original question. Let me > rephrase a bit the question: > > After a Displacer contained in a Segment node receives a set_weight input, > should then the coord node emit a point_changed event ? > > I do not think HAnim is concerned about that, so it is really a X3D > question. > > Thanks, Andreas > > On Sun, Feb 9, 2025, 12:49?AM Brutzman, Donald (Don) (CIV) < > brutzman at nps.edu> wrote: > > Thanks for pointing in the right direction John. > > Direct links to functional requirements for Displacer in HAnim 2.0 > specification: > > - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, > Clause 4 Concepts, 4.7 Displacer object > - > https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#DisplacerObject > > - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, > Clause 6 Object interfaces, 6.6 Displacer > - > https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer > > and > > - X3D 4.0 Architecture, Clause 26 Humanoid Animation (HAnim) > component, 26.3.1 HAnimDisplacer > - > https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimDisplacer > > and informative > > - X3D Tooltips, HAnimDisplacer > - https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimDisplacer > > Thanks for implementation efforts and careful scrutiny. > > Questions and potential issues/clarifications/corrections are always > welcome. > > > 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 > https://faculty.nps.edu/brutzman > > > > ------------------------------ > *From:* x3d-public on behalf of John > Carlson via x3d-public > *Sent:* Saturday, February 8, 2025 3:43 AM > *To:* Extensible 3D (X3D) Graphics public discussion ; > Carol McDonald ; Joe D Williams > *Cc:* John Carlson ; Andreas Plesch < > andreasplesch at gmail.com> > *Subject:* Re: [x3d-public] HAnimDisplacer effect on coord.point > > Here?s what HAnim spec says under Displacer: > > https://www.web3d.org/documents/specifications/19774/V2.0/index.html > > ?For the *Displacer* objects that are contained in the *displacers* field > of the *Segment* objects, the *displacements* are defined and applied in > the *Segment* coordinate system. The base mesh for the morphed *Segment* is > the original mesh defined in the *Segment*.? > > And here?s what it says under Segment: > > ? > > The *coord* field is used for *Segment* objects that have deformable > meshes and shall contain coordinates referenced from the indexed mesh for > the *Segment* object. The coordinates are given the same name as the > *Segment* object, but with a "_coords" appended (e.g.,"skull_coords").? > displacements are an offset from the mesh, with weight from 0 to 1. So > weight times displacement is total offset from base mesh. 0 weight = no > offset, 1 weight = full displacements offset > > The Coordinate point is maintained to handle weight = 0. Weight ranges > from 0 to 1, but double check. > > Joe or Carol might know where to find it in the HAnim spec. > > I believe the answer is, ?during rendering,?. Since weight can vary with > animation, and so can displacements, AFAIK. More than one displacer can be > applied to the mesh. > > I have not read the spec. > > John > > > > On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public < > x3d-public at web3d.org> wrote: > > > https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer > > does not directly explain what the effect of the displacer on the > coord.point field of the containing HAnimSegment is. But it mentions the > coord.point field and seems to imply that the coord.point field is involved. > > So the question is if the Displacer should alter the coord.point field in > order to achieve a graphical displacement, or if the Browser should only > apply the displacements during rendering without a change in the > coord.point field ? > > This is relevant if the coord.point field is accessed by routes or > scripts, in addition to displacers. > > Thanks for any feedback or ideas, > > Andreas > > -- > Andreas Plesch > Waltham, MA 02453 > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > > > > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > > > -- Andreas Plesch Waltham, MA 02453 -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Tue Feb 18 11:25:11 2025 From: yottzumm at gmail.com (John Carlson) Date: Tue, 18 Feb 2025 13:25:11 -0600 Subject: [x3d-public] HAnimDisplacer effect on coord.point In-Reply-To: References: <2eee59f2-28bb-9443-f1b8-9f25048d1283@earthlink.net> Message-ID: Don, we?re currently working on a HUD for Joe, I don?t currently have an online example of that. Otherwise, I?m waiting on someone deciding which meshes to merge. I could take the lead on this. I could use a tutorial on the Layering and Layout components, examples don?t seem to help. I may try to adopt a 3D HUD based on examples. Something with the 2D overlay in WORLD space would help tremendously, or some conversion from WORLD space. We already have 3D menus, so a 3D HUD might be easiest. Thanks, John On Mon, Feb 17, 2025 at 11:18?PM Brutzman, Donald (Don) (CIV) via x3d-public wrote: > Wondering, do we have a simple excerpted example that we can look at yet? > That will help guide these discussions. > > Don't need a full human body animation in all its displaceable glory... > > > 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 > https://faculty.nps.edu/brutzman > > > > ------------------------------ > *From:* x3d-public on behalf of Joe D > Williams via x3d-public > *Sent:* Saturday, February 15, 2025 6:55 PM > *To:* Holger Seelig ; Andreas Plesch < > andreasplesch at gmail.com> > *Cc:* joedwil at earthlink.net ; X3D < > x3d-public at web3d.org>; Carol McDonald > > *Subject:* Re: [x3d-public] HAnimDisplacer effect on coord.point > > > > coord.point changes are very very expensive quickly, > > > > Right, the processing time gets expensive as the number of points moved. > > If level 1 segment geometry where the mesh is driven directly by a joint, > then it easier since weight is always 1. > > For level 2 skin, the the weight (radial movement) applied by maybe > multiple joints needs to be computed for each point. > > Finally, for both levels, the displacements for selected set of points > needs to be applied. > > This implies multiple passes on the subject coordinates? > > Whatever, these operations are common where the applications deal with > > a complete mesh and with sparse points of a mesh for blending. . > > > > > with reference to CoordinateInterpolator, > > > > These are useful when controlling all points of a target mesh. > > All points of a mesh must be included and same number of points at each > keyframe. > > This style was used in first step of the current example x3d FACS because > > face geometry is made from multiple shapes. CoordinateInterpolater sets > > for each shape for each elemental action moved the points. > > This was simplified to using the same face for each action example > > and then replaced the CIs with sets of Displacers. > > Now have developed further to combine individual actions to make a > > specific expression which consists of multiple elemental movements. > > However, I think we want to evolve towards a basic single mesh face > > with some individual shapes for like teeth, hair, eyeballs, eyelids, > tongue, maybe ears? > > and using joint nodes to control, where appropriate. > > > > Regardless of how the points are moved for the next frame, it has to be > > considered that geometry points will be moved directly by joint > rotations, > > by a weighting algorithm using multiple joint rotation inputs, > > and by one or more scalar-driven Displacer inputs. > > > > Thanks for HAnim, > > Joe > > > > > > > > > > > > > > > > > > > > -----Message----- > > From: Holger Seelig > Sent: Feb 9, 2025 11:23 AM > To: Andreas Plesch > Cc: X3D , Joseph D Williams , > Carol McDonald > Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point > > > I don't think so, coord.point changes are very very expensive quickly, and > as Michalis said earlier, with reference to CoordinateInterpolator, we > should get rid of them. > > Holger > -- > Holger Seelig > Leipzig, Germany > > holger.seelig at yahoo.de > https://create3000.github.io/x_ite/ > > Am 09.02.2025 um 19:44 schrieb Andreas Plesch : > Yes, that is an option. However,coord.point changes are very very > expensive quickly, and as Michalis said earlier, with reference to > CoordinateInterpolator, we should get rid of them. > > Andreas > > On Sun, Feb 9, 2025, 1:40?PM Holger Seelig wrote: > > X_ITE applies the HAnimDisplacers in the shader, thus no coord.point field > has to be changed. > Maybe that helps. > > Best regards, > Holger > > -- > Holger Seelig > Leipzig, Germany > > holger.seelig at yahoo.de > https://create3000.github.io/x_ite/ > > Am 09.02.2025 um 19:33 schrieb Andreas Plesch via x3d-public < > x3d-public at web3d.org>: > > That would be the point field of a Coordinate node > > > https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/rendering.html#Coordinate > > which is used by the coord field of > > > https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimSegment > > Andreas > > On Sun, Feb 9, 2025, 12:36?PM Joe D Williams > wrote: > > > coord node emit a point_changed event > > > sorry,I don't see a field anywhere with that event. Displacer is likely to > change several points when new weight is sent. All part of the cascade to > produce the changed mesh? > Thanks, > Joe > > > > > > -----Original Message----- > From: Andreas Plesch > Sent: Feb 9, 2025 4:25 AM > To: Brutzman, Donald (Don) (CIV) > Cc: Extensible 3D (X3D) Graphics public discussion , > Carol McDonald , Joe D Williams , > John Carlson > Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point > > > Don, Joe and John > > Thanks for collecting these references. > > But I am not sure if there is an answer to my original question. Let me > rephrase a bit the question: > > After a Displacer contained in a Segment node receives a set_weight input, > should then the coord node emit a point_changed event ? > > I do not think HAnim is concerned about that, so it is really a X3D > question. > > Thanks, Andreas > > On Sun, Feb 9, 2025, 12:49?AM Brutzman, Donald (Don) (CIV) < > brutzman at nps.edu> wrote: > > Thanks for pointing in the right direction John. > > Direct links to functional requirements for Displacer in HAnim 2.0 > specification: > > - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, > Clause 4 Concepts, 4.7 Displacer object > - > https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#DisplacerObject > > - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, > Clause 6 Object interfaces, 6.6 Displacer > - > https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer > > and > > - X3D 4.0 Architecture, Clause 26 Humanoid Animation (HAnim) > component, 26.3.1 HAnimDisplacer > - > https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimDisplacer > > and informative > > - X3D Tooltips, HAnimDisplacer > - https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimDisplacer > > Thanks for implementation efforts and careful scrutiny. > > Questions and potential issues/clarifications/corrections are always > welcome. > > > 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 > https://faculty.nps.edu/brutzman > > > > ------------------------------ > *From:* x3d-public on behalf of John > Carlson via x3d-public > *Sent:* Saturday, February 8, 2025 3:43 AM > *To:* Extensible 3D (X3D) Graphics public discussion ; > Carol McDonald ; Joe D Williams > *Cc:* John Carlson ; Andreas Plesch < > andreasplesch at gmail.com> > *Subject:* Re: [x3d-public] HAnimDisplacer effect on coord.point > > Here?s what HAnim spec says under Displacer: > > https://www.web3d.org/documents/specifications/19774/V2.0/index.html > > ?For the *Displacer* objects that are contained in the *displacers* field > of the *Segment* objects, the *displacements* are defined and applied in > the *Segment* coordinate system. The base mesh for the morphed *Segment* is > the original mesh defined in the *Segment*.? > > And here?s what it says under Segment: > > ? > > The *coord* field is used for *Segment* objects that have deformable > meshes and shall contain coordinates referenced from the indexed mesh for > the *Segment* object. The coordinates are given the same name as the > *Segment* object, but with a "_coords" appended (e.g.,"skull_coords").? > displacements are an offset from the mesh, with weight from 0 to 1. So > weight times displacement is total offset from base mesh. 0 weight = no > offset, 1 weight = full displacements offset > > The Coordinate point is maintained to handle weight = 0. Weight ranges > from 0 to 1, but double check. > > Joe or Carol might know where to find it in the HAnim spec. > > I believe the answer is, ?during rendering,?. Since weight can vary with > animation, and so can displacements, AFAIK. More than one displacer can be > applied to the mesh. > > I have not read the spec. > > John > > > > On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public < > x3d-public at web3d.org> wrote: > > > https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer > > does not directly explain what the effect of the displacer on the > coord.point field of the containing HAnimSegment is. But it mentions the > coord.point field and seems to imply that the coord.point field is involved. > > So the question is if the Displacer should alter the coord.point field in > order to achieve a graphical displacement, or if the Browser should only > apply the displacements during rendering without a change in the > coord.point field ? > > This is relevant if the coord.point field is accessed by routes or > scripts, in addition to displacers. > > Thanks for any feedback or ideas, > > Andreas > > -- > Andreas Plesch > Waltham, MA 02453 > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > > > > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > > > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Tue Feb 18 11:37:53 2025 From: yottzumm at gmail.com (John Carlson) Date: Tue, 18 Feb 2025 13:37:53 -0600 Subject: [x3d-public] SFRotation default value spec. inconsistency In-Reply-To: References: Message-ID: I agree with Joe on the HAnim X-Axis note. I was thinking similarly. John On Tue, Feb 18, 2025 at 9:17?AM Joe D Williams via x3d-public < x3d-public at web3d.org> wrote: > > ... may prefer the equivalent zero-rotation default value *0 1 0 0* > > since rotation about the vertical Y-axis is most common. > > Example values: 0 1 0 1.57 > > > > actually, when you start to do hanim it is quickly found that from I-pose, > > most motions like walk and run and throw each need mainly pitch, X-axis > rotation, > > but most are combinations of some pitch and yaw and roll, x and y and z. > > > > The example showing 0 1 0 0 Yaw moves the head and other twists of the > skeleton. > > Z rotation is used a lot for arm raises along with wrist and finger rolls. > > > > Thanks Don. So the Transform rotation and Viewpoint orientation > > and any other use of rotation and orientation are treated as > > default zero when angle is zero, or, if all x, y, and z are zero. > > > > Yes, it is some Fun, > > Joe > > > > -----Original Message----- > From: Brutzman, Donald (Don) (CIV) > Sent: Feb 17, 2025 9:08 PM > To: Andreas Plesch , Joseph D Williams < > joedwil at earthlink.net> > Cc: Extensible 3D (X3D) Graphics public discussion > Subject: Re: [x3d-public] SFRotation default value spec. inconsistency > > > Thanks for discussion and for noticing the difference. Related references: > > - 19777-1 X3D ECMAScript language binding, clause 7 Function > definitions, 7.6.6 SFRotation > - > https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#SFRotation > - Table 7.18 ? SFRotation instance creation functions > - > SFRotation > (numeric x, > numeric y, > numeric z, > numeric angle) > x, y, and z are the axis of the rotation. angle is the angle of the > rotation (in radians). Missing values default to 0.0, except y, which > defaults to 1.0. > > - X3D Architecture, clause 5 Field type reference, 5.3.13 SFRotation > and MFRotation > - > https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/fieldTypes.html#SFRotationAndMFRotation > - "The default value of an uninitialized SFRotation field is (0 0 1 > 0). The default value of an MFRotation field is the empty list." > > Yes they must be the same, so that X3D models are equivalent no matter > what file encoding or programming-language binding are used. > > The X3D Architecture takes precedence. So we will change 19777-1 to match > and the highlighted y above will become z. > > I too think that a default of (0 1 0 0) makes more sense, animation > rotations are most often around the vertical (y) axis. However, the > community has discussed this many times over the years. We always landed > on (0 0 1 0) for backwards-compatibility reasons, not wanting to break > legacy X3D and VRML models. > > Incidentally here is the X3D tooltips entry. Improvements and refinements > always welcome. > > - X3D Tooltips: SFRotation > - https://www.web3d.org/x3d/tooltips/X3dTooltips.html#SFRotation > - > SFRotation > > Single-Field rotation value using 3-tuple axis, radian angle form > Default value *0 0 1 0*. Model authors and authoring tools may prefer > the equivalent zero-rotation default value *0 1 0 0* since rotation > about the vertical Y-axis is most common. Example values: 0 1 0 1.57 > *Warning:* initial 3-tuple axis vector cannot hold a zero-magnitude > vector. > *Warning:* comma characters within attribute values are not allowed, > and do not pass strict validation. > *Hint:* see Wikipedia: Radian , Rotation > matrix and Rotation > formalisms in three dimensions > > . > XML Schema > , > X3D regexes > , > Java SAI > , > X3DJ > > > > To keep track of this erratum, I have entered a new issue in the Mantis > issue tracker. > > - Mantis 1488: (ECMAScript) 7.6.6 SFRotation default value needs to be > (0 0 1 0) > - https://mantis.web3d.org/view.php?id=1488 > > I hope this make sense and sounds good. > > Have fun with X3D - or else!! ? > > > > 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 > https://faculty.nps.edu/brutzman > > > > ------------------------------ > *From:* x3d-public on behalf of Joe D > Williams via x3d-public > *Sent:* Sunday, February 16, 2025 9:09 AM > *To:* Andreas Plesch > *Cc:* joedwil at earthlink.net ; X3D < > x3d-public at web3d.org> > *Subject:* Re: [x3d-public] SFRotation default value spec. inconsistency > > > > I would vote for 0 1 0 0 since rotations around Y seem more common > > > > First,oldest use is in Part 1, way back to origin of VRML standard. > > Is Yaw really more popular or common than Pitch or Roll? > > For me, Please let's stick with oldest history and update more recent. > > Thanks > > Joe > > > > > > -----Original Message----- > From: Andreas Plesch > Sent: Feb 15, 2025 9:12 PM > To: > Cc: Holger Seelig , X3D > Subject: Re: [x3d-public] SFRotation default value spec. inconsistency > > > I agree, probably the best default value for a unit quaternion is 0 0 0 1. > > However, X3D does not concern itself with quaternions, only axis-angle > rotations. > > So the original question remains: Part 1 has axis-angle 0 0 1 0 as default > while the JS SAI spec. has 0 1 0 0. Should both list the same default value > ? > > If yes, which one ? I would vote for 0 1 0 0 since rotations around Y seem > more common. > > -Andreas > > On Sat, Feb 15, 2025 at 11:04?PM wrote: > > Doesn't this mean that the _best_ default value, for no rotation, is > 'legally' for unit quaternion = 0 0 0 1 > > because the square root of the sum of the squares of all four components > does = 1 ? > > 0 0 0 0 would not be a legal unit quaternion. > > While the axis-angle default is 0 0 1 0 as appears in Part 1 is mostly for > convenience > > since many value combinations can produce zero rotation? > > Also sure shows why axis-angle is so much easier to work with when typing > numbers, > > pitch and yaw and roll for all. > > Thanks, > > Joe > > > > -----Original Message----- > From: Andreas Plesch > Sent: Feb 14, 2025 11:36 AM > To: Holger Seelig > Cc: X3D , Joseph D Williams > Subject: Re: [x3d-public] SFRotation default value spec. inconsistency > > > Let me just add for clarity that the length (or norm) of a quaternion > includes the fourth, the scalar component. The norm is the square root of > the sum of the squares of all four components. > > Only unit quaternions represent rotations. A (0,0,0,0) quaternion does not > represent any rotation (but of course exists outside of rotations). > > Andreas > > PS: To add back in some fuzziness, a unit quaternion can only represent a > rotation up to 360 degrees. I think there is a mechanism to use non-unit > quaternions for larger rotations. > > On Fri, Feb 14, 2025 at 10:22?AM Holger Seelig > wrote: > > All quaternions must be normalized to be a legal rotation, so the length > of the quaternion must always be one. > > Holger > -- > Holger Seelig > Leipzig, Germany > > holger.seelig at yahoo.de > https://create3000.github.io/x_ite/ > > Am 14.02.2025 um 15:38 schrieb Joe D Williams via x3d-public < > x3d-public at web3d.org>: > > > So, sensibly, a zero rotation around any axis corresponds to the "zero > unit Quaternion" (0, 0, 0, 1 XYZW), > > > Right. Not sure but 0 0 0 0 for unit quaternion might not be legal. I > think the values must compute to1 to be legal? > Thanks, > Joe > > > > > > -----Original Message----- > From: Andreas Plesch > Sent: Feb 10, 2025 12:37 PM > To: Joe D Williams > Cc: Extensible 3D (X3D) Graphics public discussion > Subject: Re: [x3d-public] SFRotation default value spec. inconsistency > > > https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#_node_rotation > has indeed (0, 0, 0, 1 XYZW) as a default value. > > This is difficult to interpret as a rotation around an axis since the > corresponding axis would be at first glance (0 0 0). > > x3dom converts quaternion (0, 0, 0, 1 XYZW) to (axis),angle (0,0,0),0 as > does https://www.andre-gaschler.com/rotationconverter/ . > > On the other hand both SFRotation (0 0 1 0) and SFRotation (0 1 0 0) are > also represented by quaternion (0, 0, 0, 1 XYZW). > > So, sensibly, a zero rotation around any axis corresponds to the "zero > unit Quaternion" (0, 0, 0, 1 XYZW), making it a useful default value for > quaternions. But that does not help with choosing a default axis for the > SFRotation value. > > This will rarely matter. A use case may be when a SFRotation is > initialized to the X3D default in a Proto but then only the angle is > modified by a Proto script with the assumption that the axis is (0 0 1). > > -Andreas > > On Mon, Feb 10, 2025 at 12:57?PM Joe D Williams > wrote: > > not zerp, zero > > -----Original Message----- > From: Extensible 3D (X3D) Graphics public discussion > > Sent: Feb 10, 2025 9:50 AM > To: Extensible 3D (X3D) Graphics public discussion , > X3D Graphics public mailing list > Cc: Joe D Williams , Andreas Plesch < > andreasplesch at gmail.com> > Subject: Re: [x3d-public] SFRotation default value spec. inconsistency > > > I think the 0 0 1 0 should be used everywhere for default axis-angle. > I thinkI see 'zerp' unit quaternions (as in gltf as 0 0 0 1 XYZW) > Thanks, > Joe > > > > -----Original Message----- > From: Extensible 3D (X3D) Graphics public discussion > > Sent: Feb 10, 2025 8:44 AM > To: X3D Graphics public mailing list > Cc: Andreas Plesch > Subject: Re: [x3d-public] SFRotation default value spec. inconsistency > > > The JS SAI spec. at > https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#FieldServices > > does not list functions for SFColorRGBA, only SFColor. There may be an > earlier report. -Andreas > > On Mon, Feb 10, 2025 at 11:31?AM Andreas Plesch > wrote: > > > https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/fieldTypes.html#SFRotationAndMFRotation > > specifies that (0 0 1 0) is the value of an uninitialized SFRotation given > as (x y z a). > > However, the JS SAI spec. in table 7.18 in > https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#SFRotationInstanceCreationFunction > > effectively makes (0 1 0 0) the default value if no parameters are > provided. > > The inconsistency does not have much of an impact since both are 0 > rotations but I believe (0 1 0 0) - a 0 rotation around y - may have been > intended as the default. > > -Andreas > > -- > Andreas Plesch > Waltham, MA 02453 > > > > -- > Andreas Plesch > Waltham, MA 02453 > > > > > > > > -- > Andreas Plesch > Waltham, MA 02453 > > > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > > > > -- > Andreas Plesch > Waltham, MA 02453 > > > > > > -- > Andreas Plesch > Waltham, MA 02453 > > > > > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreasplesch at gmail.com Tue Feb 18 11:44:28 2025 From: andreasplesch at gmail.com (Andreas Plesch) Date: Tue, 18 Feb 2025 14:44:28 -0500 Subject: [x3d-public] HAnimDisplacer effect on coord.point In-Reply-To: References: <2eee59f2-28bb-9443-f1b8-9f25048d1283@earthlink.net> Message-ID: Please do not wait for x3dom. Both ProximitySensor and the Layering component are lower priority. HTML/SVG is better suited for 2D HUDs and layering can be approximated by stacking multiple X3D canvases/scenes. You may also consider XR where immersion typically strongly favors in-world 3d HUDs. Best, -Andreas On Tue, Feb 18, 2025 at 2:25?PM John Carlson wrote: > Don, we?re currently working on a HUD for Joe, I don?t currently have an > online example of that. > > Otherwise, I?m waiting on someone deciding which meshes to merge. I could > take the lead on this. > > I could use a tutorial on the Layering and Layout components, examples > don?t seem to help. I may try to adopt a 3D HUD based on examples. > Something with the 2D overlay in WORLD space would help tremendously, or > some conversion from WORLD space. > > We already have 3D menus, so a 3D HUD might be easiest. > > Thanks, > > John > On Mon, Feb 17, 2025 at 11:18?PM Brutzman, Donald (Don) (CIV) via > x3d-public wrote: > >> Wondering, do we have a simple excerpted example that we can look at >> yet? That will help guide these discussions. >> >> Don't need a full human body animation in all its displaceable glory... >> >> >> 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 >> https://faculty.nps.edu/brutzman >> >> >> >> ------------------------------ >> *From:* x3d-public on behalf of Joe D >> Williams via x3d-public >> *Sent:* Saturday, February 15, 2025 6:55 PM >> *To:* Holger Seelig ; Andreas Plesch < >> andreasplesch at gmail.com> >> *Cc:* joedwil at earthlink.net ; X3D < >> x3d-public at web3d.org>; Carol McDonald >> >> *Subject:* Re: [x3d-public] HAnimDisplacer effect on coord.point >> >> >> > coord.point changes are very very expensive quickly, >> >> >> >> Right, the processing time gets expensive as the number of points moved. >> >> If level 1 segment geometry where the mesh is driven directly by a joint, >> then it easier since weight is always 1. >> >> For level 2 skin, the the weight (radial movement) applied by maybe >> multiple joints needs to be computed for each point. >> >> Finally, for both levels, the displacements for selected set of points >> needs to be applied. >> >> This implies multiple passes on the subject coordinates? >> >> Whatever, these operations are common where the applications deal with >> >> a complete mesh and with sparse points of a mesh for blending. . >> >> >> >> > with reference to CoordinateInterpolator, >> >> >> >> These are useful when controlling all points of a target mesh. >> >> All points of a mesh must be included and same number of points at each >> keyframe. >> >> This style was used in first step of the current example x3d FACS because >> >> face geometry is made from multiple shapes. CoordinateInterpolater sets >> >> for each shape for each elemental action moved the points. >> >> This was simplified to using the same face for each action example >> >> and then replaced the CIs with sets of Displacers. >> >> Now have developed further to combine individual actions to make a >> >> specific expression which consists of multiple elemental movements. >> >> However, I think we want to evolve towards a basic single mesh face >> >> with some individual shapes for like teeth, hair, eyeballs, eyelids, >> tongue, maybe ears? >> >> and using joint nodes to control, where appropriate. >> >> >> >> Regardless of how the points are moved for the next frame, it has to be >> >> considered that geometry points will be moved directly by joint >> rotations, >> >> by a weighting algorithm using multiple joint rotation inputs, >> >> and by one or more scalar-driven Displacer inputs. >> >> >> >> Thanks for HAnim, >> >> Joe >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -----Message----- >> >> From: Holger Seelig >> Sent: Feb 9, 2025 11:23 AM >> To: Andreas Plesch >> Cc: X3D , Joseph D Williams , >> Carol McDonald >> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >> >> >> I don't think so, coord.point changes are very very expensive quickly, >> and as Michalis said earlier, with reference to CoordinateInterpolator, we >> should get rid of them. >> >> Holger >> -- >> Holger Seelig >> Leipzig, Germany >> >> holger.seelig at yahoo.de >> https://create3000.github.io/x_ite/ >> >> Am 09.02.2025 um 19:44 schrieb Andreas Plesch : >> Yes, that is an option. However,coord.point changes are very very >> expensive quickly, and as Michalis said earlier, with reference to >> CoordinateInterpolator, we should get rid of them. >> >> Andreas >> >> On Sun, Feb 9, 2025, 1:40?PM Holger Seelig >> wrote: >> >> X_ITE applies the HAnimDisplacers in the shader, thus no coord.point >> field has to be changed. >> Maybe that helps. >> >> Best regards, >> Holger >> >> -- >> Holger Seelig >> Leipzig, Germany >> >> holger.seelig at yahoo.de >> https://create3000.github.io/x_ite/ >> >> Am 09.02.2025 um 19:33 schrieb Andreas Plesch via x3d-public < >> x3d-public at web3d.org>: >> >> That would be the point field of a Coordinate node >> >> >> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/rendering.html#Coordinate >> >> which is used by the coord field of >> >> >> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimSegment >> >> Andreas >> >> On Sun, Feb 9, 2025, 12:36?PM Joe D Williams >> wrote: >> >> > coord node emit a point_changed event >> >> >> sorry,I don't see a field anywhere with that event. Displacer is likely >> to change several points when new weight is sent. All part of the cascade >> to produce the changed mesh? >> Thanks, >> Joe >> >> >> >> >> >> -----Original Message----- >> From: Andreas Plesch >> Sent: Feb 9, 2025 4:25 AM >> To: Brutzman, Donald (Don) (CIV) >> Cc: Extensible 3D (X3D) Graphics public discussion , >> Carol McDonald , Joe D Williams , >> John Carlson >> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >> >> >> Don, Joe and John >> >> Thanks for collecting these references. >> >> But I am not sure if there is an answer to my original question. Let me >> rephrase a bit the question: >> >> After a Displacer contained in a Segment node receives a set_weight >> input, should then the coord node emit a point_changed event ? >> >> I do not think HAnim is concerned about that, so it is really a X3D >> question. >> >> Thanks, Andreas >> >> On Sun, Feb 9, 2025, 12:49?AM Brutzman, Donald (Don) (CIV) < >> brutzman at nps.edu> wrote: >> >> Thanks for pointing in the right direction John. >> >> Direct links to functional requirements for Displacer in HAnim 2.0 >> specification: >> >> - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, >> Clause 4 Concepts, 4.7 Displacer object >> - >> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#DisplacerObject >> >> - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, >> Clause 6 Object interfaces, 6.6 Displacer >> - >> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer >> >> and >> >> - X3D 4.0 Architecture, Clause 26 Humanoid Animation (HAnim) >> component, 26.3.1 HAnimDisplacer >> - >> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimDisplacer >> >> and informative >> >> - X3D Tooltips, HAnimDisplacer >> - https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimDisplacer >> >> Thanks for implementation efforts and careful scrutiny. >> >> Questions and potential issues/clarifications/corrections are always >> welcome. >> >> >> 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 >> https://faculty.nps.edu/brutzman >> >> >> >> ------------------------------ >> *From:* x3d-public on behalf of John >> Carlson via x3d-public >> *Sent:* Saturday, February 8, 2025 3:43 AM >> *To:* Extensible 3D (X3D) Graphics public discussion < >> x3d-public at web3d.org>; Carol McDonald ; Joe D >> Williams >> *Cc:* John Carlson ; Andreas Plesch < >> andreasplesch at gmail.com> >> *Subject:* Re: [x3d-public] HAnimDisplacer effect on coord.point >> >> Here?s what HAnim spec says under Displacer: >> >> https://www.web3d.org/documents/specifications/19774/V2.0/index.html >> >> ?For the *Displacer* objects that are contained in the *displacers* field >> of the *Segment* objects, the *displacements* are defined and applied in >> the *Segment* coordinate system. The base mesh for the morphed *Segment* is >> the original mesh defined in the *Segment*.? >> >> And here?s what it says under Segment: >> >> ? >> >> The *coord* field is used for *Segment* objects that have deformable >> meshes and shall contain coordinates referenced from the indexed mesh for >> the *Segment* object. The coordinates are given the same name as the >> *Segment* object, but with a "_coords" appended (e.g.,"skull_coords").? >> displacements are an offset from the mesh, with weight from 0 to 1. So >> weight times displacement is total offset from base mesh. 0 weight = no >> offset, 1 weight = full displacements offset >> >> The Coordinate point is maintained to handle weight = 0. Weight ranges >> from 0 to 1, but double check. >> >> Joe or Carol might know where to find it in the HAnim spec. >> >> I believe the answer is, ?during rendering,?. Since weight can vary with >> animation, and so can displacements, AFAIK. More than one displacer can be >> applied to the mesh. >> >> I have not read the spec. >> >> John >> >> >> >> On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public < >> x3d-public at web3d.org> wrote: >> >> >> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer >> >> does not directly explain what the effect of the displacer on the >> coord.point field of the containing HAnimSegment is. But it mentions the >> coord.point field and seems to imply that the coord.point field is involved. >> >> So the question is if the Displacer should alter the coord.point field in >> order to achieve a graphical displacement, or if the Browser should only >> apply the displacements during rendering without a change in the >> coord.point field ? >> >> This is relevant if the coord.point field is accessed by routes or >> scripts, in addition to displacers. >> >> Thanks for any feedback or ideas, >> >> Andreas >> >> -- >> Andreas Plesch >> Waltham, MA 02453 >> _______________________________________________ >> x3d-public mailing list >> x3d-public at web3d.org >> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >> >> >> >> _______________________________________________ >> x3d-public mailing list >> x3d-public at web3d.org >> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >> >> >> _______________________________________________ >> x3d-public mailing list >> x3d-public at web3d.org >> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >> > -- Andreas Plesch Waltham, MA 02453 -------------- next part -------------- An HTML attachment was scrubbed... URL: From joedwil at earthlink.net Tue Feb 18 16:38:41 2025 From: joedwil at earthlink.net (Joe D Williams) Date: Wed, 19 Feb 2025 00:38:41 +0000 Subject: [x3d-public] HAnimDisplacer effect on coord.point Message-ID: > a HUD for Joe A hud for the FACS example is needed because any navigation causes the menu to disappear. The menu can be just like used on the Jin scaled with animation example. However that uses a ProximitySensor which x3dom does not support, for some reason. We use that a lot for start timers, timers, etc.as well as being the typical way to keep a menu or scene data in view. If HTML/SVG is better, I have not seen it. I don't think Stacking canvas is appropriate. Fine to think of XR for in-world 2d or3d HUDS but does that sort ofdisplay really work any different than using prox sensor? ProximitySensor is just so basic. rest of menu Thanks and Best, Joe huds3d XR -----Original Message----- From: Andreas Plesch Sent: Feb 18, 2025 11:45 AM To: John Carlson Cc: Extensible 3D (X3D) Graphics public discussion , Holger Seelig , Joseph D Williams , Brutzman, Donald (Don) (CIV) , Carol McDonald Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point Please do not wait for x3dom. Both ProximitySensor and the Layering component are lower priority. HTML/SVG is better suited for 2D HUDs and layering can be approximated by stacking multiple X3D canvases/scenes. You may also consider XR where immersion typically strongly favors in-world 3d HUDs. Best, -Andreas On Tue, Feb 18, 2025 at 2:25?PM John Carlson wrote: Don, we’re currently working on a HUD for Joe, I don’t currently have an online example of that. Otherwise, I’m waiting on someone deciding which meshes to merge. I could take the lead on this. I could use a tutorial on the Layering and Layout components, examples don’t seem to help. I may try to adopt a 3D HUD based on examples. Something with the 2D overlay in WORLD space would help tremendously, or some conversion from WORLD space. We already have 3D menus, so a 3D HUD might be easiest. Thanks, John On Mon, Feb 17, 2025 at 11:18?PM Brutzman, Donald (Don) (CIV) via x3d-public wrote: Wondering, do we have a simple excerpted example that we can look at yet? That will help guide these discussions. Don't need a full human body animation in all its displaceable glory... all the best, Don -- Don Brutzman Naval Postgraduate School, Code USW/Br brutzman at nps.edu (mailto:brutzman at nps.edu) Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149 X3D graphics, virtual worlds, navy robotics https://faculty.nps.edu/brutzman From: x3d-public on behalf of Joe D Williams via x3d-public Sent: Saturday, February 15, 2025 6:55 PM To: Holger Seelig ; Andreas Plesch Cc: joedwil at earthlink.net (mailto:joedwil at earthlink.net) ; X3D ; Carol McDonald Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point > coord.point changes are very very expensive quickly, Right, the processing time gets expensive as the number of points moved. If level 1 segment geometry where the mesh is driven directly by a joint, then it easier since weight is always 1. For level 2 skin, the the weight (radial movement) applied by maybe multiple joints needs to be computed for each point. Finally, for both levels, the displacements for selected set of points needs to be applied. This implies multiple passes on the subject coordinates? Whatever, these operations are common where the applications deal with a complete mesh and with sparse points of a mesh for blending. . > with reference to CoordinateInterpolator, These are useful when controlling all points of a target mesh. All points of a mesh must be included and same number of points at each keyframe. This style was used in first step of the current example x3d FACS because face geometry is made from multiple shapes. CoordinateInterpolater sets for each shape for each elemental action moved the points. This was simplified to using the same face for each action example and then replaced the CIs with sets of Displacers. Now have developed further to combine individual actions to make a specific expression which consists of multiple elemental movements. However, I think we want to evolve towards a basic single mesh face with some individual shapes for like teeth, hair, eyeballs, eyelids, tongue, maybe ears? and using joint nodes to control, where appropriate. Regardless of how the points are moved for the next frame, it has to be considered that geometry points will be moved directly by joint rotations, by a weighting algorithm using multiple joint rotation inputs, and by one or more scalar-driven Displacer inputs. Thanks for HAnim, Joe -----Message----- From: Holger Seelig Sent: Feb 9, 2025 11:23 AM To: Andreas Plesch Cc: X3D , Joseph D Williams , Carol McDonald Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point I don't think so, coord.point changes are very very expensive quickly, and as Michalis said earlier, with reference to CoordinateInterpolator, we should get rid of them. Holger-- Holger Seelig Leipzig, Germany holger.seelig at yahoo.de (mailto:holger.seelig at yahoo.de) https://create3000.github.io/x_ite/ Am 09.02.2025 um 19:44 schrieb Andreas Plesch : Yes, that is an option. However,coord.point changes are very very expensive quickly, and as Michalis said earlier, with reference to CoordinateInterpolator, we should get rid of them. Andreas On Sun, Feb 9, 2025, 1:40?PM Holger Seelig wrote: X_ITE applies the HAnimDisplacers in the shader, thus no coord.point field has to be changed.Maybe that helps. Best regards, Holger -- Holger Seelig Leipzig, Germany holger.seelig at yahoo.de (mailto:holger.seelig at yahoo.de) https://create3000.github.io/x_ite/ Am 09.02.2025 um 19:33 schrieb Andreas Plesch via x3d-public : That would be the point field of a Coordinate node https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/rendering.html#Coordinate which is used by the coord field of https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimSegment Andreas On Sun, Feb 9, 2025, 12:36?PM Joe D Williams wrote: > coord node emit a point_changed event sorry,I don't see a field anywhere with that event. Displacer is likely to change several points when new weight is sent. All part of the cascade to produce the changed mesh? Thanks, Joe -----Original Message----- From: Andreas Plesch Sent: Feb 9, 2025 4:25 AM To: Brutzman, Donald (Don) (CIV) Cc: Extensible 3D (X3D) Graphics public discussion , Carol McDonald , Joe D Williams , John Carlson Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point Don, Joe and John Thanks for collecting these references. But I am not sure if there is an answer to my original question. Let me rephrase a bit the question: After a Displacer contained in a Segment node receives a set_weight input, should then the coord node emit a point_changed event ? I do not think HAnim is concerned about that, so it is really a X3D question. Thanks, Andreas On Sun, Feb 9, 2025, 12:49?AM Brutzman, Donald (Don) (CIV) wrote: Thanks for pointing in the right direction John. Direct links to functional requirements for Displacer in HAnim 2.0 specification: * HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, Clause 4 Concepts, 4.7 Displacer object * https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#DisplacerObject * HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, Clause 6 Object interfaces, 6.6 Displacer * https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer and * X3D 4.0 Architecture, Clause 26 Humanoid Animation (HAnim) component, 26.3.1 HAnimDisplacer * https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimDisplacer and informative * X3D Tooltips, HAnimDisplacer * https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimDisplacer Thanks for implementation efforts and careful scrutiny. Questions and potential issues/clarifications/corrections are always welcome. all the best, Don -- Don Brutzman Naval Postgraduate School, Code USW/Br brutzman at nps.edu (mailto:brutzman at nps.edu) Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149 X3D graphics, virtual worlds, navy robotics https://faculty.nps.edu/brutzman From: x3d-public on behalf of John Carlson via x3d-public Sent: Saturday, February 8, 2025 3:43 AM To: Extensible 3D (X3D) Graphics public discussion ; Carol McDonald ; Joe D Williams Cc: John Carlson ; Andreas Plesch Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point Here’s what HAnim spec says under Displacer: https://www.web3d.org/documents/specifications/19774/V2.0/index.html “For the Displacer objects that are contained in the displacers field of the Segment objects, the displacements are defined and applied in the Segment coordinate system. The base mesh for the morphed Segment is the original mesh defined in the Segment.” And here’s what it says under Segment: “ The coord field is used for Segment objects that have deformable meshes and shall contain coordinates referenced from the indexed mesh for the Segment object. The coordinates are given the same name as the Segment object, but with a "_coords" appended (e.g.,"skull_coords").” displacements are an offset from the mesh, with weight from 0 to 1. So weight times displacement is total offset from base mesh. 0 weight = no offset, 1 weight = full displacements offset The Coordinate point is maintained to handle weight = 0. Weight ranges from 0 to 1, but double check. Joe or Carol might know where to find it in the HAnim spec. I believe the answer is, “during rendering,”. Since weight can vary with animation, and so can displacements, AFAIK. More than one displacer can be applied to the mesh. I have not read the spec. John On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public wrote: https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer does not directly explain what the effect of the displacer on the coord.point field of the containing HAnimSegment is. But it mentions the coord.point field and seems to imply that the coord.point field is involved. So the question is if the Displacer should alter the coord.point field in order to achieve a graphical displacement, or if the Browser should only apply the displacements during rendering without a change in the coord.point field ? This is relevant if the coord.point field is accessed by routes or scripts, in addition to displacers. Thanks for any feedback or ideas, Andreas -- Andreas Plesch Waltham, MA 02453 _______________________________________________ x3d-public mailing list x3d-public at web3d.org (mailto:x3d-public at web3d.org) http://web3d.org/mailman/listinfo/x3d-public_web3d.org _______________________________________________ x3d-public mailing list x3d-public at web3d.org (mailto:x3d-public at web3d.org) http://web3d.org/mailman/listinfo/x3d-public_web3d.org _______________________________________________ x3d-public mailing list x3d-public at web3d.org (mailto:x3d-public at web3d.org) http://web3d.org/mailman/listinfo/x3d-public_web3d.org -- Andreas Plesch Waltham, MA 02453 -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Tue Feb 18 16:49:42 2025 From: yottzumm at gmail.com (John Carlson) Date: Tue, 18 Feb 2025 18:49:42 -0600 Subject: [x3d-public] HAnimDisplacer effect on coord.point In-Reply-To: References: Message-ID: Thanks for code samples, Joe. It looks like I can take out my Layering/Layout code and just focus on the menu. Sorry I am so slow on this, I think I might be hibernating. I?m looking at my GitHub commits and they have dropped drastically. This might be because I am spending more time helping others with recovery or just using social media too much. I will try to get to the HUD in the next two days. It was so cold, we didn?t even go to the dentist 45 miles away. We got out today though. John On Tue, Feb 18, 2025 at 6:38?PM Joe D Williams wrote: > > a HUD for Joe > > > > A hud for the FACS example is needed because any navigation causes the > menu to disappear. The menu can be just like used on the Jin scaled with > animation example. However that uses a ProximitySensor which x3dom does not > support, for some reason. We use that a lot for start timers, timers, > etc.as well as being the typical way to keep a menu or scene data in > view. > > If HTML/SVG is better, I have not seen it. I don't think Stacking canvas > is appropriate. Fine to think of XR for in-world 2d or3d HUDS but does that > sort ofdisplay really work any different than using prox sensor? > ProximitySensor is just so basic. > > > > > > > > > > rest of menu > > toField='set_translation' toNode='HudXform'/> > toField='set_rotation' toNode='HudXform'/> > > > > Thanks and Best, > > Joe > > > > huds3d > > XR > > -----Original Message----- > From: Andreas Plesch > Sent: Feb 18, 2025 11:45 AM > To: John Carlson > Cc: Extensible 3D (X3D) Graphics public discussion , > Holger Seelig , Joseph D Williams < > joedwil at earthlink.net>, Brutzman, Donald (Don) (CIV) , > Carol McDonald > Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point > > > Please do not wait for x3dom. Both ProximitySensor and the Layering > component are lower priority. HTML/SVG is better suited for 2D HUDs and > layering can be approximated by stacking multiple X3D canvases/scenes. You > may also consider XR where immersion typically strongly favors in-world 3d > HUDs. > > Best, -Andreas > > On Tue, Feb 18, 2025 at 2:25?PM John Carlson wrote: > >> Don, we?re currently working on a HUD for Joe, I don?t currently have an >> online example of that. >> >> Otherwise, I?m waiting on someone deciding which meshes to merge. I >> could take the lead on this. >> >> I could use a tutorial on the Layering and Layout components, examples >> don?t seem to help. I may try to adopt a 3D HUD based on examples. >> Something with the 2D overlay in WORLD space would help tremendously, or >> some conversion from WORLD space. >> >> We already have 3D menus, so a 3D HUD might be easiest. >> >> Thanks, >> >> John >> On Mon, Feb 17, 2025 at 11:18?PM Brutzman, Donald (Don) (CIV) via >> x3d-public wrote: >> >>> Wondering, do we have a simple excerpted example that we can look at >>> yet? That will help guide these discussions. >>> >>> Don't need a full human body animation in all its displaceable glory... >>> >>> >>> >>> 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 >>> https://faculty.nps.edu/brutzman >>> >>> >>> >>> ------------------------------ >>> *From:* x3d-public on behalf of Joe D >>> Williams via x3d-public >>> *Sent:* Saturday, February 15, 2025 6:55 PM >>> *To:* Holger Seelig ; Andreas Plesch < >>> andreasplesch at gmail.com> >>> *Cc:* joedwil at earthlink.net ; X3D < >>> x3d-public at web3d.org>; Carol McDonald >>> >>> *Subject:* Re: [x3d-public] HAnimDisplacer effect on coord.point >>> >>> >>> > coord.point changes are very very expensive quickly, >>> >>> >>> >>> Right, the processing time gets expensive as the number of points moved. >>> >>> If level 1 segment geometry where the mesh is driven directly by a >>> joint, then it easier since weight is always 1. >>> >>> For level 2 skin, the the weight (radial movement) applied by maybe >>> multiple joints needs to be computed for each point. >>> >>> Finally, for both levels, the displacements for selected set of points >>> needs to be applied. >>> >>> This implies multiple passes on the subject coordinates? >>> >>> Whatever, these operations are common where the applications deal with >>> >>> a complete mesh and with sparse points of a mesh for blending. . >>> >>> >>> >>> > with reference to CoordinateInterpolator, >>> >>> >>> >>> These are useful when controlling all points of a target mesh. >>> >>> All points of a mesh must be included and same number of points at each >>> keyframe. >>> >>> This style was used in first step of the current example x3d FACS >>> because >>> >>> face geometry is made from multiple shapes. CoordinateInterpolater sets >>> >>> for each shape for each elemental action moved the points. >>> >>> This was simplified to using the same face for each action example >>> >>> and then replaced the CIs with sets of Displacers. >>> >>> Now have developed further to combine individual actions to make a >>> >>> specific expression which consists of multiple elemental movements. >>> >>> However, I think we want to evolve towards a basic single mesh face >>> >>> with some individual shapes for like teeth, hair, eyeballs, eyelids, >>> tongue, maybe ears? >>> >>> and using joint nodes to control, where appropriate. >>> >>> >>> >>> Regardless of how the points are moved for the next frame, it has to be >>> >>> considered that geometry points will be moved directly by joint >>> rotations, >>> >>> by a weighting algorithm using multiple joint rotation inputs, >>> >>> and by one or more scalar-driven Displacer inputs. >>> >>> >>> >>> Thanks for HAnim, >>> >>> Joe >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> -----Message----- >>> >>> From: Holger Seelig >>> Sent: Feb 9, 2025 11:23 AM >>> To: Andreas Plesch >>> Cc: X3D , Joseph D Williams , >>> Carol McDonald >>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>> >>> >>> I don't think so, coord.point changes are very very expensive quickly, >>> and as Michalis said earlier, with reference to CoordinateInterpolator, we >>> should get rid of them. >>> >>> Holger >>> -- >>> Holger Seelig >>> Leipzig, Germany >>> >>> holger.seelig at yahoo.de >>> https://create3000.github.io/x_ite/ >>> >>> Am 09.02.2025 um 19:44 schrieb Andreas Plesch : >>> Yes, that is an option. However,coord.point changes are very very >>> expensive quickly, and as Michalis said earlier, with reference to >>> CoordinateInterpolator, we should get rid of them. >>> >>> Andreas >>> >>> On Sun, Feb 9, 2025, 1:40?PM Holger Seelig >>> wrote: >>> >>> X_ITE applies the HAnimDisplacers in the shader, thus no coord.point >>> field has to be changed. >>> Maybe that helps. >>> >>> Best regards, >>> Holger >>> >>> -- >>> Holger Seelig >>> Leipzig, Germany >>> >>> holger.seelig at yahoo.de >>> https://create3000.github.io/x_ite/ >>> >>> Am 09.02.2025 um 19:33 schrieb Andreas Plesch via x3d-public < >>> x3d-public at web3d.org>: >>> >>> That would be the point field of a Coordinate node >>> >>> >>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/rendering.html#Coordinate >>> >>> which is used by the coord field of >>> >>> >>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimSegment >>> >>> Andreas >>> >>> On Sun, Feb 9, 2025, 12:36?PM Joe D Williams >>> wrote: >>> >>> > coord node emit a point_changed event >>> >>> >>> sorry,I don't see a field anywhere with that event. Displacer is likely >>> to change several points when new weight is sent. All part of the cascade >>> to produce the changed mesh? >>> Thanks, >>> Joe >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: Andreas Plesch >>> Sent: Feb 9, 2025 4:25 AM >>> To: Brutzman, Donald (Don) (CIV) >>> Cc: Extensible 3D (X3D) Graphics public discussion , >>> Carol McDonald , Joe D Williams < >>> joedwil at earthlink.net>, John Carlson >>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>> >>> >>> Don, Joe and John >>> >>> Thanks for collecting these references. >>> >>> But I am not sure if there is an answer to my original question. Let me >>> rephrase a bit the question: >>> >>> After a Displacer contained in a Segment node receives a set_weight >>> input, should then the coord node emit a point_changed event ? >>> >>> I do not think HAnim is concerned about that, so it is really a X3D >>> question. >>> >>> Thanks, Andreas >>> >>> On Sun, Feb 9, 2025, 12:49?AM Brutzman, Donald (Don) (CIV) < >>> brutzman at nps.edu> wrote: >>> >>> Thanks for pointing in the right direction John. >>> >>> Direct links to functional requirements for Displacer in HAnim 2.0 >>> specification: >>> >>> - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, >>> Clause 4 Concepts, 4.7 Displacer object >>> - >>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#DisplacerObject >>> >>> - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, >>> Clause 6 Object interfaces, 6.6 Displacer >>> - >>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer >>> >>> and >>> >>> - X3D 4.0 Architecture, Clause 26 Humanoid Animation (HAnim) >>> component, 26.3.1 HAnimDisplacer >>> - >>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimDisplacer >>> >>> and informative >>> >>> - X3D Tooltips, HAnimDisplacer >>> - https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimDisplacer >>> >>> Thanks for implementation efforts and careful scrutiny. >>> >>> Questions and potential issues/clarifications/corrections are always >>> welcome. >>> >>> >>> 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 >>> https://faculty.nps.edu/brutzman >>> >>> >>> >>> ------------------------------ >>> *From:* x3d-public on behalf of John >>> Carlson via x3d-public >>> *Sent:* Saturday, February 8, 2025 3:43 AM >>> *To:* Extensible 3D (X3D) Graphics public discussion < >>> x3d-public at web3d.org>; Carol McDonald ; Joe D >>> Williams >>> *Cc:* John Carlson ; Andreas Plesch < >>> andreasplesch at gmail.com> >>> *Subject:* Re: [x3d-public] HAnimDisplacer effect on coord.point >>> >>> Here?s what HAnim spec says under Displacer: >>> >>> https://www.web3d.org/documents/specifications/19774/V2.0/index.html >>> >>> ?For the *Displacer* objects that are contained in the *displacers* field >>> of the *Segment* objects, the *displacements* are defined and applied >>> in the *Segment* coordinate system. The base mesh for the morphed >>> *Segment* is the original mesh defined in the *Segment*.? >>> >>> And here?s what it says under Segment: >>> >>> ? >>> >>> The *coord* field is used for *Segment* objects that have deformable >>> meshes and shall contain coordinates referenced from the indexed mesh for >>> the *Segment* object. The coordinates are given the same name as the >>> *Segment* object, but with a "_coords" appended (e.g.,"skull_coords").? >>> displacements are an offset from the mesh, with weight from 0 to 1. So >>> weight times displacement is total offset from base mesh. 0 weight = no >>> offset, 1 weight = full displacements offset >>> >>> The Coordinate point is maintained to handle weight = 0. Weight ranges >>> from 0 to 1, but double check. >>> >>> Joe or Carol might know where to find it in the HAnim spec. >>> >>> I believe the answer is, ?during rendering,?. Since weight can vary with >>> animation, and so can displacements, AFAIK. More than one displacer can be >>> applied to the mesh. >>> >>> I have not read the spec. >>> >>> John >>> >>> >>> >>> On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public < >>> x3d-public at web3d.org> wrote: >>> >>> >>> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer >>> >>> does not directly explain what the effect of the displacer on the >>> coord.point field of the containing HAnimSegment is. But it mentions the >>> coord.point field and seems to imply that the coord.point field is involved. >>> >>> So the question is if the Displacer should alter the coord.point field >>> in order to achieve a graphical displacement, or if the Browser should only >>> apply the displacements during rendering without a change in the >>> coord.point field ? >>> >>> This is relevant if the coord.point field is accessed by routes or >>> scripts, in addition to displacers. >>> >>> Thanks for any feedback or ideas, >>> >>> Andreas >>> >>> -- >>> Andreas Plesch >>> Waltham, MA 02453 >>> _______________________________________________ >>> x3d-public mailing list >>> x3d-public at web3d.org >>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>> >>> >>> >>> _______________________________________________ >>> x3d-public mailing list >>> x3d-public at web3d.org >>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>> >>> >>> _______________________________________________ >>> x3d-public mailing list >>> x3d-public at web3d.org >>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >> >> > > -- > Andreas Plesch > Waltham, MA 02453 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreasplesch at gmail.com Wed Feb 19 06:50:27 2025 From: andreasplesch at gmail.com (Andreas Plesch) Date: Wed, 19 Feb 2025 09:50:27 -0500 Subject: [x3d-public] SFRotation default value spec. inconsistency In-Reply-To: References: Message-ID: On Tue, Feb 18, 2025 at 10:16?AM Joe D Williams wrote: > > ... may prefer the equivalent zero-rotation default value *0 1 0 0* > > .. > > Thanks Don. So the Transform rotation and Viewpoint orientation > > and any other use of rotation and orientation are treated as > > default zero when angle is zero, or, if all x, y, and z are zero. > Just a caution that - https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/fieldTypes.html#SFRotationAndMFRotation says "The first three values specify a normalized rotation axis vector". So x,y,z all zero is not a valid (illegal) SFRotation value. -Andreas > > > -----Original Message----- > From: Brutzman, Donald (Don) (CIV) > Sent: Feb 17, 2025 9:08 PM > To: Andreas Plesch , Joseph D Williams < > joedwil at earthlink.net> > Cc: Extensible 3D (X3D) Graphics public discussion > Subject: Re: [x3d-public] SFRotation default value spec. inconsistency > > > Thanks for discussion and for noticing the difference. Related references: > > - 19777-1 X3D ECMAScript language binding, clause 7 Function > definitions, 7.6.6 SFRotation > - > https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#SFRotation > - Table 7.18 ? SFRotation instance creation functions > - > SFRotation > (numeric x, > numeric y, > numeric z, > numeric angle) > x, y, and z are the axis of the rotation. angle is the angle of the > rotation (in radians). Missing values default to 0.0, except y, which > defaults to 1.0. > > - X3D Architecture, clause 5 Field type reference, 5.3.13 SFRotation > and MFRotation > - > https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/fieldTypes.html#SFRotationAndMFRotation > - "The default value of an uninitialized SFRotation field is (0 0 1 > 0). The default value of an MFRotation field is the empty list." > > Yes they must be the same, so that X3D models are equivalent no matter > what file encoding or programming-language binding are used. > > The X3D Architecture takes precedence. So we will change 19777-1 to match > and the highlighted y above will become z. > > I too think that a default of (0 1 0 0) makes more sense, animation > rotations are most often around the vertical (y) axis. However, the > community has discussed this many times over the years. We always landed > on (0 0 1 0) for backwards-compatibility reasons, not wanting to break > legacy X3D and VRML models. > > Incidentally here is the X3D tooltips entry. Improvements and refinements > always welcome. > > - X3D Tooltips: SFRotation > - https://www.web3d.org/x3d/tooltips/X3dTooltips.html#SFRotation > - > SFRotation > > Single-Field rotation value using 3-tuple axis, radian angle form > Default value *0 0 1 0*. Model authors and authoring tools may prefer > the equivalent zero-rotation default value *0 1 0 0* since rotation > about the vertical Y-axis is most common. Example values: 0 1 0 1.57 > *Warning:* initial 3-tuple axis vector cannot hold a zero-magnitude > vector. > *Warning:* comma characters within attribute values are not allowed, > and do not pass strict validation. > *Hint:* see Wikipedia: Radian , Rotation > matrix and Rotation > formalisms in three dimensions > > . > XML Schema > , > X3D regexes > , > Java SAI > , > X3DJ > > > > To keep track of this erratum, I have entered a new issue in the Mantis > issue tracker. > > - Mantis 1488: (ECMAScript) 7.6.6 SFRotation default value needs to be > (0 0 1 0) > - https://mantis.web3d.org/view.php?id=1488 > > I hope this make sense and sounds good. > > Have fun with X3D - or else!! ? > > > > 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 > https://faculty.nps.edu/brutzman > > > > ------------------------------ > *From:* x3d-public on behalf of Joe D > Williams via x3d-public > *Sent:* Sunday, February 16, 2025 9:09 AM > *To:* Andreas Plesch > *Cc:* joedwil at earthlink.net ; X3D < > x3d-public at web3d.org> > *Subject:* Re: [x3d-public] SFRotation default value spec. inconsistency > > > > I would vote for 0 1 0 0 since rotations around Y seem more common > > > > First,oldest use is in Part 1, way back to origin of VRML standard. > > Is Yaw really more popular or common than Pitch or Roll? > > For me, Please let's stick with oldest history and update more recent. > > Thanks > > Joe > > > > > > -----Original Message----- > From: Andreas Plesch > Sent: Feb 15, 2025 9:12 PM > To: > Cc: Holger Seelig , X3D > Subject: Re: [x3d-public] SFRotation default value spec. inconsistency > > > I agree, probably the best default value for a unit quaternion is 0 0 0 1. > > However, X3D does not concern itself with quaternions, only axis-angle > rotations. > > So the original question remains: Part 1 has axis-angle 0 0 1 0 as default > while the JS SAI spec. has 0 1 0 0. Should both list the same default value > ? > > If yes, which one ? I would vote for 0 1 0 0 since rotations around Y seem > more common. > > -Andreas > > On Sat, Feb 15, 2025 at 11:04?PM wrote: > > Doesn't this mean that the _best_ default value, for no rotation, is > 'legally' for unit quaternion = 0 0 0 1 > > because the square root of the sum of the squares of all four components > does = 1 ? > > 0 0 0 0 would not be a legal unit quaternion. > > While the axis-angle default is 0 0 1 0 as appears in Part 1 is mostly for > convenience > > since many value combinations can produce zero rotation? > > Also sure shows why axis-angle is so much easier to work with when typing > numbers, > > pitch and yaw and roll for all. > > Thanks, > > Joe > > > > -----Original Message----- > From: Andreas Plesch > Sent: Feb 14, 2025 11:36 AM > To: Holger Seelig > Cc: X3D , Joseph D Williams > Subject: Re: [x3d-public] SFRotation default value spec. inconsistency > > > Let me just add for clarity that the length (or norm) of a quaternion > includes the fourth, the scalar component. The norm is the square root of > the sum of the squares of all four components. > > Only unit quaternions represent rotations. A (0,0,0,0) quaternion does not > represent any rotation (but of course exists outside of rotations). > > Andreas > > PS: To add back in some fuzziness, a unit quaternion can only represent a > rotation up to 360 degrees. I think there is a mechanism to use non-unit > quaternions for larger rotations. > > On Fri, Feb 14, 2025 at 10:22?AM Holger Seelig > wrote: > > All quaternions must be normalized to be a legal rotation, so the length > of the quaternion must always be one. > > Holger > -- > Holger Seelig > Leipzig, Germany > > holger.seelig at yahoo.de > https://create3000.github.io/x_ite/ > > Am 14.02.2025 um 15:38 schrieb Joe D Williams via x3d-public < > x3d-public at web3d.org>: > > > So, sensibly, a zero rotation around any axis corresponds to the "zero > unit Quaternion" (0, 0, 0, 1 XYZW), > > > Right. Not sure but 0 0 0 0 for unit quaternion might not be legal. I > think the values must compute to1 to be legal? > Thanks, > Joe > > > > > > -----Original Message----- > From: Andreas Plesch > Sent: Feb 10, 2025 12:37 PM > To: Joe D Williams > Cc: Extensible 3D (X3D) Graphics public discussion > Subject: Re: [x3d-public] SFRotation default value spec. inconsistency > > > https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#_node_rotation > has indeed (0, 0, 0, 1 XYZW) as a default value. > > This is difficult to interpret as a rotation around an axis since the > corresponding axis would be at first glance (0 0 0). > > x3dom converts quaternion (0, 0, 0, 1 XYZW) to (axis),angle (0,0,0),0 as > does https://www.andre-gaschler.com/rotationconverter/ . > > On the other hand both SFRotation (0 0 1 0) and SFRotation (0 1 0 0) are > also represented by quaternion (0, 0, 0, 1 XYZW). > > So, sensibly, a zero rotation around any axis corresponds to the "zero > unit Quaternion" (0, 0, 0, 1 XYZW), making it a useful default value for > quaternions. But that does not help with choosing a default axis for the > SFRotation value. > > This will rarely matter. A use case may be when a SFRotation is > initialized to the X3D default in a Proto but then only the angle is > modified by a Proto script with the assumption that the axis is (0 0 1). > > -Andreas > > On Mon, Feb 10, 2025 at 12:57?PM Joe D Williams > wrote: > > not zerp, zero > > -----Original Message----- > From: Extensible 3D (X3D) Graphics public discussion > > Sent: Feb 10, 2025 9:50 AM > To: Extensible 3D (X3D) Graphics public discussion , > X3D Graphics public mailing list > Cc: Joe D Williams , Andreas Plesch < > andreasplesch at gmail.com> > Subject: Re: [x3d-public] SFRotation default value spec. inconsistency > > > I think the 0 0 1 0 should be used everywhere for default axis-angle. > I thinkI see 'zerp' unit quaternions (as in gltf as 0 0 0 1 XYZW) > Thanks, > Joe > > > > -----Original Message----- > From: Extensible 3D (X3D) Graphics public discussion > > Sent: Feb 10, 2025 8:44 AM > To: X3D Graphics public mailing list > Cc: Andreas Plesch > Subject: Re: [x3d-public] SFRotation default value spec. inconsistency > > > The JS SAI spec. at > https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#FieldServices > > does not list functions for SFColorRGBA, only SFColor. There may be an > earlier report. -Andreas > > On Mon, Feb 10, 2025 at 11:31?AM Andreas Plesch > wrote: > > > https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/fieldTypes.html#SFRotationAndMFRotation > > specifies that (0 0 1 0) is the value of an uninitialized SFRotation given > as (x y z a). > > However, the JS SAI spec. in table 7.18 in > https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#SFRotationInstanceCreationFunction > > effectively makes (0 1 0 0) the default value if no parameters are > provided. > > The inconsistency does not have much of an impact since both are 0 > rotations but I believe (0 1 0 0) - a 0 rotation around y - may have been > intended as the default. > > -Andreas > > -- > Andreas Plesch > Waltham, MA 02453 > > > > -- > Andreas Plesch > Waltham, MA 02453 > > > > > > > > -- > Andreas Plesch > Waltham, MA 02453 > > > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > > > > -- > Andreas Plesch > Waltham, MA 02453 > > > > > > -- > Andreas Plesch > Waltham, MA 02453 > > > > > -- Andreas Plesch Waltham, MA 02453 -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Wed Feb 19 08:10:44 2025 From: yottzumm at gmail.com (John Carlson) Date: Wed, 19 Feb 2025 10:10:44 -0600 Subject: [x3d-public] SFRotation default value spec. inconsistency In-Reply-To: References: Message-ID: Yes, that was the point I was trying to make with 0 0 0 not being an axis or normalized. Thanks for backup. On Wed, Feb 19, 2025 at 8:51?AM Andreas Plesch via x3d-public < x3d-public at web3d.org> wrote: > On Tue, Feb 18, 2025 at 10:16?AM Joe D Williams > wrote: > >> > ... may prefer the equivalent zero-rotation default value *0 1 0 0* >> >> .. >> >> Thanks Don. So the Transform rotation and Viewpoint orientation >> >> and any other use of rotation and orientation are treated as >> >> default zero when angle is zero, or, if all x, y, and z are zero. >> > > Just a caution that > > > - > https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/fieldTypes.html#SFRotationAndMFRotation > > > says "The first three values specify a normalized rotation axis vector". > So x,y,z all zero is not a valid (illegal) SFRotation value. > > -Andreas > > >> >> >> -----Original Message----- >> From: Brutzman, Donald (Don) (CIV) >> Sent: Feb 17, 2025 9:08 PM >> To: Andreas Plesch , Joseph D Williams < >> joedwil at earthlink.net> >> Cc: Extensible 3D (X3D) Graphics public discussion >> Subject: Re: [x3d-public] SFRotation default value spec. inconsistency >> >> >> Thanks for discussion and for noticing the difference. Related >> references: >> >> - 19777-1 X3D ECMAScript language binding, clause 7 Function >> definitions, 7.6.6 SFRotation >> - >> https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#SFRotation >> - Table 7.18 ? SFRotation instance creation functions >> - >> SFRotation >> (numeric x, >> numeric y, >> numeric z, >> numeric angle) >> x, y, and z are the axis of the rotation. angle is the angle of the >> rotation (in radians). Missing values default to 0.0, except y, which >> defaults to 1.0. >> >> - X3D Architecture, clause 5 Field type reference, 5.3.13 SFRotation >> and MFRotation >> - >> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/fieldTypes.html#SFRotationAndMFRotation >> - "The default value of an uninitialized SFRotation field is (0 0 1 >> 0). The default value of an MFRotation field is the empty list." >> >> Yes they must be the same, so that X3D models are equivalent no matter >> what file encoding or programming-language binding are used. >> >> The X3D Architecture takes precedence. So we will change 19777-1 to >> match and the highlighted y above will become z. >> >> I too think that a default of (0 1 0 0) makes more sense, animation >> rotations are most often around the vertical (y) axis. However, the >> community has discussed this many times over the years. We always landed >> on (0 0 1 0) for backwards-compatibility reasons, not wanting to break >> legacy X3D and VRML models. >> >> Incidentally here is the X3D tooltips entry. Improvements and >> refinements always welcome. >> >> - X3D Tooltips: SFRotation >> - https://www.web3d.org/x3d/tooltips/X3dTooltips.html#SFRotation >> - >> SFRotation >> >> Single-Field rotation value using 3-tuple axis, radian angle form >> Default value *0 0 1 0*. Model authors and authoring tools may prefer >> the equivalent zero-rotation default value *0 1 0 0* since rotation >> about the vertical Y-axis is most common. Example values: 0 1 0 1.57 >> *Warning:* initial 3-tuple axis vector cannot hold a zero-magnitude >> vector. >> *Warning:* comma characters within attribute values are not allowed, >> and do not pass strict validation. >> *Hint:* see Wikipedia: Radian , Rotation >> matrix and Rotation >> formalisms in three dimensions >> >> . >> XML Schema >> , >> X3D regexes >> , >> Java SAI >> , >> X3DJ >> >> >> >> To keep track of this erratum, I have entered a new issue in the Mantis >> issue tracker. >> >> - Mantis 1488: (ECMAScript) 7.6.6 SFRotation default value needs to >> be (0 0 1 0) >> - https://mantis.web3d.org/view.php?id=1488 >> >> I hope this make sense and sounds good. >> >> Have fun with X3D - or else!! ? >> >> >> >> 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 >> https://faculty.nps.edu/brutzman >> >> >> >> ------------------------------ >> *From:* x3d-public on behalf of Joe D >> Williams via x3d-public >> *Sent:* Sunday, February 16, 2025 9:09 AM >> *To:* Andreas Plesch >> *Cc:* joedwil at earthlink.net ; X3D < >> x3d-public at web3d.org> >> *Subject:* Re: [x3d-public] SFRotation default value spec. inconsistency >> >> >> > I would vote for 0 1 0 0 since rotations around Y seem more common >> >> >> >> First,oldest use is in Part 1, way back to origin of VRML standard. >> >> Is Yaw really more popular or common than Pitch or Roll? >> >> For me, Please let's stick with oldest history and update more recent. >> >> Thanks >> >> Joe >> >> >> >> >> >> -----Original Message----- >> From: Andreas Plesch >> Sent: Feb 15, 2025 9:12 PM >> To: >> Cc: Holger Seelig , X3D >> Subject: Re: [x3d-public] SFRotation default value spec. inconsistency >> >> >> I agree, probably the best default value for a unit quaternion is 0 0 0 1. >> >> However, X3D does not concern itself with quaternions, only axis-angle >> rotations. >> >> So the original question remains: Part 1 has axis-angle 0 0 1 0 as >> default while the JS SAI spec. has 0 1 0 0. Should both list the same >> default value ? >> >> If yes, which one ? I would vote for 0 1 0 0 since rotations around Y >> seem more common. >> >> -Andreas >> >> On Sat, Feb 15, 2025 at 11:04?PM wrote: >> >> Doesn't this mean that the _best_ default value, for no rotation, is >> 'legally' for unit quaternion = 0 0 0 1 >> >> because the square root of the sum of the squares of all four components >> does = 1 ? >> >> 0 0 0 0 would not be a legal unit quaternion. >> >> While the axis-angle default is 0 0 1 0 as appears in Part 1 is mostly >> for convenience >> >> since many value combinations can produce zero rotation? >> >> Also sure shows why axis-angle is so much easier to work with when typing >> numbers, >> >> pitch and yaw and roll for all. >> >> Thanks, >> >> Joe >> >> >> >> -----Original Message----- >> From: Andreas Plesch >> Sent: Feb 14, 2025 11:36 AM >> To: Holger Seelig >> Cc: X3D , Joseph D Williams >> Subject: Re: [x3d-public] SFRotation default value spec. inconsistency >> >> >> Let me just add for clarity that the length (or norm) of a quaternion >> includes the fourth, the scalar component. The norm is the square root of >> the sum of the squares of all four components. >> >> Only unit quaternions represent rotations. A (0,0,0,0) quaternion does >> not represent any rotation (but of course exists outside of rotations). >> >> Andreas >> >> PS: To add back in some fuzziness, a unit quaternion can only represent a >> rotation up to 360 degrees. I think there is a mechanism to use non-unit >> quaternions for larger rotations. >> >> On Fri, Feb 14, 2025 at 10:22?AM Holger Seelig >> wrote: >> >> All quaternions must be normalized to be a legal rotation, so the length >> of the quaternion must always be one. >> >> Holger >> -- >> Holger Seelig >> Leipzig, Germany >> >> holger.seelig at yahoo.de >> https://create3000.github.io/x_ite/ >> >> Am 14.02.2025 um 15:38 schrieb Joe D Williams via x3d-public < >> x3d-public at web3d.org>: >> >> > So, sensibly, a zero rotation around any axis corresponds to the "zero >> unit Quaternion" (0, 0, 0, 1 XYZW), >> >> >> Right. Not sure but 0 0 0 0 for unit quaternion might not be legal. I >> think the values must compute to1 to be legal? >> Thanks, >> Joe >> >> >> >> >> >> -----Original Message----- >> From: Andreas Plesch >> Sent: Feb 10, 2025 12:37 PM >> To: Joe D Williams >> Cc: Extensible 3D (X3D) Graphics public discussion >> Subject: Re: [x3d-public] SFRotation default value spec. inconsistency >> >> >> https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#_node_rotation >> has indeed (0, 0, 0, 1 XYZW) as a default value. >> >> This is difficult to interpret as a rotation around an axis since the >> corresponding axis would be at first glance (0 0 0). >> >> x3dom converts quaternion (0, 0, 0, 1 XYZW) to (axis),angle (0,0,0),0 as >> does https://www.andre-gaschler.com/rotationconverter/ . >> >> On the other hand both SFRotation (0 0 1 0) and SFRotation (0 1 0 0) are >> also represented by quaternion (0, 0, 0, 1 XYZW). >> >> So, sensibly, a zero rotation around any axis corresponds to the "zero >> unit Quaternion" (0, 0, 0, 1 XYZW), making it a useful default value for >> quaternions. But that does not help with choosing a default axis for the >> SFRotation value. >> >> This will rarely matter. A use case may be when a SFRotation is >> initialized to the X3D default in a Proto but then only the angle is >> modified by a Proto script with the assumption that the axis is (0 0 1). >> >> -Andreas >> >> On Mon, Feb 10, 2025 at 12:57?PM Joe D Williams >> wrote: >> >> not zerp, zero >> >> -----Original Message----- >> From: Extensible 3D (X3D) Graphics public discussion < >> x3d-public at web3d.org> >> Sent: Feb 10, 2025 9:50 AM >> To: Extensible 3D (X3D) Graphics public discussion , >> X3D Graphics public mailing list >> Cc: Joe D Williams , Andreas Plesch < >> andreasplesch at gmail.com> >> Subject: Re: [x3d-public] SFRotation default value spec. inconsistency >> >> >> I think the 0 0 1 0 should be used everywhere for default axis-angle. >> I thinkI see 'zerp' unit quaternions (as in gltf as 0 0 0 1 XYZW) >> Thanks, >> Joe >> >> >> >> -----Original Message----- >> From: Extensible 3D (X3D) Graphics public discussion < >> x3d-public at web3d.org> >> Sent: Feb 10, 2025 8:44 AM >> To: X3D Graphics public mailing list >> Cc: Andreas Plesch >> Subject: Re: [x3d-public] SFRotation default value spec. inconsistency >> >> >> The JS SAI spec. at >> https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#FieldServices >> >> does not list functions for SFColorRGBA, only SFColor. There may be an >> earlier report. -Andreas >> >> On Mon, Feb 10, 2025 at 11:31?AM Andreas Plesch >> wrote: >> >> >> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/fieldTypes.html#SFRotationAndMFRotation >> >> specifies that (0 0 1 0) is the value of an uninitialized SFRotation >> given as (x y z a). >> >> However, the JS SAI spec. in table 7.18 in >> https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#SFRotationInstanceCreationFunction >> >> effectively makes (0 1 0 0) the default value if no parameters are >> provided. >> >> The inconsistency does not have much of an impact since both are 0 >> rotations but I believe (0 1 0 0) - a 0 rotation around y - may have been >> intended as the default. >> >> -Andreas >> >> -- >> Andreas Plesch >> Waltham, MA 02453 >> >> >> >> -- >> Andreas Plesch >> Waltham, MA 02453 >> >> >> >> >> >> >> >> -- >> Andreas Plesch >> Waltham, MA 02453 >> >> >> _______________________________________________ >> x3d-public mailing list >> x3d-public at web3d.org >> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >> >> >> >> -- >> Andreas Plesch >> Waltham, MA 02453 >> >> >> >> >> >> -- >> Andreas Plesch >> Waltham, MA 02453 >> >> >> >> >> > > > -- > Andreas Plesch > Waltham, MA 02453 > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brutzman at nps.edu Wed Feb 19 08:39:39 2025 From: brutzman at nps.edu (Brutzman, Donald (Don) (CIV)) Date: Wed, 19 Feb 2025 16:39:39 +0000 Subject: [x3d-public] [x3d] Spec Comment by on 19776-2: ClassicVRML Encoding - V4.0: improved string grammar In-Reply-To: References: Message-ID: Vince, thanks for your feedback on the X3D specification. -- Submitter indicates that this comment may be public: *Yes* -- [cc: x3d-public] I have entered your feedback in our Mantis tracking system. * Mantis 1489: potential grammar improvement to SFString for special characters * https://mantis.web3d.org/view.php?id=1489 To facilitate review and comment, I have also added it to the current draft 4.0 specification. * X3D ClassicVRML Encoding, Annex A (normative) Grammar, A.4 Fields * https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19776-2v4.0-WD1/Part02/grammar.html#Fields * Github specification source * https://github.com/Web3DConsortium/X3D/blob/master/ISO-IEC19776/ISO-IEC19776-2/ISO-IEC19776-2v4.0/ISO-IEC19776-2v4.0-WD1/Part02/grammar.html Of note is that we have a dozen pending changes to the Classic grammar. These are tracked together in a coordinated fashion using a "choreography" issue. * Mantis 1483: Grammar annex issues (choreography) * https://mantis.web3d.org/view.php?id=1483 ====================================== * Grammar annex includes a number of problems. * https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19776-2v4.0-WD1/Part02/grammar.html a. Much missing whitespace - fixed. b. [PERL] is no longer an authoritative reference and should be removed from the Bibliography. c. The actual syntax appears to be a variation of Extended Backus-Naur Form (EBNF). - ISO/IEC 14997 https://www.iso.org/standard/26153.html (then ITTF website) - https://en.wikipedia.org/wiki/Extended_Backus%E2%80%93Naur_form d. In order for production rules to match EBNF grammar syntax, the construct := should likely be the definition symbol = instead. e. Some informal inconsistencies can be found in the grammar, for example IdFirstChar::= Any ISO-10646 character encoded using UTF-8 except: 0x30-0x3a, 0x0-0x20, 0x22, 0x23, 0x27, 0x2b, 0x2c, 0x2d, 0x2e, 0x5b, 0x5c, 0x5d, 0x7b, 0x7d, 0x7f ; IdRestChars::= Any number of ISO-10646 characters except: 0x0-0x20, 0x22, 0x23, 0x27, 0x2c, 0x2e, 0x3a, 0x5b, 0x5c, 0x5d, 0x7b, 0x7d, 0x7f ; f. Do each of the node names and field names need to be defined? g. The grammar and bibliographic references need to appear at appropriate places in the rest of the document. * Can this grammar be validated using a software tool? * EBNF Evaluator https://mdkrajnak.github.io/ebnftest * EBNF Visualizer http://dotnet.jku.at/applications/Visualizer * ebnf parsing library https://github.com/pedroreissantos/bnf * BNF (EBNF) Playground https://bnfplayground.pauliankline.com Note concerns in * David A. Wheeler, Don?t Use ISO/IEC 14977:1996 Extended Backus-Naur Form (EBNF) * https://dwheeler.com/essays/dont-use-iso-14977-ebnf.html If we do achieve a validatable EBNF grammar, both forms will need to be carefully compared. Conceivably both prior VRML-style grammar and updated EBNF grammar might both be included. ====================================== I just cleaned up much HTML in there too. Careful scrutiny and all comments are welcome. Patient persistent pays, and valid content is king. These principles were collectively adopted by the community at the first Web3D Conference in 2025. We are working atop a tall pile of treasure. Have fun with X3D! ? 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 https://faculty.nps.edu/brutzman ________________________________ From: x3d on behalf of Spec Feedback Sent: Tuesday, February 18, 2025 6:50 PM To: x3d at web3d.org Subject: [x3d] Spec Comment by on 19776-2: ClassicVRML Encoding - V3.3 -- Submitter indicates that this comment may be public: *Yes* -- Comment on 19776-2: ClassicVRML Encoding - V3.3 Annex A : Grammar https://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/grammar.html ----------------- I propose that for V 4.0 of the VRML encoding the grammar for sfstringValue be defined more explicitly, in the same notation as the other grammer definitions. I propose 3 additional syntax elements defining single-character elements BackslashChar ::= 0x5c QuoteChar ::= 0x22 NonEscapedChar ::= Any ISO-10646 character except : BackslashChar , QuoteChar -- alternate syntax -- NonEscapedChar ::= [^\"] and the existing grammar for sfstringValue be replaced with sfStringValue ::= QuoteChar ((BackslashChar QuoteChar)|(BackslashChar BackslashChar)|NonEscapedChar)* QuoteChar No change is necessary for sfstringValues , mfstringValue ----------------- Submitted on Tuesday, 2025, February 18 - 6:50pm by (Vincent Marchetti ) IP: 76.34.206.177 See: https://www.web3d.org/node/1694/submission/12439 _______________________________________________ x3d mailing list x3d at web3d.org http://web3d.org/mailman/listinfo/x3d_web3d.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From joedwil at earthlink.net Wed Feb 19 12:15:05 2025 From: joedwil at earthlink.net (Joe D Williams) Date: Wed, 19 Feb 2025 20:15:05 +0000 Subject: [x3d-public] [X3D-Ecosystem] X3DOM/X_ITE/Castle Content Preview in RawKee X3D Exporter for Maya Message-ID: > standard set of functions, perhaps DOM The DOM and its interfaces continue to evolve to make it more 'alive' and competent for realtime interactive simulations. Like the X3D SAI the DOM has enough power to implement a realtime fully validating authoring system. Both the DOM and SAI can coexist beside or embedded in one another. The DOM is represented as a tree; X3D is presented as a DAG with multiple roots and hierarchy of namespaces. Just that the X3D SAI has certain runtime advantages. These are mainly derived from the idea that SAI is conceived as a realtime/anytime, internally/externally scriptable, prototypable, validatable process with both declarative and imperative aspects presented human-readable form. In addition, X3D runtime is both time and internal/external event-driven and fully documents frame-by-frame event flows as the scene progresses. X3D is basically the xmlized version of VRML but can be produced in most any language, including ecmascript, java, json, etc. So all is great. The X3D scenegraph can be represented as inline code interspersed with the html and use mainly DOM runtime, or run directly using SAI contained by Canvas, or run independently directly in the OS as a 3D web browser. As real 3D interactive support improves in current WWW browsers and evolves toward metaversal experiences, the value and versatility of X3D will increase. > Qt WebChannel Look around, maybe a way to do HUDs and control panels, but lots of licensing involved? Thanks, Joe -----Original Message----- From: X3D Ecosystem public discussion Sent: Feb 19, 2025 9:25 AM To: Bergstrom, Aaron Cc: John Carlson , X3D Ecosystem public discussion Subject: Re: [X3D-Ecosystem] X3DOM/X_ITE/Castle Content Preview in RawKee X3D Exporter for Maya To understand where I’m coming from, read the link, which includes: “ Qt WebChannel enables peer-to-peer communication between a server (QML/Python application) and a client (HTML/JavaScript or QML application). It is supported out of the box by Qt WebEngine . In addition it can work on all browsers that support WebSockets , enabling Qt WebChannel clients to run in any JavaScript environment (including QML). This requires the implementation of a custom transport based on Qt WebSockets. “ So I see client/server and websockets and I think JSONverse and socket.io (http://socket.io). AFAIK, there’s no X3D standard which includes websockets. But it seems like you’re more about a standard set of functions, perhaps DOM, which is common across all JS browsers. I don’t know if there’s an X3D DOM standard, but I suspect the best place to look is the XML encoding. John On Tue, Feb 18, 2025 at 2:48?PM Bergstrom, Aaron wrote: John, I think we are talking about two different things. What you’ve described sounds very complex and is not what I had in mind. So I apologize if I gave the impression that I was looking to recreate the DIS, EAI. I am thinking just a handful of Javacript functions that would be called in the same for each viewer, and allow me access the scenegraph in each of viewers. The programming work, I was planning to go myself. I was looking more for feedback, and guidance. And I was planning on using the QWebChannel object built into Qt for accessing the webpage already loaded into the Qt objects that display the webpage. This wouldn’t be communicating with external browsers or other websites. Aaron From: John Carlson Sent: Tuesday, February 18, 2025 2:14 PM To: X3D Ecosystem public discussion Cc: Bergstrom, Aaron Subject: Re: [X3D-Ecosystem] X3DOM/X_ITE/Castle Content Preview in RawKee X3D Exporter for Maya Aaron, There is prior work on this, primarily DIS, EAI, which got folded into SAI, and socket.io (http://socket.io) work I did on my JSONverse project. Office Towers has full multiuser avatars. I would suggest creating an extension to x3d.py project which will do SAI across the network, possibly using the EAI underneath SAI. If you want to move objects around the scene, DIS or HLA may be indicated. There’s an X3DOM pull request for DIS. X_ITE doesn’t support DIS. JSONverse is written with X_ITE. Since JSONverse uses X3D script You probably won’t see leadership supporting anything else, unless it’s in the Metaverse Standards Forum. Web3D is a member. I believe the Webiverse may be a proposal using existing standards. I am more interested in what goes across the network, which events, etc. WebSockets has good backing, but people are working on WebTransport now. Might I suggest we discuss what you want to communicate before we discuss standards? On Tue, Feb 18, 2025 at 11:59?AM Bergstrom, Aaron wrote: What I’m hoping for is to collaborate with the X3D Ecosystem community and X3D viewer developers to standardize Maya/RawKee/QtWebChannel communication across the various viewers. You can learn a bit more about this here: https://doc.qt.io/qtforpython-6/PySide6/QtWebChannel/index.html And by doing a Google search based on these search request: ‘communicate with QtWebEngine using javascript via PySide6’ Thoughts? Thanks, Aaron -- X3D-Ecosystem mailing list X3D-Ecosystem at web3d.org (mailto:X3D-Ecosystem at web3d.org) http://web3d.org/mailman/listinfo/x3d-ecosystem_web3d.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Wed Feb 19 12:29:33 2025 From: yottzumm at gmail.com (John Carlson) Date: Wed, 19 Feb 2025 14:29:33 -0600 Subject: [x3d-public] [X3D-Ecosystem] X3DOM/X_ITE/Castle Content Preview in RawKee X3D Exporter for Maya In-Reply-To: References: Message-ID: The aim is cross-x3d browser scene loading and possibly modification. Which API is best currently. John On Wed, Feb 19, 2025 at 2:15?PM Joe D Williams wrote: > > standard set of functions, perhaps DOM > > > > The DOM and its interfaces continue to evolve to make it more 'alive' and > competent for realtime interactive simulations. > > Like the X3D SAI the DOM has enough power to implement a realtime fully validating > authoring system. > > Both the DOM and SAI can coexist beside or embedded in one another. > > The DOM is represented as a tree; X3D is presented as a DAG with multiple > roots and hierarchy of namespaces. > > Just that the X3D SAI has certain runtime advantages. > > These are mainly derived from the idea that SAI is conceived as a > realtime/anytime, internally/externally scriptable, prototypable, > > validatable process with both declarative and imperative aspects presented > human-readable form. > > In addition, X3D runtime is both time and internal/external event-driven > and fully documents frame-by-frame event flows as the scene progresses. > > X3D is basically the xmlized version of VRML but can be produced in most > any language, including ecmascript, java, json, etc. > > > > So all is great. The X3D scenegraph can be represented as inline code > interspersed with the html and use mainly DOM runtime, or > > run directly using SAI contained by Canvas, or > > run independently directly in the OS as a 3D web browser. > > As real 3D interactive support improves in current WWW browsers and > evolves toward metaversal experiences, the value and versatility of X3D > will increase. > > > > > Qt WebChannel > > > > Look around, maybe a way to do HUDs and control panels, but lots of > licensing involved? > > > > Thanks, > > Joe > > > > > > > > -----Original Message----- > > From: X3D Ecosystem public discussion > Sent: Feb 19, 2025 9:25 AM > To: Bergstrom, Aaron > Cc: John Carlson , X3D Ecosystem public discussion < > x3d-ecosystem at web3d.org> > Subject: Re: [X3D-Ecosystem] X3DOM/X_ITE/Castle Content Preview in RawKee > X3D Exporter for Maya > > > To understand where I?m coming from, read the link, which includes: > > ? > Qt WebChannel enables peer-to-peer communication between a server > (QML/Python application) and a client (HTML/JavaScript or QML application). > It is supported out of the box by Qt WebEngine . In addition it can work > on all browsers that support WebSockets , enabling Qt WebChannel clients > to run in any JavaScript environment (including QML). This requires the > implementation of a custom transport based on Qt WebSockets. > ? > So I see client/server and websockets and I think JSONverse and socket.io. > > AFAIK, there?s no X3D standard which includes websockets. > > But it seems like you?re more about a standard set of functions, perhaps > DOM, which is common across all JS browsers. > > I don?t know if there?s an X3D DOM standard, but I suspect the best place > to look is the XML encoding. > > John > > > On Tue, Feb 18, 2025 at 2:48?PM Bergstrom, Aaron > wrote: > >> John, >> >> >> >> I think we are talking about two different things. What you?ve described >> sounds very complex and is not what I had in mind. >> >> >> >> So I apologize if I gave the impression that I was looking to recreate >> the DIS, EAI. >> >> >> >> I am thinking just a handful of Javacript functions that would be called >> in the same for each viewer, and allow me access the scenegraph in each of >> viewers. >> >> >> >> The programming work, I was planning to go myself. I was looking more for >> feedback, and guidance. And I was planning on using the QWebChannel object >> built into Qt for accessing the webpage already loaded into the Qt objects >> that display the webpage. >> >> >> >> This wouldn?t be communicating with external browsers or other websites. >> >> >> >> >> >> Aaron >> >> >> >> *From:* John Carlson >> *Sent:* Tuesday, February 18, 2025 2:14 PM >> *To:* X3D Ecosystem public discussion >> *Cc:* Bergstrom, Aaron >> *Subject:* Re: [X3D-Ecosystem] X3DOM/X_ITE/Castle Content Preview in >> RawKee X3D Exporter for Maya >> >> >> >> Aaron, >> >> >> >> There is prior work on this, primarily DIS, EAI, which got folded into >> SAI, and socket.io work I did on my JSONverse project. Office Towers has >> full multiuser avatars. >> >> >> >> I would suggest creating an extension to x3d.py project which will do SAI >> across the network, possibly using the EAI underneath SAI. If you want to >> move objects around the scene, DIS or HLA may be indicated. There?s an >> X3DOM pull request for DIS. X_ITE doesn?t support DIS. JSONverse is >> written with X_ITE. Since JSONverse uses X3D script >> >> >> >> You probably won?t see leadership supporting anything else, unless it?s >> in the Metaverse Standards Forum. Web3D is a member. I believe the >> Webiverse may be a proposal using existing standards. >> >> >> >> I am more interested in what goes across the network, which events, etc. >> WebSockets has good backing, but people are working on WebTransport now. >> >> >> >> Might I suggest we discuss what you want to communicate before we discuss >> standards? >> >> >> >> On Tue, Feb 18, 2025 at 11:59?AM Bergstrom, Aaron wrote: >> >> >> >> What I?m hoping for is to collaborate with the X3D Ecosystem community >> and X3D viewer developers to standardize Maya/RawKee/QtWebChannel >> communication across the various viewers. >> >> >> >> You can learn a bit more about this here: >> >> https://doc.qt.io/qtforpython-6/PySide6/QtWebChannel/index.html >> >> >> >> And by doing a Google search based on these search request: >> >> ?communicate with QtWebEngine using javascript via PySide6? >> >> >> >> Thoughts? >> >> >> >> Thanks, >> >> >> >> Aaron >> >> -- >> X3D-Ecosystem mailing list >> X3D-Ecosystem at web3d.org >> http://web3d.org/mailman/listinfo/x3d-ecosystem_web3d.org >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From joedwil at earthlink.net Wed Feb 19 13:06:29 2025 From: joedwil at earthlink.net (Joe D Williams) Date: Wed, 19 Feb 2025 21:06:29 +0000 Subject: [x3d-public] SFRotation default value spec. inconsistency Message-ID: <6cb3151d-ba79-28f4-692c-90f304b04389@earthlink.net> OK, Good, I was worried about x y z all being zero yet have some value for angle not zero. Thanks, Joe -----Original Message----- From: John Carlson Sent: Feb 19, 2025 8:10 AM To: Extensible 3D (X3D) Graphics public discussion Cc: Joe D Williams , Andreas Plesch Subject: Re: [x3d-public] SFRotation default value spec. inconsistency Yes, that was the point I was trying to make with 0 0 0 not being an axis or normalized. Thanks for backup. On Wed, Feb 19, 2025 at 8:51?AM Andreas Plesch via x3d-public wrote: On Tue, Feb 18, 2025 at 10:16?AM Joe D Williams wrote: > ... may prefer the equivalent zero-rotation default value 0 1 0 0 .. Thanks Don. So the Transform rotation and Viewpoint orientation and any other use of rotation and orientation are treated as default zero when angle is zero, or, if all x, y, and z are zero. Just a caution that * https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/fieldTypes.html#SFRotationAndMFRotation says "The first three values specify a normalized rotation axis vector". So x,y,z all zero is not a valid (illegal) SFRotation value. -Andreas -----Original Message----- From: Brutzman, Donald (Don) (CIV) Sent: Feb 17, 2025 9:08 PM To: Andreas Plesch , Joseph D Williams Cc: Extensible 3D (X3D) Graphics public discussion Subject: Re: [x3d-public] SFRotation default value spec. inconsistency Thanks for discussion and for noticing the difference. Related references: * 19777-1 X3D ECMAScript language binding, clause 7 Function definitions, 7.6.6 SFRotation * https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#SFRotation * Table 7.18 — SFRotation instance creation functions * SFRotation (numeric x, numeric y, numeric z, numeric angle) x, y, and z are the axis of the rotation. angle is the angle of the rotation (in radians). Missing values default to 0.0, except y, which defaults to 1.0. * X3D Architecture, clause 5 Field type reference, 5.3.13 SFRotation and MFRotation * https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/fieldTypes.html#SFRotationAndMFRotation * "The default value of an uninitialized SFRotation field is (0 0 1 0). The default value of an MFRotation field is the empty list." Yes they must be the same, so that X3D models are equivalent no matter what file encoding or programming-language binding are used. The X3D Architecture takes precedence. So we will change 19777-1 to match and the highlighted y above will become z. I too think that a default of (0 1 0 0) makes more sense, animation rotations are most often around the vertical (y) axis. However, the community has discussed this many times over the years. We always landed on (0 0 1 0) for backwards-compatibility reasons, not wanting to break legacy X3D and VRML models. Incidentally here is the X3D tooltips entry. Improvements and refinements always welcome. * X3D Tooltips: SFRotation * https://www.web3d.org/x3d/tooltips/X3dTooltips.html#SFRotation * SFRotation (https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/fieldTypes.html#SFRotationAndMFRotation) Single-Field rotation value using 3-tuple axis, radian angle form Default value 0 0 1 0. Model authors and authoring tools may prefer the equivalent zero-rotation default value 0 1 0 0 since rotation about the vertical Y-axis is most common. Example values: 0 1 0 1.57 Warning: initial 3-tuple axis vector cannot hold a zero-magnitude vector. Warning: comma characters within attribute values are not allowed, and do not pass strict validation. Hint: see Wikipedia: Radian (https://en.wikipedia.org/wiki/Radian), Rotation matrix (https://en.wikipedia.org/wiki/Rotation_matrix) and Rotation formalisms in three dimensions (https://en.wikipedia.org/wiki/Rotation_formalisms_in_three_dimensions). XML Schema (https://www.web3d.org/specifications/X3dSchemaDocumentation4.0/x3d-4.0_SFRotation.html), X3D regexes (https://www.web3d.org/specifications/X3dRegularExpressions.html#SFRotation), Java SAI (https://www.web3d.org/specifications/JavaLanguageBinding/Part2/nodeTypeInterfaces.html#SFRotation), X3DJ (https://www.web3d.org/specifications/java/javadoc/org/web3d/x3d/jsail/fields/SFRotation.html) To keep track of this erratum, I have entered a new issue in the Mantis issue tracker. * Mantis 1488: (ECMAScript) 7.6.6 SFRotation default value needs to be (0 0 1 0) * https://mantis.web3d.org/view.php?id=1488 I hope this make sense and sounds good. Have fun with X3D - or else!! ? all the best, Don -- Don Brutzman Naval Postgraduate School, Code USW/Br brutzman at nps.edu (mailto:brutzman at nps.edu) Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149 X3D graphics, virtual worlds, navy robotics https://faculty.nps.edu/brutzman From: x3d-public on behalf of Joe D Williams via x3d-public Sent: Sunday, February 16, 2025 9:09 AM To: Andreas Plesch Cc: joedwil at earthlink.net (mailto:joedwil at earthlink.net) ; X3D Subject: Re: [x3d-public] SFRotation default value spec. inconsistency > I would vote for 0 1 0 0 since rotations around Y seem more common First,oldest use is in Part 1, way back to origin of VRML standard. Is Yaw really more popular or common than Pitch or Roll? For me, Please let's stick with oldest history and update more recent. Thanks Joe -----Original Message----- From: Andreas Plesch Sent: Feb 15, 2025 9:12 PM To: Cc: Holger Seelig , X3D Subject: Re: [x3d-public] SFRotation default value spec. inconsistency I agree, probably the best default value for a unit quaternion is 0 0 0 1. However, X3D does not concern itself with quaternions, only axis-angle rotations. So the original question remains: Part 1 has axis-angle 0 0 1 0 as default while the JS SAI spec. has 0 1 0 0. Should both list the same default value ? If yes, which one ? I would vote for 0 1 0 0 since rotations around Y seem more common. -Andreas On Sat, Feb 15, 2025 at 11:04?PM wrote: Doesn't this mean that the _best_ default value, for no rotation, is 'legally' for unit quaternion = 0 0 0 1 because the square root of the sum of the squares of all four components does = 1 ? 0 0 0 0 would not be a legal unit quaternion. While the axis-angle default is 0 0 1 0 as appears in Part 1 is mostly for convenience since many value combinations can produce zero rotation? Also sure shows why axis-angle is so much easier to work with when typing numbers, pitch and yaw and roll for all. Thanks, Joe -----Original Message----- From: Andreas Plesch Sent: Feb 14, 2025 11:36 AM To: Holger Seelig Cc: X3D , Joseph D Williams Subject: Re: [x3d-public] SFRotation default value spec. inconsistency Let me just add for clarity that the length (or norm) of a quaternion includes the fourth, the scalar component. The norm is the square root of the sum of the squares of all four components. Only unit quaternions represent rotations. A (0,0,0,0) quaternion does not represent any rotation (but of course exists outside of rotations). Andreas PS: To add back in some fuzziness, a unit quaternion can only represent a rotation up to 360 degrees. I think there is a mechanism to use non-unit quaternions for larger rotations. On Fri, Feb 14, 2025 at 10:22?AM Holger Seelig wrote: All quaternions must be normalized to be a legal rotation, so the length of the quaternion must always be one. Holger-- Holger Seelig Leipzig, Germany holger.seelig at yahoo.de (mailto:holger.seelig at yahoo.de) https://create3000.github.io/x_ite/ Am 14.02.2025 um 15:38 schrieb Joe D Williams via x3d-public : > So, sensibly, a zero rotation around any axis corresponds to the "zero unit Quaternion" (0, 0, 0, 1 XYZW), Right. Not sure but 0 0 0 0 for unit quaternion might not be legal. I think the values must compute to1 to be legal? Thanks, Joe -----Original Message----- From: Andreas Plesch Sent: Feb 10, 2025 12:37 PM To: Joe D Williams Cc: Extensible 3D (X3D) Graphics public discussion Subject: Re: [x3d-public] SFRotation default value spec. inconsistency https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#_node_rotation has indeed (0, 0, 0, 1 XYZW) as a default value. This is difficult to interpret as a rotation around an axis since the corresponding axis would be at first glance (0 0 0). x3dom converts quaternion (0, 0, 0, 1 XYZW) to (axis),angle (0,0,0),0 as does https://www.andre-gaschler.com/rotationconverter/ (https://www.andre-gaschler.com/rotationconverter/) . On the other hand both SFRotation (0 0 1 0) and SFRotation (0 1 0 0) are also represented by quaternion (0, 0, 0, 1 XYZW). So, sensibly, a zero rotation around any axis corresponds to the "zero unit Quaternion" (0, 0, 0, 1 XYZW), making it a useful default value for quaternions. But that does not help with choosing a default axis for the SFRotation value. This will rarely matter. A use case may be when a SFRotation is initialized to the X3D default in a Proto but then only the angle is modified by a Proto script with the assumption that the axis is (0 0 1). -Andreas On Mon, Feb 10, 2025 at 12:57?PM Joe D Williams wrote: not zerp, zero -----Original Message----- From: Extensible 3D (X3D) Graphics public discussion Sent: Feb 10, 2025 9:50 AM To: Extensible 3D (X3D) Graphics public discussion , X3D Graphics public mailing list Cc: Joe D Williams , Andreas Plesch Subject: Re: [x3d-public] SFRotation default value spec. inconsistency I think the 0 0 1 0 should be used everywhere for default axis-angle. I thinkI see 'zerp' unit quaternions (as in gltf as 0 0 0 1 XYZW) Thanks, Joe -----Original Message----- From: Extensible 3D (X3D) Graphics public discussion Sent: Feb 10, 2025 8:44 AM To: X3D Graphics public mailing list Cc: Andreas Plesch Subject: Re: [x3d-public] SFRotation default value spec. inconsistency The JS SAI spec. at https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#FieldServices (https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#FieldServices) does not list functions for SFColorRGBA, only SFColor. There may be an earlier report. -Andreas On Mon, Feb 10, 2025 at 11:31?AM Andreas Plesch wrote: https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/fieldTypes.html#SFRotationAndMFRotation specifies that (0 0 1 0) is the value of an uninitialized SFRotation given as (x y z a). However, the JS SAI spec. in table 7.18 in https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#SFRotationInstanceCreationFunction (https://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#SFRotationInstanceCreationFunction) effectively makes (0 1 0 0) the default value if no parameters are provided. The inconsistency does not have much of an impact since both are 0 rotations but I believe (0 1 0 0) - a 0 rotation around y - may have been intended as the default. -Andreas -- Andreas Plesch Waltham, MA 02453 -- Andreas Plesch Waltham, MA 02453 -- Andreas Plesch Waltham, MA 02453 _______________________________________________ x3d-public mailing list x3d-public at web3d.org (mailto:x3d-public at web3d.org) http://web3d.org/mailman/listinfo/x3d-public_web3d.org -- Andreas Plesch Waltham, MA 02453 -- Andreas Plesch Waltham, MA 02453 -- Andreas Plesch Waltham, MA 02453 _______________________________________________ x3d-public mailing list x3d-public at web3d.org (mailto:x3d-public at web3d.org) http://web3d.org/mailman/listinfo/x3d-public_web3d.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Wed Feb 19 15:24:20 2025 From: yottzumm at gmail.com (John Carlson) Date: Wed, 19 Feb 2025 17:24:20 -0600 Subject: [x3d-public] HAnimDisplacer effect on coord.point In-Reply-To: References: Message-ID: Attached is an example with a Hud. I can't get the menu (with the Hud ProximitySensor and Transforms) to move differently than Jin, so I'm kind of stuck. There's probably some silly problem that I missed. The menus move with the mouse. Thanks for looking, John On Tue, Feb 18, 2025 at 6:49?PM John Carlson wrote: > Thanks for code samples, Joe. It looks like I can take out my > Layering/Layout code and just focus on the menu. Sorry I am so slow on > this, I think I might be hibernating. > > I?m looking at my GitHub commits and they have dropped drastically. This > might be because I am spending more time helping others with recovery or > just using social media too much. > > I will try to get to the HUD in the next two days. It was so cold, we > didn?t even go to the dentist 45 miles away. We got out today though. > > John > > On Tue, Feb 18, 2025 at 6:38?PM Joe D Williams > wrote: > >> > a HUD for Joe >> >> >> >> A hud for the FACS example is needed because any navigation causes the >> menu to disappear. The menu can be just like used on the Jin scaled with >> animation example. However that uses a ProximitySensor which x3dom does not >> support, for some reason. We use that a lot for start timers, timers, >> etc.as well as being the typical way to keep a menu or scene data in >> view. >> >> If HTML/SVG is better, I have not seen it. I don't think Stacking canvas >> is appropriate. Fine to think of XR for in-world 2d or3d HUDS but does that >> sort ofdisplay really work any different than using prox sensor? >> ProximitySensor is just so basic. >> >> >> >> >> >> >> >> >> >> rest of menu >> >> > toField='set_translation' toNode='HudXform'/> >> > toField='set_rotation' toNode='HudXform'/> >> >> >> >> Thanks and Best, >> >> Joe >> >> >> >> huds3d >> >> XR >> >> -----Original Message----- >> From: Andreas Plesch >> Sent: Feb 18, 2025 11:45 AM >> To: John Carlson >> Cc: Extensible 3D (X3D) Graphics public discussion , >> Holger Seelig , Joseph D Williams < >> joedwil at earthlink.net>, Brutzman, Donald (Don) (CIV) , >> Carol McDonald >> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >> >> >> Please do not wait for x3dom. Both ProximitySensor and the Layering >> component are lower priority. HTML/SVG is better suited for 2D HUDs and >> layering can be approximated by stacking multiple X3D canvases/scenes. You >> may also consider XR where immersion typically strongly favors in-world 3d >> HUDs. >> >> Best, -Andreas >> >> On Tue, Feb 18, 2025 at 2:25?PM John Carlson wrote: >> >>> Don, we?re currently working on a HUD for Joe, I don?t currently have an >>> online example of that. >>> >>> Otherwise, I?m waiting on someone deciding which meshes to merge. I >>> could take the lead on this. >>> >>> I could use a tutorial on the Layering and Layout components, examples >>> don?t seem to help. I may try to adopt a 3D HUD based on examples. >>> Something with the 2D overlay in WORLD space would help tremendously, or >>> some conversion from WORLD space. >>> >>> We already have 3D menus, so a 3D HUD might be easiest. >>> >>> Thanks, >>> >>> John >>> On Mon, Feb 17, 2025 at 11:18?PM Brutzman, Donald (Don) (CIV) via >>> x3d-public wrote: >>> >>>> Wondering, do we have a simple excerpted example that we can look at >>>> yet? That will help guide these discussions. >>>> >>>> Don't need a full human body animation in all its displaceable glory... >>>> >>>> >>>> >>>> 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 >>>> https://faculty.nps.edu/brutzman >>>> >>>> >>>> >>>> ------------------------------ >>>> *From:* x3d-public on behalf of Joe D >>>> Williams via x3d-public >>>> *Sent:* Saturday, February 15, 2025 6:55 PM >>>> *To:* Holger Seelig ; Andreas Plesch < >>>> andreasplesch at gmail.com> >>>> *Cc:* joedwil at earthlink.net ; X3D < >>>> x3d-public at web3d.org>; Carol McDonald >>>> >>>> *Subject:* Re: [x3d-public] HAnimDisplacer effect on coord.point >>>> >>>> >>>> > coord.point changes are very very expensive quickly, >>>> >>>> >>>> >>>> Right, the processing time gets expensive as the number of points moved. >>>> >>>> If level 1 segment geometry where the mesh is driven directly by a >>>> joint, then it easier since weight is always 1. >>>> >>>> For level 2 skin, the the weight (radial movement) applied by maybe >>>> multiple joints needs to be computed for each point. >>>> >>>> Finally, for both levels, the displacements for selected set of points >>>> needs to be applied. >>>> >>>> This implies multiple passes on the subject coordinates? >>>> >>>> Whatever, these operations are common where the applications deal with >>>> >>>> a complete mesh and with sparse points of a mesh for blending. . >>>> >>>> >>>> >>>> > with reference to CoordinateInterpolator, >>>> >>>> >>>> >>>> These are useful when controlling all points of a target mesh. >>>> >>>> All points of a mesh must be included and same number of points at each >>>> keyframe. >>>> >>>> This style was used in first step of the current example x3d FACS >>>> because >>>> >>>> face geometry is made from multiple shapes. CoordinateInterpolater >>>> sets >>>> >>>> for each shape for each elemental action moved the points. >>>> >>>> This was simplified to using the same face for each action example >>>> >>>> and then replaced the CIs with sets of Displacers. >>>> >>>> Now have developed further to combine individual actions to make a >>>> >>>> specific expression which consists of multiple elemental movements. >>>> >>>> However, I think we want to evolve towards a basic single mesh face >>>> >>>> with some individual shapes for like teeth, hair, eyeballs, eyelids, >>>> tongue, maybe ears? >>>> >>>> and using joint nodes to control, where appropriate. >>>> >>>> >>>> >>>> Regardless of how the points are moved for the next frame, it has to be >>>> >>>> considered that geometry points will be moved directly by joint >>>> rotations, >>>> >>>> by a weighting algorithm using multiple joint rotation inputs, >>>> >>>> and by one or more scalar-driven Displacer inputs. >>>> >>>> >>>> >>>> Thanks for HAnim, >>>> >>>> Joe >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -----Message----- >>>> >>>> From: Holger Seelig >>>> Sent: Feb 9, 2025 11:23 AM >>>> To: Andreas Plesch >>>> Cc: X3D , Joseph D Williams < >>>> joedwil at earthlink.net>, Carol McDonald >>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>> >>>> >>>> I don't think so, coord.point changes are very very expensive quickly, >>>> and as Michalis said earlier, with reference to CoordinateInterpolator, we >>>> should get rid of them. >>>> >>>> Holger >>>> -- >>>> Holger Seelig >>>> Leipzig, Germany >>>> >>>> holger.seelig at yahoo.de >>>> https://create3000.github.io/x_ite/ >>>> >>>> Am 09.02.2025 um 19:44 schrieb Andreas Plesch >>> >: >>>> Yes, that is an option. However,coord.point changes are very very >>>> expensive quickly, and as Michalis said earlier, with reference to >>>> CoordinateInterpolator, we should get rid of them. >>>> >>>> Andreas >>>> >>>> On Sun, Feb 9, 2025, 1:40?PM Holger Seelig >>>> wrote: >>>> >>>> X_ITE applies the HAnimDisplacers in the shader, thus no coord.point >>>> field has to be changed. >>>> Maybe that helps. >>>> >>>> Best regards, >>>> Holger >>>> >>>> -- >>>> Holger Seelig >>>> Leipzig, Germany >>>> >>>> holger.seelig at yahoo.de >>>> https://create3000.github.io/x_ite/ >>>> >>>> Am 09.02.2025 um 19:33 schrieb Andreas Plesch via x3d-public < >>>> x3d-public at web3d.org>: >>>> >>>> That would be the point field of a Coordinate node >>>> >>>> >>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/rendering.html#Coordinate >>>> >>>> which is used by the coord field of >>>> >>>> >>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimSegment >>>> >>>> Andreas >>>> >>>> On Sun, Feb 9, 2025, 12:36?PM Joe D Williams >>>> wrote: >>>> >>>> > coord node emit a point_changed event >>>> >>>> >>>> sorry,I don't see a field anywhere with that event. Displacer is likely >>>> to change several points when new weight is sent. All part of the cascade >>>> to produce the changed mesh? >>>> Thanks, >>>> Joe >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Andreas Plesch >>>> Sent: Feb 9, 2025 4:25 AM >>>> To: Brutzman, Donald (Don) (CIV) >>>> Cc: Extensible 3D (X3D) Graphics public discussion < >>>> x3d-public at web3d.org>, Carol McDonald , Joe D >>>> Williams , John Carlson >>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>> >>>> >>>> Don, Joe and John >>>> >>>> Thanks for collecting these references. >>>> >>>> But I am not sure if there is an answer to my original question. Let me >>>> rephrase a bit the question: >>>> >>>> After a Displacer contained in a Segment node receives a set_weight >>>> input, should then the coord node emit a point_changed event ? >>>> >>>> I do not think HAnim is concerned about that, so it is really a X3D >>>> question. >>>> >>>> Thanks, Andreas >>>> >>>> On Sun, Feb 9, 2025, 12:49?AM Brutzman, Donald (Don) (CIV) < >>>> brutzman at nps.edu> wrote: >>>> >>>> Thanks for pointing in the right direction John. >>>> >>>> Direct links to functional requirements for Displacer in HAnim 2.0 >>>> specification: >>>> >>>> - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, >>>> Clause 4 Concepts, 4.7 Displacer object >>>> - >>>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#DisplacerObject >>>> >>>> - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, >>>> Clause 6 Object interfaces, 6.6 Displacer >>>> - >>>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer >>>> >>>> and >>>> >>>> - X3D 4.0 Architecture, Clause 26 Humanoid Animation (HAnim) >>>> component, 26.3.1 HAnimDisplacer >>>> - >>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimDisplacer >>>> >>>> and informative >>>> >>>> - X3D Tooltips, HAnimDisplacer >>>> - https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimDisplacer >>>> >>>> Thanks for implementation efforts and careful scrutiny. >>>> >>>> Questions and potential issues/clarifications/corrections are always >>>> welcome. >>>> >>>> >>>> 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 >>>> https://faculty.nps.edu/brutzman >>>> >>>> >>>> >>>> ------------------------------ >>>> *From:* x3d-public on behalf of John >>>> Carlson via x3d-public >>>> *Sent:* Saturday, February 8, 2025 3:43 AM >>>> *To:* Extensible 3D (X3D) Graphics public discussion < >>>> x3d-public at web3d.org>; Carol McDonald ; Joe D >>>> Williams >>>> *Cc:* John Carlson ; Andreas Plesch < >>>> andreasplesch at gmail.com> >>>> *Subject:* Re: [x3d-public] HAnimDisplacer effect on coord.point >>>> >>>> Here?s what HAnim spec says under Displacer: >>>> >>>> https://www.web3d.org/documents/specifications/19774/V2.0/index.html >>>> >>>> ?For the *Displacer* objects that are contained in the *displacers* field >>>> of the *Segment* objects, the *displacements* are defined and applied >>>> in the *Segment* coordinate system. The base mesh for the morphed >>>> *Segment* is the original mesh defined in the *Segment*.? >>>> >>>> And here?s what it says under Segment: >>>> >>>> ? >>>> >>>> The *coord* field is used for *Segment* objects that have deformable >>>> meshes and shall contain coordinates referenced from the indexed mesh for >>>> the *Segment* object. The coordinates are given the same name as the >>>> *Segment* object, but with a "_coords" appended (e.g.,"skull_coords").? >>>> displacements are an offset from the mesh, with weight from 0 to 1. >>>> So weight times displacement is total offset from base mesh. 0 weight = no >>>> offset, 1 weight = full displacements offset >>>> >>>> The Coordinate point is maintained to handle weight = 0. Weight ranges >>>> from 0 to 1, but double check. >>>> >>>> Joe or Carol might know where to find it in the HAnim spec. >>>> >>>> I believe the answer is, ?during rendering,?. Since weight can vary >>>> with animation, and so can displacements, AFAIK. More than one displacer >>>> can be applied to the mesh. >>>> >>>> I have not read the spec. >>>> >>>> John >>>> >>>> >>>> >>>> On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public < >>>> x3d-public at web3d.org> wrote: >>>> >>>> >>>> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer >>>> >>>> does not directly explain what the effect of the displacer on the >>>> coord.point field of the containing HAnimSegment is. But it mentions the >>>> coord.point field and seems to imply that the coord.point field is involved. >>>> >>>> So the question is if the Displacer should alter the coord.point field >>>> in order to achieve a graphical displacement, or if the Browser should only >>>> apply the displacements during rendering without a change in the >>>> coord.point field ? >>>> >>>> This is relevant if the coord.point field is accessed by routes or >>>> scripts, in addition to displacers. >>>> >>>> Thanks for any feedback or ideas, >>>> >>>> Andreas >>>> >>>> -- >>>> Andreas Plesch >>>> Waltham, MA 02453 >>>> _______________________________________________ >>>> x3d-public mailing list >>>> x3d-public at web3d.org >>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>> >>>> >>>> >>>> _______________________________________________ >>>> x3d-public mailing list >>>> x3d-public at web3d.org >>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>> >>>> >>>> _______________________________________________ >>>> x3d-public mailing list >>>> x3d-public at web3d.org >>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>> >>> >> >> -- >> Andreas Plesch >> Waltham, MA 02453 >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Clocks6.zip Type: application/x-zip-compressed Size: 251599 bytes Desc: not available URL: From holger.seelig at yahoo.de Thu Feb 20 05:18:05 2025 From: holger.seelig at yahoo.de (Holger Seelig) Date: Thu, 20 Feb 2025 14:18:05 +0100 Subject: [x3d-public] HAnimDisplacer effect on coord.point In-Reply-To: References: Message-ID: <36E93FD5-C4F6-44DA-B202-B48E1CFA724B@yahoo.de> For some reason I cannot open those *.zip files from you John. My system say ?Unknown file format?. Best regards, Holger -- Holger Seelig Leipzig, Germany holger.seelig at yahoo.de https://create3000.github.io/x_ite/ > Am 20.02.2025 um 00:24 schrieb John Carlson : > > Attached is an example with a Hud. I can't get the menu (with the Hud ProximitySensor and Transforms) to move differently than Jin, so I'm kind of stuck. > > There's probably some silly problem that I missed. The menus move with the mouse. > > Thanks for looking, > > John > > On Tue, Feb 18, 2025 at 6:49?PM John Carlson > wrote: >> Thanks for code samples, Joe. It looks like I can take out my Layering/Layout code and just focus on the menu. Sorry I am so slow on this, I think I might be hibernating. >> >> I?m looking at my GitHub commits and they have dropped drastically. This might be because I am spending more time helping others with recovery or just using social media too much. >> >> I will try to get to the HUD in the next two days. It was so cold, we didn?t even go to the dentist 45 miles away. We got out today though. >> >> John >> >> On Tue, Feb 18, 2025 at 6:38?PM Joe D Williams > wrote: >>> > a HUD for Joe >>> >>> A hud for the FACS example is needed because any navigation causes the menu to disappear. The menu can be just like used on the Jin scaled with animation example. However that uses a ProximitySensor which x3dom does not support, for some reason. We use that a lot for start timers, timers, etc.as well as being the typical way to keep a menu or scene data in view. >>> If HTML/SVG is better, I have not seen it. I don't think Stacking canvas is appropriate. Fine to think of XR for in-world 2d or3d HUDS but does that sort ofdisplay really work any different than using prox sensor? ProximitySensor is just so basic. >>> >>> >>> >>> >>> rest of menu >>> >>> >>> >>> Thanks and Best, >>> Joe >>> >>> huds3d >>> XR >>> >>> -----Original Message----- >>> From: Andreas Plesch > >>> Sent: Feb 18, 2025 11:45 AM >>> To: John Carlson > >>> Cc: Extensible 3D (X3D) Graphics public discussion >, Holger Seelig >, Joseph D Williams >, Brutzman, Donald (Don) (CIV) >, Carol McDonald > >>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>> >>> >>> Please do not wait for x3dom. Both ProximitySensor and the Layering component are lower priority. HTML/SVG is better suited for 2D HUDs and layering can be approximated by stacking multiple X3D canvases/scenes. You may also consider XR where immersion typically strongly favors in-world 3d HUDs. >>> >>> Best, -Andreas >>> >>> On Tue, Feb 18, 2025 at 2:25?PM John Carlson > wrote: >>>> Don, we?re currently working on a HUD for Joe, I don?t currently have an online example of that. >>>> >>>> Otherwise, I?m waiting on someone deciding which meshes to merge. I could take the lead on this. >>>> >>>> I could use a tutorial on the Layering and Layout components, examples don?t seem to help. I may try to adopt a 3D HUD based on examples. Something with the 2D overlay in WORLD space would help tremendously, or some conversion from WORLD space. >>>> >>>> We already have 3D menus, so a 3D HUD might be easiest. >>>> >>>> Thanks, >>>> >>>> John >>>> On Mon, Feb 17, 2025 at 11:18?PM Brutzman, Donald (Don) (CIV) via x3d-public > wrote: >>>>> Wondering, do we have a simple excerpted example that we can look at yet? That will help guide these discussions. >>>>> >>>>> Don't need a full human body animation in all its displaceable glory... >>>>> >>>>> 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 https://faculty.nps.edu/brutzman >>>>> >>>>> >>>>> From: x3d-public > on behalf of Joe D Williams via x3d-public > >>>>> Sent: Saturday, February 15, 2025 6:55 PM >>>>> To: Holger Seelig >; Andreas Plesch > >>>>> Cc: joedwil at earthlink.net >; X3D >; Carol McDonald > >>>>> >>>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>> >>>>> > coord.point changes are very very expensive quickly, >>>>> >>>>> Right, the processing time gets expensive as the number of points moved. >>>>> If level 1 segment geometry where the mesh is driven directly by a joint, then it easier since weight is always 1. >>>>> For level 2 skin, the the weight (radial movement) applied by maybe multiple joints needs to be computed for each point. >>>>> Finally, for both levels, the displacements for selected set of points needs to be applied. >>>>> This implies multiple passes on the subject coordinates? >>>>> Whatever, these operations are common where the applications deal with >>>>> a complete mesh and with sparse points of a mesh for blending. . >>>>> >>>>> > with reference to CoordinateInterpolator, >>>>> >>>>> These are useful when controlling all points of a target mesh. >>>>> All points of a mesh must be included and same number of points at each keyframe. >>>>> This style was used in first step of the current example x3d FACS because >>>>> face geometry is made from multiple shapes. CoordinateInterpolater sets >>>>> for each shape for each elemental action moved the points. >>>>> This was simplified to using the same face for each action example >>>>> and then replaced the CIs with sets of Displacers. >>>>> Now have developed further to combine individual actions to make a >>>>> specific expression which consists of multiple elemental movements. >>>>> However, I think we want to evolve towards a basic single mesh face >>>>> with some individual shapes for like teeth, hair, eyeballs, eyelids, tongue, maybe ears? >>>>> and using joint nodes to control, where appropriate. >>>>> >>>>> Regardless of how the points are moved for the next frame, it has to be >>>>> considered that geometry points will be moved directly by joint rotations, >>>>> by a weighting algorithm using multiple joint rotation inputs, >>>>> and by one or more scalar-driven Displacer inputs. >>>>> >>>>> Thanks for HAnim, >>>>> Joe >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -----Message----- >>>>> From: Holger Seelig > >>>>> Sent: Feb 9, 2025 11:23 AM >>>>> To: Andreas Plesch > >>>>> Cc: X3D >, Joseph D Williams >, Carol McDonald > >>>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>> >>>>> I don't think so, coord.point changes are very very expensive quickly, and as Michalis said earlier, with reference to CoordinateInterpolator, we should get rid of them. >>>>> >>>>> Holger >>>>> -- >>>>> Holger Seelig >>>>> Leipzig, Germany >>>>> >>>>> holger.seelig at yahoo.de >>>>> https://create3000.github.io/x_ite/ >>>>> >>>>> Am 09.02.2025 um 19:44 schrieb Andreas Plesch >: >>>>> Yes, that is an option. However,coord.point changes are very very expensive quickly, and as Michalis said earlier, with reference to CoordinateInterpolator, we should get rid of them. >>>>> >>>>> Andreas >>>>> >>>>> On Sun, Feb 9, 2025, 1:40?PM Holger Seelig > wrote: >>>>> X_ITE applies the HAnimDisplacers in the shader, thus no coord.point field has to be changed. >>>>> Maybe that helps. >>>>> >>>>> Best regards, >>>>> Holger >>>>> >>>>> -- >>>>> Holger Seelig >>>>> Leipzig, Germany >>>>> >>>>> holger.seelig at yahoo.de >>>>> https://create3000.github.io/x_ite/ >>>>> >>>>> Am 09.02.2025 um 19:33 schrieb Andreas Plesch via x3d-public >: >>>>> >>>>> That would be the point field of a Coordinate node >>>>> >>>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/rendering.html#Coordinate >>>>> >>>>> which is used by the coord field of >>>>> >>>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimSegment >>>>> >>>>> Andreas >>>>> >>>>> On Sun, Feb 9, 2025, 12:36?PM Joe D Williams > wrote: >>>>> > coord node emit a point_changed event >>>>> >>>>> sorry,I don't see a field anywhere with that event. Displacer is likely to change several points when new weight is sent. All part of the cascade to produce the changed mesh? >>>>> Thanks, >>>>> Joe >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Andreas Plesch > >>>>> Sent: Feb 9, 2025 4:25 AM >>>>> To: Brutzman, Donald (Don) (CIV) > >>>>> Cc: Extensible 3D (X3D) Graphics public discussion >, Carol McDonald >, Joe D Williams >, John Carlson > >>>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>> >>>>> >>>>> Don, Joe and John >>>>> >>>>> Thanks for collecting these references. >>>>> >>>>> But I am not sure if there is an answer to my original question. Let me rephrase a bit the question: >>>>> >>>>> After a Displacer contained in a Segment node receives a set_weight input, should then the coord node emit a point_changed event ? >>>>> >>>>> I do not think HAnim is concerned about that, so it is really a X3D question. >>>>> >>>>> Thanks, Andreas >>>>> >>>>> On Sun, Feb 9, 2025, 12:49?AM Brutzman, Donald (Don) (CIV) > wrote: >>>>> Thanks for pointing in the right direction John. >>>>> >>>>> Direct links to functional requirements for Displacer in HAnim 2.0 specification: >>>>> HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, Clause 4 Concepts, 4.7 Displacer object >>>>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#DisplacerObject >>>>> >>>>> HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, Clause 6 Object interfaces, 6.6 Displacer >>>>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer >>>>> and >>>>> X3D 4.0 Architecture, Clause 26 Humanoid Animation (HAnim) component, 26.3.1 HAnimDisplacer >>>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimDisplacer >>>>> and informative >>>>> X3D Tooltips, HAnimDisplacer >>>>> https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimDisplacer >>>>> Thanks for implementation efforts and careful scrutiny. >>>>> >>>>> Questions and potential issues/clarifications/corrections are always welcome. >>>>> >>>>> >>>>> 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 https://faculty.nps.edu/brutzman >>>>> >>>>> >>>>> From: x3d-public > on behalf of John Carlson via x3d-public > >>>>> Sent: Saturday, February 8, 2025 3:43 AM >>>>> To: Extensible 3D (X3D) Graphics public discussion >; Carol McDonald >; Joe D Williams > >>>>> Cc: John Carlson >; Andreas Plesch > >>>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>> >>>>> Here?s what HAnim spec says under Displacer: >>>>> >>>>> https://www.web3d.org/documents/specifications/19774/V2.0/index.html >>>>> >>>>> ?For the Displacer objects that are contained in the displacers field of the Segment objects, the displacements are defined and applied in the Segment coordinate system. The base mesh for the morphed Segment is the original mesh defined in the Segment.? >>>>> >>>>> And here?s what it says under Segment: >>>>> >>>>> ? >>>>> The coord field is used for Segment objects that have deformable meshes and shall contain coordinates referenced from the indexed mesh for the Segment object. The coordinates are given the same name as the Segment object, but with a "_coords" appended (e.g.,"skull_coords").? >>>>> >>>>> displacements are an offset from the mesh, with weight from 0 to 1. So weight times displacement is total offset from base mesh. 0 weight = no offset, 1 weight = full displacements offset >>>>> >>>>> The Coordinate point is maintained to handle weight = 0. Weight ranges from 0 to 1, but double check. >>>>> >>>>> Joe or Carol might know where to find it in the HAnim spec. >>>>> >>>>> I believe the answer is, ?during rendering,?. Since weight can vary with animation, and so can displacements, AFAIK. More than one displacer can be applied to the mesh. >>>>> >>>>> I have not read the spec. >>>>> >>>>> John >>>>> >>>>> >>>>> >>>>> On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public > wrote: >>>>> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer >>>>> >>>>> does not directly explain what the effect of the displacer on the coord.point field of the containing HAnimSegment is. But it mentions the coord.point field and seems to imply that the coord.point field is involved. >>>>> >>>>> So the question is if the Displacer should alter the coord.point field in order to achieve a graphical displacement, or if the Browser should only apply the displacements during rendering without a change in the coord.point field ? >>>>> >>>>> This is relevant if the coord.point field is accessed by routes or scripts, in addition to displacers. >>>>> >>>>> Thanks for any feedback or ideas, >>>>> >>>>> Andreas >>>>> >>>>> -- >>>>> Andreas Plesch >>>>> Waltham, MA 02453 >>>>> _______________________________________________ >>>>> x3d-public mailing list >>>>> x3d-public at web3d.org >>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>>> >>>>> _______________________________________________ >>>>> x3d-public mailing list >>>>> x3d-public at web3d.org >>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>>> >>>>> _______________________________________________ >>>>> x3d-public mailing list >>>>> x3d-public at web3d.org >>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>> >>> >>> >>> -- >>> Andreas Plesch >>> Waltham, MA 02453 >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Thu Feb 20 09:17:27 2025 From: yottzumm at gmail.com (John Carlson) Date: Thu, 20 Feb 2025 11:17:27 -0600 Subject: [x3d-public] HAnimDisplacer effect on coord.point In-Reply-To: <36E93FD5-C4F6-44DA-B202-B48E1CFA724B@yahoo.de> References: <36E93FD5-C4F6-44DA-B202-B48E1CFA724B@yahoo.de> Message-ID: Try java SDK jar program? John On Thu, Feb 20, 2025 at 7:19?AM Holger Seelig via x3d-public < x3d-public at web3d.org> wrote: > For some reason I cannot open those *.zip files from you John. My system > say ?Unknown file format?. > > Best regards, > Holger > > -- > Holger Seelig > Leipzig, Germany > > holger.seelig at yahoo.de > https://create3000.github.io/x_ite/ > > Am 20.02.2025 um 00:24 schrieb John Carlson : > > Attached is an example with a Hud. I can't get the menu (with the Hud > ProximitySensor and Transforms) to move differently than Jin, so I'm kind > of stuck. > > There's probably some silly problem that I missed. The menus move > with the mouse. > > Thanks for looking, > > John > > On Tue, Feb 18, 2025 at 6:49?PM John Carlson wrote: > >> Thanks for code samples, Joe. It looks like I can take out my >> Layering/Layout code and just focus on the menu. Sorry I am so slow on >> this, I think I might be hibernating. >> >> I?m looking at my GitHub commits and they have dropped drastically. This >> might be because I am spending more time helping others with recovery or >> just using social media too much. >> >> I will try to get to the HUD in the next two days. It was so cold, we >> didn?t even go to the dentist 45 miles away. We got out today though. >> >> John >> >> On Tue, Feb 18, 2025 at 6:38?PM Joe D Williams >> wrote: >> >>> > a HUD for Joe >>> >>> >>> A hud for the FACS example is needed because any navigation causes the >>> menu to disappear. The menu can be just like used on the Jin scaled with >>> animation example. However that uses a ProximitySensor which x3dom does not >>> support, for some reason. We use that a lot for start timers, timers, >>> etc.as well as being the typical way to keep a menu or scene data in >>> view. >>> If HTML/SVG is better, I have not seen it. I don't think Stacking >>> canvas is appropriate. Fine to think of XR for in-world 2d or3d HUDS but >>> does that sort ofdisplay really work any different than using prox sensor? >>> ProximitySensor is just so basic. >>> >>> >>> >>> >>> >>> rest of menu >>> >> toField='set_translation' toNode='HudXform'/> >>> >> toField='set_rotation' toNode='HudXform'/> >>> >>> >>> Thanks and Best, >>> Joe >>> >>> >>> huds3d >>> XR >>> >>> -----Original Message----- >>> From: Andreas Plesch >>> Sent: Feb 18, 2025 11:45 AM >>> To: John Carlson >>> Cc: Extensible 3D (X3D) Graphics public discussion , >>> Holger Seelig , Joseph D Williams < >>> joedwil at earthlink.net>, Brutzman, Donald (Don) (CIV) , >>> Carol McDonald >>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>> >>> >>> Please do not wait for x3dom. Both ProximitySensor and the Layering >>> component are lower priority. HTML/SVG is better suited for 2D HUDs and >>> layering can be approximated by stacking multiple X3D canvases/scenes. You >>> may also consider XR where immersion typically strongly favors in-world 3d >>> HUDs. >>> >>> Best, -Andreas >>> >>> On Tue, Feb 18, 2025 at 2:25?PM John Carlson wrote: >>> >>>> Don, we?re currently working on a HUD for Joe, I don?t currently have >>>> an online example of that. >>>> >>>> Otherwise, I?m waiting on someone deciding which meshes to merge. I >>>> could take the lead on this. >>>> >>>> I could use a tutorial on the Layering and Layout components, examples >>>> don?t seem to help. I may try to adopt a 3D HUD based on examples. >>>> Something with the 2D overlay in WORLD space would help tremendously, or >>>> some conversion from WORLD space. >>>> >>>> We already have 3D menus, so a 3D HUD might be easiest. >>>> >>>> Thanks, >>>> >>>> John >>>> On Mon, Feb 17, 2025 at 11:18?PM Brutzman, Donald (Don) (CIV) via >>>> x3d-public wrote: >>>> >>>>> Wondering, do we have a simple excerpted example that we can look at >>>>> yet? That will help guide these discussions. >>>>> >>>>> Don't need a full human body animation in all its displaceable glory... >>>>> >>>>> >>>>> 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 >>>>> https://faculty.nps.edu/brutzman >>>>> >>>>> >>>>> >>>>> ------------------------------ >>>>> *From:* x3d-public on behalf of Joe D >>>>> Williams via x3d-public >>>>> *Sent:* Saturday, February 15, 2025 6:55 PM >>>>> *To:* Holger Seelig ; Andreas Plesch < >>>>> andreasplesch at gmail.com> >>>>> *Cc:* joedwil at earthlink.net ; X3D < >>>>> x3d-public at web3d.org>; Carol McDonald >>>>> >>>>> *Subject:* Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>> >>>>> > coord.point changes are very very expensive quickly, >>>>> >>>>> >>>>> Right, the processing time gets expensive as the number of points >>>>> moved. >>>>> If level 1 segment geometry where the mesh is driven directly by a >>>>> joint, then it easier since weight is always 1. >>>>> For level 2 skin, the the weight (radial movement) applied by maybe >>>>> multiple joints needs to be computed for each point. >>>>> Finally, for both levels, the displacements for selected set of points >>>>> needs to be applied. >>>>> This implies multiple passes on the subject coordinates? >>>>> Whatever, these operations are common where the applications deal with >>>>> a complete mesh and with sparse points of a mesh for blending. . >>>>> >>>>> >>>>> > with reference to CoordinateInterpolator, >>>>> >>>>> >>>>> These are useful when controlling all points of a target mesh. >>>>> All points of a mesh must be included and same number of points at >>>>> each keyframe. >>>>> This style was used in first step of the current example x3d FACS >>>>> because >>>>> face geometry is made from multiple shapes. CoordinateInterpolater >>>>> sets >>>>> for each shape for each elemental action moved the points. >>>>> This was simplified to using the same face for each action example >>>>> and then replaced the CIs with sets of Displacers. >>>>> Now have developed further to combine individual actions to make a >>>>> specific expression which consists of multiple elemental movements. >>>>> However, I think we want to evolve towards a basic single mesh face >>>>> with some individual shapes for like teeth, hair, eyeballs, eyelids, >>>>> tongue, maybe ears? >>>>> and using joint nodes to control, where appropriate. >>>>> >>>>> >>>>> Regardless of how the points are moved for the next frame, it has to >>>>> be >>>>> considered that geometry points will be moved directly by joint >>>>> rotations, >>>>> by a weighting algorithm using multiple joint rotation inputs, >>>>> and by one or more scalar-driven Displacer inputs. >>>>> >>>>> >>>>> Thanks for HAnim, >>>>> Joe >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -----Message----- >>>>> From: Holger Seelig >>>>> Sent: Feb 9, 2025 11:23 AM >>>>> To: Andreas Plesch >>>>> Cc: X3D , Joseph D Williams < >>>>> joedwil at earthlink.net>, Carol McDonald >>>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>> >>>>> >>>>> I don't think so, coord.point changes are very very expensive quickly, >>>>> and as Michalis said earlier, with reference to CoordinateInterpolator, we >>>>> should get rid of them. >>>>> >>>>> Holger >>>>> -- >>>>> Holger Seelig >>>>> Leipzig, Germany >>>>> >>>>> holger.seelig at yahoo.de >>>>> https://create3000.github.io/x_ite/ >>>>> >>>>> Am 09.02.2025 um 19:44 schrieb Andreas Plesch >>>> >: >>>>> Yes, that is an option. However,coord.point changes are very very >>>>> expensive quickly, and as Michalis said earlier, with reference to >>>>> CoordinateInterpolator, we should get rid of them. >>>>> >>>>> Andreas >>>>> >>>>> On Sun, Feb 9, 2025, 1:40?PM Holger Seelig >>>>> wrote: >>>>> >>>>> X_ITE applies the HAnimDisplacers in the shader, thus no coord.point >>>>> field has to be changed. >>>>> Maybe that helps. >>>>> >>>>> Best regards, >>>>> Holger >>>>> >>>>> -- >>>>> Holger Seelig >>>>> Leipzig, Germany >>>>> >>>>> holger.seelig at yahoo.de >>>>> https://create3000.github.io/x_ite/ >>>>> >>>>> Am 09.02.2025 um 19:33 schrieb Andreas Plesch via x3d-public < >>>>> x3d-public at web3d.org>: >>>>> >>>>> That would be the point field of a Coordinate node >>>>> >>>>> >>>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/rendering.html#Coordinate >>>>> >>>>> which is used by the coord field of >>>>> >>>>> >>>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimSegment >>>>> >>>>> Andreas >>>>> >>>>> On Sun, Feb 9, 2025, 12:36?PM Joe D Williams >>>>> wrote: >>>>> >>>>> > coord node emit a point_changed event >>>>> >>>>> >>>>> sorry,I don't see a field anywhere with that event. Displacer is >>>>> likely to change several points when new weight is sent. All part of the >>>>> cascade to produce the changed mesh? >>>>> Thanks, >>>>> Joe >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Andreas Plesch >>>>> Sent: Feb 9, 2025 4:25 AM >>>>> To: Brutzman, Donald (Don) (CIV) >>>>> Cc: Extensible 3D (X3D) Graphics public discussion < >>>>> x3d-public at web3d.org>, Carol McDonald , Joe D >>>>> Williams , John Carlson >>>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>> >>>>> >>>>> Don, Joe and John >>>>> >>>>> Thanks for collecting these references. >>>>> >>>>> But I am not sure if there is an answer to my original question. Let >>>>> me rephrase a bit the question: >>>>> >>>>> After a Displacer contained in a Segment node receives a set_weight >>>>> input, should then the coord node emit a point_changed event ? >>>>> >>>>> I do not think HAnim is concerned about that, so it is really a X3D >>>>> question. >>>>> >>>>> Thanks, Andreas >>>>> >>>>> On Sun, Feb 9, 2025, 12:49?AM Brutzman, Donald (Don) (CIV) < >>>>> brutzman at nps.edu> wrote: >>>>> >>>>> Thanks for pointing in the right direction John. >>>>> >>>>> Direct links to functional requirements for Displacer in HAnim 2.0 >>>>> specification: >>>>> >>>>> - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, >>>>> Clause 4 Concepts, 4.7 Displacer object >>>>> - >>>>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#DisplacerObject >>>>> >>>>> - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, >>>>> Clause 6 Object interfaces, 6.6 Displacer >>>>> - >>>>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer >>>>> >>>>> and >>>>> >>>>> - X3D 4.0 Architecture, Clause 26 Humanoid Animation (HAnim) >>>>> component, 26.3.1 HAnimDisplacer >>>>> - >>>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimDisplacer >>>>> >>>>> and informative >>>>> >>>>> - X3D Tooltips, HAnimDisplacer >>>>> - https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimDisplacer >>>>> >>>>> Thanks for implementation efforts and careful scrutiny. >>>>> >>>>> Questions and potential issues/clarifications/corrections are always >>>>> welcome. >>>>> >>>>> >>>>> 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 >>>>> https://faculty.nps.edu/brutzman >>>>> >>>>> >>>>> >>>>> ------------------------------ >>>>> *From:* x3d-public on behalf of John >>>>> Carlson via x3d-public >>>>> *Sent:* Saturday, February 8, 2025 3:43 AM >>>>> *To:* Extensible 3D (X3D) Graphics public discussion < >>>>> x3d-public at web3d.org>; Carol McDonald ; Joe D >>>>> Williams >>>>> *Cc:* John Carlson ; Andreas Plesch < >>>>> andreasplesch at gmail.com> >>>>> *Subject:* Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>> >>>>> Here?s what HAnim spec says under Displacer: >>>>> >>>>> https://www.web3d.org/documents/specifications/19774/V2.0/index.html >>>>> >>>>> ?For the *Displacer* objects that are contained in the *displacers* field >>>>> of the *Segment* objects, the *displacements* are defined and applied >>>>> in the *Segment* coordinate system. The base mesh for the morphed >>>>> *Segment* is the original mesh defined in the *Segment*.? >>>>> >>>>> And here?s what it says under Segment: >>>>> >>>>> ? >>>>> >>>>> The *coord* field is used for *Segment* objects that have deformable >>>>> meshes and shall contain coordinates referenced from the indexed mesh for >>>>> the *Segment* object. The coordinates are given the same name as the >>>>> *Segment* object, but with a "_coords" appended (e.g.,"skull_coords" >>>>> ).? >>>>> displacements are an offset from the mesh, with weight from 0 to 1. >>>>> So weight times displacement is total offset from base mesh. 0 weight = no >>>>> offset, 1 weight = full displacements offset >>>>> >>>>> The Coordinate point is maintained to handle weight = 0. Weight >>>>> ranges from 0 to 1, but double check. >>>>> >>>>> Joe or Carol might know where to find it in the HAnim spec. >>>>> >>>>> I believe the answer is, ?during rendering,?. Since weight can vary >>>>> with animation, and so can displacements, AFAIK. More than one displacer >>>>> can be applied to the mesh. >>>>> >>>>> I have not read the spec. >>>>> >>>>> John >>>>> >>>>> >>>>> >>>>> On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public < >>>>> x3d-public at web3d.org> wrote: >>>>> >>>>> >>>>> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer >>>>> >>>>> does not directly explain what the effect of the displacer on the >>>>> coord.point field of the containing HAnimSegment is. But it mentions the >>>>> coord.point field and seems to imply that the coord.point field is involved. >>>>> >>>>> So the question is if the Displacer should alter the coord.point field >>>>> in order to achieve a graphical displacement, or if the Browser should only >>>>> apply the displacements during rendering without a change in the >>>>> coord.point field ? >>>>> >>>>> This is relevant if the coord.point field is accessed by routes or >>>>> scripts, in addition to displacers. >>>>> >>>>> Thanks for any feedback or ideas, >>>>> >>>>> Andreas >>>>> >>>>> -- >>>>> Andreas Plesch >>>>> Waltham, MA 02453 >>>>> _______________________________________________ >>>>> x3d-public mailing list >>>>> x3d-public at web3d.org >>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> x3d-public mailing list >>>>> x3d-public at web3d.org >>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>>> >>>>> >>>>> _______________________________________________ >>>>> x3d-public mailing list >>>>> x3d-public at web3d.org >>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>> >>>> >>> >>> -- >>> Andreas Plesch >>> Waltham, MA 02453 >>> >>> >>> >> > > > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger.seelig at yahoo.de Thu Feb 20 09:42:37 2025 From: holger.seelig at yahoo.de (Holger Seelig) Date: Thu, 20 Feb 2025 18:42:37 +0100 Subject: [x3d-public] HAnimDisplacer effect on coord.point In-Reply-To: References: Message-ID: <215C055A-411D-4C08-9BE3-F3F4AC63E839@yahoo.de> No. It should be your intention to provide files everyone can open. A ZIP file shouldn?t be so difficult today. Holger -- Holger Seelig Leipzig, Germany holger.seelig at yahoo.de https://create3000.github.io/x_ite/ > Am 20.02.2025 um 00:24 schrieb John Carlson : > > Attached is an example with a Hud. I can't get the menu (with the Hud ProximitySensor and Transforms) to move differently than Jin, so I'm kind of stuck. > > There's probably some silly problem that I missed. The menus move with the mouse. > > Thanks for looking, > > John > > On Tue, Feb 18, 2025 at 6:49?PM John Carlson > wrote: >> Thanks for code samples, Joe. It looks like I can take out my Layering/Layout code and just focus on the menu. Sorry I am so slow on this, I think I might be hibernating. >> >> I?m looking at my GitHub commits and they have dropped drastically. This might be because I am spending more time helping others with recovery or just using social media too much. >> >> I will try to get to the HUD in the next two days. It was so cold, we didn?t even go to the dentist 45 miles away. We got out today though. >> >> John >> >> On Tue, Feb 18, 2025 at 6:38?PM Joe D Williams > wrote: >>> > a HUD for Joe >>> >>> A hud for the FACS example is needed because any navigation causes the menu to disappear. The menu can be just like used on the Jin scaled with animation example. However that uses a ProximitySensor which x3dom does not support, for some reason. We use that a lot for start timers, timers, etc.as well as being the typical way to keep a menu or scene data in view. >>> If HTML/SVG is better, I have not seen it. I don't think Stacking canvas is appropriate. Fine to think of XR for in-world 2d or3d HUDS but does that sort ofdisplay really work any different than using prox sensor? ProximitySensor is just so basic. >>> >>> >>> >>> >>> rest of menu >>> >>> >>> >>> Thanks and Best, >>> Joe >>> >>> huds3d >>> XR >>> >>> -----Original Message----- >>> From: Andreas Plesch > >>> Sent: Feb 18, 2025 11:45 AM >>> To: John Carlson > >>> Cc: Extensible 3D (X3D) Graphics public discussion >, Holger Seelig >, Joseph D Williams >, Brutzman, Donald (Don) (CIV) >, Carol McDonald > >>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>> >>> >>> Please do not wait for x3dom. Both ProximitySensor and the Layering component are lower priority. HTML/SVG is better suited for 2D HUDs and layering can be approximated by stacking multiple X3D canvases/scenes. You may also consider XR where immersion typically strongly favors in-world 3d HUDs. >>> >>> Best, -Andreas >>> >>> On Tue, Feb 18, 2025 at 2:25?PM John Carlson > wrote: >>>> Don, we?re currently working on a HUD for Joe, I don?t currently have an online example of that. >>>> >>>> Otherwise, I?m waiting on someone deciding which meshes to merge. I could take the lead on this. >>>> >>>> I could use a tutorial on the Layering and Layout components, examples don?t seem to help. I may try to adopt a 3D HUD based on examples. Something with the 2D overlay in WORLD space would help tremendously, or some conversion from WORLD space. >>>> >>>> We already have 3D menus, so a 3D HUD might be easiest. >>>> >>>> Thanks, >>>> >>>> John >>>> On Mon, Feb 17, 2025 at 11:18?PM Brutzman, Donald (Don) (CIV) via x3d-public > wrote: >>>>> Wondering, do we have a simple excerpted example that we can look at yet? That will help guide these discussions. >>>>> >>>>> Don't need a full human body animation in all its displaceable glory... >>>>> >>>>> 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 https://faculty.nps.edu/brutzman >>>>> >>>>> >>>>> From: x3d-public > on behalf of Joe D Williams via x3d-public > >>>>> Sent: Saturday, February 15, 2025 6:55 PM >>>>> To: Holger Seelig >; Andreas Plesch > >>>>> Cc: joedwil at earthlink.net >; X3D >; Carol McDonald > >>>>> >>>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>> >>>>> > coord.point changes are very very expensive quickly, >>>>> >>>>> Right, the processing time gets expensive as the number of points moved. >>>>> If level 1 segment geometry where the mesh is driven directly by a joint, then it easier since weight is always 1. >>>>> For level 2 skin, the the weight (radial movement) applied by maybe multiple joints needs to be computed for each point. >>>>> Finally, for both levels, the displacements for selected set of points needs to be applied. >>>>> This implies multiple passes on the subject coordinates? >>>>> Whatever, these operations are common where the applications deal with >>>>> a complete mesh and with sparse points of a mesh for blending. . >>>>> >>>>> > with reference to CoordinateInterpolator, >>>>> >>>>> These are useful when controlling all points of a target mesh. >>>>> All points of a mesh must be included and same number of points at each keyframe. >>>>> This style was used in first step of the current example x3d FACS because >>>>> face geometry is made from multiple shapes. CoordinateInterpolater sets >>>>> for each shape for each elemental action moved the points. >>>>> This was simplified to using the same face for each action example >>>>> and then replaced the CIs with sets of Displacers. >>>>> Now have developed further to combine individual actions to make a >>>>> specific expression which consists of multiple elemental movements. >>>>> However, I think we want to evolve towards a basic single mesh face >>>>> with some individual shapes for like teeth, hair, eyeballs, eyelids, tongue, maybe ears? >>>>> and using joint nodes to control, where appropriate. >>>>> >>>>> Regardless of how the points are moved for the next frame, it has to be >>>>> considered that geometry points will be moved directly by joint rotations, >>>>> by a weighting algorithm using multiple joint rotation inputs, >>>>> and by one or more scalar-driven Displacer inputs. >>>>> >>>>> Thanks for HAnim, >>>>> Joe >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -----Message----- >>>>> From: Holger Seelig > >>>>> Sent: Feb 9, 2025 11:23 AM >>>>> To: Andreas Plesch > >>>>> Cc: X3D >, Joseph D Williams >, Carol McDonald > >>>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>> >>>>> I don't think so, coord.point changes are very very expensive quickly, and as Michalis said earlier, with reference to CoordinateInterpolator, we should get rid of them. >>>>> >>>>> Holger >>>>> -- >>>>> Holger Seelig >>>>> Leipzig, Germany >>>>> >>>>> holger.seelig at yahoo.de >>>>> https://create3000.github.io/x_ite/ >>>>> >>>>> Am 09.02.2025 um 19:44 schrieb Andreas Plesch >: >>>>> Yes, that is an option. However,coord.point changes are very very expensive quickly, and as Michalis said earlier, with reference to CoordinateInterpolator, we should get rid of them. >>>>> >>>>> Andreas >>>>> >>>>> On Sun, Feb 9, 2025, 1:40?PM Holger Seelig > wrote: >>>>> X_ITE applies the HAnimDisplacers in the shader, thus no coord.point field has to be changed. >>>>> Maybe that helps. >>>>> >>>>> Best regards, >>>>> Holger >>>>> >>>>> -- >>>>> Holger Seelig >>>>> Leipzig, Germany >>>>> >>>>> holger.seelig at yahoo.de >>>>> https://create3000.github.io/x_ite/ >>>>> >>>>> Am 09.02.2025 um 19:33 schrieb Andreas Plesch via x3d-public >: >>>>> >>>>> That would be the point field of a Coordinate node >>>>> >>>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/rendering.html#Coordinate >>>>> >>>>> which is used by the coord field of >>>>> >>>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimSegment >>>>> >>>>> Andreas >>>>> >>>>> On Sun, Feb 9, 2025, 12:36?PM Joe D Williams > wrote: >>>>> > coord node emit a point_changed event >>>>> >>>>> sorry,I don't see a field anywhere with that event. Displacer is likely to change several points when new weight is sent. All part of the cascade to produce the changed mesh? >>>>> Thanks, >>>>> Joe >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Andreas Plesch > >>>>> Sent: Feb 9, 2025 4:25 AM >>>>> To: Brutzman, Donald (Don) (CIV) > >>>>> Cc: Extensible 3D (X3D) Graphics public discussion >, Carol McDonald >, Joe D Williams >, John Carlson > >>>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>> >>>>> >>>>> Don, Joe and John >>>>> >>>>> Thanks for collecting these references. >>>>> >>>>> But I am not sure if there is an answer to my original question. Let me rephrase a bit the question: >>>>> >>>>> After a Displacer contained in a Segment node receives a set_weight input, should then the coord node emit a point_changed event ? >>>>> >>>>> I do not think HAnim is concerned about that, so it is really a X3D question. >>>>> >>>>> Thanks, Andreas >>>>> >>>>> On Sun, Feb 9, 2025, 12:49?AM Brutzman, Donald (Don) (CIV) > wrote: >>>>> Thanks for pointing in the right direction John. >>>>> >>>>> Direct links to functional requirements for Displacer in HAnim 2.0 specification: >>>>> HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, Clause 4 Concepts, 4.7 Displacer object >>>>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#DisplacerObject >>>>> >>>>> HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, Clause 6 Object interfaces, 6.6 Displacer >>>>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer >>>>> and >>>>> X3D 4.0 Architecture, Clause 26 Humanoid Animation (HAnim) component, 26.3.1 HAnimDisplacer >>>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimDisplacer >>>>> and informative >>>>> X3D Tooltips, HAnimDisplacer >>>>> https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimDisplacer >>>>> Thanks for implementation efforts and careful scrutiny. >>>>> >>>>> Questions and potential issues/clarifications/corrections are always welcome. >>>>> >>>>> >>>>> 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 https://faculty.nps.edu/brutzman >>>>> >>>>> >>>>> From: x3d-public > on behalf of John Carlson via x3d-public > >>>>> Sent: Saturday, February 8, 2025 3:43 AM >>>>> To: Extensible 3D (X3D) Graphics public discussion >; Carol McDonald >; Joe D Williams > >>>>> Cc: John Carlson >; Andreas Plesch > >>>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>> >>>>> Here?s what HAnim spec says under Displacer: >>>>> >>>>> https://www.web3d.org/documents/specifications/19774/V2.0/index.html >>>>> >>>>> ?For the Displacer objects that are contained in the displacers field of the Segment objects, the displacements are defined and applied in the Segment coordinate system. The base mesh for the morphed Segment is the original mesh defined in the Segment.? >>>>> >>>>> And here?s what it says under Segment: >>>>> >>>>> ? >>>>> The coord field is used for Segment objects that have deformable meshes and shall contain coordinates referenced from the indexed mesh for the Segment object. The coordinates are given the same name as the Segment object, but with a "_coords" appended (e.g.,"skull_coords").? >>>>> >>>>> displacements are an offset from the mesh, with weight from 0 to 1. So weight times displacement is total offset from base mesh. 0 weight = no offset, 1 weight = full displacements offset >>>>> >>>>> The Coordinate point is maintained to handle weight = 0. Weight ranges from 0 to 1, but double check. >>>>> >>>>> Joe or Carol might know where to find it in the HAnim spec. >>>>> >>>>> I believe the answer is, ?during rendering,?. Since weight can vary with animation, and so can displacements, AFAIK. More than one displacer can be applied to the mesh. >>>>> >>>>> I have not read the spec. >>>>> >>>>> John >>>>> >>>>> >>>>> >>>>> On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public > wrote: >>>>> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer >>>>> >>>>> does not directly explain what the effect of the displacer on the coord.point field of the containing HAnimSegment is. But it mentions the coord.point field and seems to imply that the coord.point field is involved. >>>>> >>>>> So the question is if the Displacer should alter the coord.point field in order to achieve a graphical displacement, or if the Browser should only apply the displacements during rendering without a change in the coord.point field ? >>>>> >>>>> This is relevant if the coord.point field is accessed by routes or scripts, in addition to displacers. >>>>> >>>>> Thanks for any feedback or ideas, >>>>> >>>>> Andreas >>>>> >>>>> -- >>>>> Andreas Plesch >>>>> Waltham, MA 02453 >>>>> _______________________________________________ >>>>> x3d-public mailing list >>>>> x3d-public at web3d.org >>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>>> >>>>> _______________________________________________ >>>>> x3d-public mailing list >>>>> x3d-public at web3d.org >>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>>> >>>>> _______________________________________________ >>>>> x3d-public mailing list >>>>> x3d-public at web3d.org >>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>> >>> >>> >>> -- >>> Andreas Plesch >>> Waltham, MA 02453 >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Thu Feb 20 11:16:45 2025 From: yottzumm at gmail.com (John Carlson) Date: Thu, 20 Feb 2025 13:16:45 -0600 Subject: [x3d-public] HAnimDisplacer effect on coord.point In-Reply-To: <215C055A-411D-4C08-9BE3-F3F4AC63E839@yahoo.de> References: <215C055A-411D-4C08-9BE3-F3F4AC63E839@yahoo.de> Message-ID: Did you try the unzip program? The jar/zip could be corrupted? Vince also had a similar issues with my jars/zips. John On Thu, Feb 20, 2025 at 11:43?AM Holger Seelig via x3d-public < x3d-public at web3d.org> wrote: > No. It should be your intention to provide files everyone can open. A ZIP > file shouldn?t be so difficult today. > > Holger > > -- > Holger Seelig > Leipzig, Germany > > holger.seelig at yahoo.de > https://create3000.github.io/x_ite/ > > Am 20.02.2025 um 00:24 schrieb John Carlson : > > Attached is an example with a Hud. I can't get the menu (with the Hud > ProximitySensor and Transforms) to move differently than Jin, so I'm kind > of stuck. > > There's probably some silly problem that I missed. The menus move > with the mouse. > > Thanks for looking, > > John > > On Tue, Feb 18, 2025 at 6:49?PM John Carlson wrote: > >> Thanks for code samples, Joe. It looks like I can take out my >> Layering/Layout code and just focus on the menu. Sorry I am so slow on >> this, I think I might be hibernating. >> >> I?m looking at my GitHub commits and they have dropped drastically. This >> might be because I am spending more time helping others with recovery or >> just using social media too much. >> >> I will try to get to the HUD in the next two days. It was so cold, we >> didn?t even go to the dentist 45 miles away. We got out today though. >> >> John >> >> On Tue, Feb 18, 2025 at 6:38?PM Joe D Williams >> wrote: >> >>> > a HUD for Joe >>> >>> >>> A hud for the FACS example is needed because any navigation causes the >>> menu to disappear. The menu can be just like used on the Jin scaled with >>> animation example. However that uses a ProximitySensor which x3dom does not >>> support, for some reason. We use that a lot for start timers, timers, >>> etc.as well as being the typical way to keep a menu or scene data in >>> view. >>> If HTML/SVG is better, I have not seen it. I don't think Stacking >>> canvas is appropriate. Fine to think of XR for in-world 2d or3d HUDS but >>> does that sort ofdisplay really work any different than using prox sensor? >>> ProximitySensor is just so basic. >>> >>> >>> >>> >>> >>> rest of menu >>> >> toField='set_translation' toNode='HudXform'/> >>> >> toField='set_rotation' toNode='HudXform'/> >>> >>> >>> Thanks and Best, >>> Joe >>> >>> >>> huds3d >>> XR >>> >>> -----Original Message----- >>> From: Andreas Plesch >>> Sent: Feb 18, 2025 11:45 AM >>> To: John Carlson >>> Cc: Extensible 3D (X3D) Graphics public discussion , >>> Holger Seelig , Joseph D Williams < >>> joedwil at earthlink.net>, Brutzman, Donald (Don) (CIV) , >>> Carol McDonald >>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>> >>> >>> Please do not wait for x3dom. Both ProximitySensor and the Layering >>> component are lower priority. HTML/SVG is better suited for 2D HUDs and >>> layering can be approximated by stacking multiple X3D canvases/scenes. You >>> may also consider XR where immersion typically strongly favors in-world 3d >>> HUDs. >>> >>> Best, -Andreas >>> >>> On Tue, Feb 18, 2025 at 2:25?PM John Carlson wrote: >>> >>>> Don, we?re currently working on a HUD for Joe, I don?t currently have >>>> an online example of that. >>>> >>>> Otherwise, I?m waiting on someone deciding which meshes to merge. I >>>> could take the lead on this. >>>> >>>> I could use a tutorial on the Layering and Layout components, examples >>>> don?t seem to help. I may try to adopt a 3D HUD based on examples. >>>> Something with the 2D overlay in WORLD space would help tremendously, or >>>> some conversion from WORLD space. >>>> >>>> We already have 3D menus, so a 3D HUD might be easiest. >>>> >>>> Thanks, >>>> >>>> John >>>> On Mon, Feb 17, 2025 at 11:18?PM Brutzman, Donald (Don) (CIV) via >>>> x3d-public wrote: >>>> >>>>> Wondering, do we have a simple excerpted example that we can look at >>>>> yet? That will help guide these discussions. >>>>> >>>>> Don't need a full human body animation in all its displaceable glory... >>>>> >>>>> >>>>> 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 >>>>> https://faculty.nps.edu/brutzman >>>>> >>>>> >>>>> >>>>> ------------------------------ >>>>> *From:* x3d-public on behalf of Joe D >>>>> Williams via x3d-public >>>>> *Sent:* Saturday, February 15, 2025 6:55 PM >>>>> *To:* Holger Seelig ; Andreas Plesch < >>>>> andreasplesch at gmail.com> >>>>> *Cc:* joedwil at earthlink.net ; X3D < >>>>> x3d-public at web3d.org>; Carol McDonald >>>>> >>>>> *Subject:* Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>> >>>>> > coord.point changes are very very expensive quickly, >>>>> >>>>> >>>>> Right, the processing time gets expensive as the number of points >>>>> moved. >>>>> If level 1 segment geometry where the mesh is driven directly by a >>>>> joint, then it easier since weight is always 1. >>>>> For level 2 skin, the the weight (radial movement) applied by maybe >>>>> multiple joints needs to be computed for each point. >>>>> Finally, for both levels, the displacements for selected set of points >>>>> needs to be applied. >>>>> This implies multiple passes on the subject coordinates? >>>>> Whatever, these operations are common where the applications deal with >>>>> a complete mesh and with sparse points of a mesh for blending. . >>>>> >>>>> >>>>> > with reference to CoordinateInterpolator, >>>>> >>>>> >>>>> These are useful when controlling all points of a target mesh. >>>>> All points of a mesh must be included and same number of points at >>>>> each keyframe. >>>>> This style was used in first step of the current example x3d FACS >>>>> because >>>>> face geometry is made from multiple shapes. CoordinateInterpolater >>>>> sets >>>>> for each shape for each elemental action moved the points. >>>>> This was simplified to using the same face for each action example >>>>> and then replaced the CIs with sets of Displacers. >>>>> Now have developed further to combine individual actions to make a >>>>> specific expression which consists of multiple elemental movements. >>>>> However, I think we want to evolve towards a basic single mesh face >>>>> with some individual shapes for like teeth, hair, eyeballs, eyelids, >>>>> tongue, maybe ears? >>>>> and using joint nodes to control, where appropriate. >>>>> >>>>> >>>>> Regardless of how the points are moved for the next frame, it has to >>>>> be >>>>> considered that geometry points will be moved directly by joint >>>>> rotations, >>>>> by a weighting algorithm using multiple joint rotation inputs, >>>>> and by one or more scalar-driven Displacer inputs. >>>>> >>>>> >>>>> Thanks for HAnim, >>>>> Joe >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -----Message----- >>>>> From: Holger Seelig >>>>> Sent: Feb 9, 2025 11:23 AM >>>>> To: Andreas Plesch >>>>> Cc: X3D , Joseph D Williams < >>>>> joedwil at earthlink.net>, Carol McDonald >>>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>> >>>>> >>>>> I don't think so, coord.point changes are very very expensive quickly, >>>>> and as Michalis said earlier, with reference to CoordinateInterpolator, we >>>>> should get rid of them. >>>>> >>>>> Holger >>>>> -- >>>>> Holger Seelig >>>>> Leipzig, Germany >>>>> >>>>> holger.seelig at yahoo.de >>>>> https://create3000.github.io/x_ite/ >>>>> >>>>> Am 09.02.2025 um 19:44 schrieb Andreas Plesch >>>> >: >>>>> Yes, that is an option. However,coord.point changes are very very >>>>> expensive quickly, and as Michalis said earlier, with reference to >>>>> CoordinateInterpolator, we should get rid of them. >>>>> >>>>> Andreas >>>>> >>>>> On Sun, Feb 9, 2025, 1:40?PM Holger Seelig >>>>> wrote: >>>>> >>>>> X_ITE applies the HAnimDisplacers in the shader, thus no coord.point >>>>> field has to be changed. >>>>> Maybe that helps. >>>>> >>>>> Best regards, >>>>> Holger >>>>> >>>>> -- >>>>> Holger Seelig >>>>> Leipzig, Germany >>>>> >>>>> holger.seelig at yahoo.de >>>>> https://create3000.github.io/x_ite/ >>>>> >>>>> Am 09.02.2025 um 19:33 schrieb Andreas Plesch via x3d-public < >>>>> x3d-public at web3d.org>: >>>>> >>>>> That would be the point field of a Coordinate node >>>>> >>>>> >>>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/rendering.html#Coordinate >>>>> >>>>> which is used by the coord field of >>>>> >>>>> >>>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimSegment >>>>> >>>>> Andreas >>>>> >>>>> On Sun, Feb 9, 2025, 12:36?PM Joe D Williams >>>>> wrote: >>>>> >>>>> > coord node emit a point_changed event >>>>> >>>>> >>>>> sorry,I don't see a field anywhere with that event. Displacer is >>>>> likely to change several points when new weight is sent. All part of the >>>>> cascade to produce the changed mesh? >>>>> Thanks, >>>>> Joe >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Andreas Plesch >>>>> Sent: Feb 9, 2025 4:25 AM >>>>> To: Brutzman, Donald (Don) (CIV) >>>>> Cc: Extensible 3D (X3D) Graphics public discussion < >>>>> x3d-public at web3d.org>, Carol McDonald , Joe D >>>>> Williams , John Carlson >>>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>> >>>>> >>>>> Don, Joe and John >>>>> >>>>> Thanks for collecting these references. >>>>> >>>>> But I am not sure if there is an answer to my original question. Let >>>>> me rephrase a bit the question: >>>>> >>>>> After a Displacer contained in a Segment node receives a set_weight >>>>> input, should then the coord node emit a point_changed event ? >>>>> >>>>> I do not think HAnim is concerned about that, so it is really a X3D >>>>> question. >>>>> >>>>> Thanks, Andreas >>>>> >>>>> On Sun, Feb 9, 2025, 12:49?AM Brutzman, Donald (Don) (CIV) < >>>>> brutzman at nps.edu> wrote: >>>>> >>>>> Thanks for pointing in the right direction John. >>>>> >>>>> Direct links to functional requirements for Displacer in HAnim 2.0 >>>>> specification: >>>>> >>>>> - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, >>>>> Clause 4 Concepts, 4.7 Displacer object >>>>> - >>>>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#DisplacerObject >>>>> >>>>> - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, >>>>> Clause 6 Object interfaces, 6.6 Displacer >>>>> - >>>>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer >>>>> >>>>> and >>>>> >>>>> - X3D 4.0 Architecture, Clause 26 Humanoid Animation (HAnim) >>>>> component, 26.3.1 HAnimDisplacer >>>>> - >>>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimDisplacer >>>>> >>>>> and informative >>>>> >>>>> - X3D Tooltips, HAnimDisplacer >>>>> - https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimDisplacer >>>>> >>>>> Thanks for implementation efforts and careful scrutiny. >>>>> >>>>> Questions and potential issues/clarifications/corrections are always >>>>> welcome. >>>>> >>>>> >>>>> 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 >>>>> https://faculty.nps.edu/brutzman >>>>> >>>>> >>>>> >>>>> ------------------------------ >>>>> *From:* x3d-public on behalf of John >>>>> Carlson via x3d-public >>>>> *Sent:* Saturday, February 8, 2025 3:43 AM >>>>> *To:* Extensible 3D (X3D) Graphics public discussion < >>>>> x3d-public at web3d.org>; Carol McDonald ; Joe D >>>>> Williams >>>>> *Cc:* John Carlson ; Andreas Plesch < >>>>> andreasplesch at gmail.com> >>>>> *Subject:* Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>> >>>>> Here?s what HAnim spec says under Displacer: >>>>> >>>>> https://www.web3d.org/documents/specifications/19774/V2.0/index.html >>>>> >>>>> ?For the *Displacer* objects that are contained in the *displacers* field >>>>> of the *Segment* objects, the *displacements* are defined and applied >>>>> in the *Segment* coordinate system. The base mesh for the morphed >>>>> *Segment* is the original mesh defined in the *Segment*.? >>>>> >>>>> And here?s what it says under Segment: >>>>> >>>>> ? >>>>> >>>>> The *coord* field is used for *Segment* objects that have deformable >>>>> meshes and shall contain coordinates referenced from the indexed mesh for >>>>> the *Segment* object. The coordinates are given the same name as the >>>>> *Segment* object, but with a "_coords" appended (e.g.,"skull_coords" >>>>> ).? >>>>> displacements are an offset from the mesh, with weight from 0 to 1. >>>>> So weight times displacement is total offset from base mesh. 0 weight = no >>>>> offset, 1 weight = full displacements offset >>>>> >>>>> The Coordinate point is maintained to handle weight = 0. Weight >>>>> ranges from 0 to 1, but double check. >>>>> >>>>> Joe or Carol might know where to find it in the HAnim spec. >>>>> >>>>> I believe the answer is, ?during rendering,?. Since weight can vary >>>>> with animation, and so can displacements, AFAIK. More than one displacer >>>>> can be applied to the mesh. >>>>> >>>>> I have not read the spec. >>>>> >>>>> John >>>>> >>>>> >>>>> >>>>> On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public < >>>>> x3d-public at web3d.org> wrote: >>>>> >>>>> >>>>> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer >>>>> >>>>> does not directly explain what the effect of the displacer on the >>>>> coord.point field of the containing HAnimSegment is. But it mentions the >>>>> coord.point field and seems to imply that the coord.point field is involved. >>>>> >>>>> So the question is if the Displacer should alter the coord.point field >>>>> in order to achieve a graphical displacement, or if the Browser should only >>>>> apply the displacements during rendering without a change in the >>>>> coord.point field ? >>>>> >>>>> This is relevant if the coord.point field is accessed by routes or >>>>> scripts, in addition to displacers. >>>>> >>>>> Thanks for any feedback or ideas, >>>>> >>>>> Andreas >>>>> >>>>> -- >>>>> Andreas Plesch >>>>> Waltham, MA 02453 >>>>> _______________________________________________ >>>>> x3d-public mailing list >>>>> x3d-public at web3d.org >>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> x3d-public mailing list >>>>> x3d-public at web3d.org >>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>>> >>>>> >>>>> _______________________________________________ >>>>> x3d-public mailing list >>>>> x3d-public at web3d.org >>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>> >>>> >>> >>> -- >>> Andreas Plesch >>> Waltham, MA 02453 >>> >>> >>> >> > > > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Thu Feb 20 11:52:53 2025 From: yottzumm at gmail.com (John Carlson) Date: Thu, 20 Feb 2025 13:52:53 -0600 Subject: [x3d-public] HAnimDisplacer effect on coord.point In-Reply-To: References: <215C055A-411D-4C08-9BE3-F3F4AC63E839@yahoo.de> Message-ID: I?ve been creating zips with jar for years, and also unpacking them with unzip on Linux, I think. I can spin up a virtual machine or WSL to investigate, if people continue to have issues. 7zip or renaming file to .jar might work too. Don?t use the java command. Typically, I would use unzip. If you tell me what unarchiver you use, I can do more research. I will spend some effort trying to duplicate the issue. I?m not seeing any that says you won?t be able to unzip a jar file with standard zip utilities. John On Thu, Feb 20, 2025 at 1:16?PM John Carlson wrote: > Did you try the unzip program? The jar/zip could be corrupted? Vince > also had a similar issues with my jars/zips. > > John > > On Thu, Feb 20, 2025 at 11:43?AM Holger Seelig via x3d-public < > x3d-public at web3d.org> wrote: > >> No. It should be your intention to provide files everyone can open. A ZIP >> file shouldn?t be so difficult today. >> >> Holger >> >> -- >> Holger Seelig >> Leipzig, Germany >> >> holger.seelig at yahoo.de >> https://create3000.github.io/x_ite/ >> >> Am 20.02.2025 um 00:24 schrieb John Carlson : >> >> Attached is an example with a Hud. I can't get the menu (with the Hud >> ProximitySensor and Transforms) to move differently than Jin, so I'm kind >> of stuck. >> >> There's probably some silly problem that I missed. The menus move >> with the mouse. >> >> Thanks for looking, >> >> John >> >> On Tue, Feb 18, 2025 at 6:49?PM John Carlson wrote: >> >>> Thanks for code samples, Joe. It looks like I can take out my >>> Layering/Layout code and just focus on the menu. Sorry I am so slow on >>> this, I think I might be hibernating. >>> >>> I?m looking at my GitHub commits and they have dropped drastically. >>> This might be because I am spending more time helping others with recovery >>> or just using social media too much. >>> >>> I will try to get to the HUD in the next two days. It was so cold, we >>> didn?t even go to the dentist 45 miles away. We got out today though. >>> >>> John >>> >>> On Tue, Feb 18, 2025 at 6:38?PM Joe D Williams >>> wrote: >>> >>>> > a HUD for Joe >>>> >>>> >>>> A hud for the FACS example is needed because any navigation causes the >>>> menu to disappear. The menu can be just like used on the Jin scaled with >>>> animation example. However that uses a ProximitySensor which x3dom does not >>>> support, for some reason. We use that a lot for start timers, timers, >>>> etc.as well as being the typical way to keep a menu or scene data in >>>> view. >>>> If HTML/SVG is better, I have not seen it. I don't think Stacking >>>> canvas is appropriate. Fine to think of XR for in-world 2d or3d HUDS but >>>> does that sort ofdisplay really work any different than using prox sensor? >>>> ProximitySensor is just so basic. >>>> >>>> >>>> >>>> >>>> >>>> rest of menu >>>> >>> toField='set_translation' toNode='HudXform'/> >>>> >>> toField='set_rotation' toNode='HudXform'/> >>>> >>>> >>>> Thanks and Best, >>>> Joe >>>> >>>> >>>> huds3d >>>> XR >>>> >>>> -----Original Message----- >>>> From: Andreas Plesch >>>> Sent: Feb 18, 2025 11:45 AM >>>> To: John Carlson >>>> Cc: Extensible 3D (X3D) Graphics public discussion < >>>> x3d-public at web3d.org>, Holger Seelig , Joseph >>>> D Williams , Brutzman, Donald (Don) (CIV) < >>>> brutzman at nps.edu>, Carol McDonald >>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>> >>>> >>>> Please do not wait for x3dom. Both ProximitySensor and the Layering >>>> component are lower priority. HTML/SVG is better suited for 2D HUDs and >>>> layering can be approximated by stacking multiple X3D canvases/scenes. You >>>> may also consider XR where immersion typically strongly favors in-world 3d >>>> HUDs. >>>> >>>> Best, -Andreas >>>> >>>> On Tue, Feb 18, 2025 at 2:25?PM John Carlson >>>> wrote: >>>> >>>>> Don, we?re currently working on a HUD for Joe, I don?t currently have >>>>> an online example of that. >>>>> >>>>> Otherwise, I?m waiting on someone deciding which meshes to merge. I >>>>> could take the lead on this. >>>>> >>>>> I could use a tutorial on the Layering and Layout components, examples >>>>> don?t seem to help. I may try to adopt a 3D HUD based on examples. >>>>> Something with the 2D overlay in WORLD space would help tremendously, or >>>>> some conversion from WORLD space. >>>>> >>>>> We already have 3D menus, so a 3D HUD might be easiest. >>>>> >>>>> Thanks, >>>>> >>>>> John >>>>> On Mon, Feb 17, 2025 at 11:18?PM Brutzman, Donald (Don) (CIV) via >>>>> x3d-public wrote: >>>>> >>>>>> Wondering, do we have a simple excerpted example that we can look at >>>>>> yet? That will help guide these discussions. >>>>>> >>>>>> Don't need a full human body animation in all its displaceable >>>>>> glory... >>>>>> >>>>>> >>>>>> 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 >>>>>> https://faculty.nps.edu/brutzman >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------ >>>>>> *From:* x3d-public on behalf of Joe D >>>>>> Williams via x3d-public >>>>>> *Sent:* Saturday, February 15, 2025 6:55 PM >>>>>> *To:* Holger Seelig ; Andreas Plesch < >>>>>> andreasplesch at gmail.com> >>>>>> *Cc:* joedwil at earthlink.net ; X3D < >>>>>> x3d-public at web3d.org>; Carol McDonald >>>>>> >>>>>> *Subject:* Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>>> >>>>>> > coord.point changes are very very expensive quickly, >>>>>> >>>>>> >>>>>> Right, the processing time gets expensive as the number of points >>>>>> moved. >>>>>> If level 1 segment geometry where the mesh is driven directly by a >>>>>> joint, then it easier since weight is always 1. >>>>>> For level 2 skin, the the weight (radial movement) applied by maybe >>>>>> multiple joints needs to be computed for each point. >>>>>> Finally, for both levels, the displacements for selected set of >>>>>> points needs to be applied. >>>>>> This implies multiple passes on the subject coordinates? >>>>>> Whatever, these operations are common where the applications deal >>>>>> with >>>>>> a complete mesh and with sparse points of a mesh for blending. . >>>>>> >>>>>> >>>>>> > with reference to CoordinateInterpolator, >>>>>> >>>>>> >>>>>> These are useful when controlling all points of a target mesh. >>>>>> All points of a mesh must be included and same number of points at >>>>>> each keyframe. >>>>>> This style was used in first step of the current example x3d FACS >>>>>> because >>>>>> face geometry is made from multiple shapes. CoordinateInterpolater >>>>>> sets >>>>>> for each shape for each elemental action moved the points. >>>>>> This was simplified to using the same face for each action example >>>>>> and then replaced the CIs with sets of Displacers. >>>>>> Now have developed further to combine individual actions to make a >>>>>> specific expression which consists of multiple elemental movements. >>>>>> However, I think we want to evolve towards a basic single mesh face >>>>>> with some individual shapes for like teeth, hair, eyeballs, eyelids, >>>>>> tongue, maybe ears? >>>>>> and using joint nodes to control, where appropriate. >>>>>> >>>>>> >>>>>> Regardless of how the points are moved for the next frame, it has to >>>>>> be >>>>>> considered that geometry points will be moved directly by joint >>>>>> rotations, >>>>>> by a weighting algorithm using multiple joint rotation inputs, >>>>>> and by one or more scalar-driven Displacer inputs. >>>>>> >>>>>> >>>>>> Thanks for HAnim, >>>>>> Joe >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -----Message----- >>>>>> From: Holger Seelig >>>>>> Sent: Feb 9, 2025 11:23 AM >>>>>> To: Andreas Plesch >>>>>> Cc: X3D , Joseph D Williams < >>>>>> joedwil at earthlink.net>, Carol McDonald >>>>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>>> >>>>>> >>>>>> I don't think so, coord.point changes are very very expensive >>>>>> quickly, and as Michalis said earlier, with reference to >>>>>> CoordinateInterpolator, we should get rid of them. >>>>>> >>>>>> Holger >>>>>> -- >>>>>> Holger Seelig >>>>>> Leipzig, Germany >>>>>> >>>>>> holger.seelig at yahoo.de >>>>>> https://create3000.github.io/x_ite/ >>>>>> >>>>>> Am 09.02.2025 um 19:44 schrieb Andreas Plesch < >>>>>> andreasplesch at gmail.com>: >>>>>> Yes, that is an option. However,coord.point changes are very very >>>>>> expensive quickly, and as Michalis said earlier, with reference to >>>>>> CoordinateInterpolator, we should get rid of them. >>>>>> >>>>>> Andreas >>>>>> >>>>>> On Sun, Feb 9, 2025, 1:40?PM Holger Seelig >>>>>> wrote: >>>>>> >>>>>> X_ITE applies the HAnimDisplacers in the shader, thus no coord.point >>>>>> field has to be changed. >>>>>> Maybe that helps. >>>>>> >>>>>> Best regards, >>>>>> Holger >>>>>> >>>>>> -- >>>>>> Holger Seelig >>>>>> Leipzig, Germany >>>>>> >>>>>> holger.seelig at yahoo.de >>>>>> https://create3000.github.io/x_ite/ >>>>>> >>>>>> Am 09.02.2025 um 19:33 schrieb Andreas Plesch via x3d-public < >>>>>> x3d-public at web3d.org>: >>>>>> >>>>>> That would be the point field of a Coordinate node >>>>>> >>>>>> >>>>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/rendering.html#Coordinate >>>>>> >>>>>> which is used by the coord field of >>>>>> >>>>>> >>>>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimSegment >>>>>> >>>>>> Andreas >>>>>> >>>>>> On Sun, Feb 9, 2025, 12:36?PM Joe D Williams >>>>>> wrote: >>>>>> >>>>>> > coord node emit a point_changed event >>>>>> >>>>>> >>>>>> sorry,I don't see a field anywhere with that event. Displacer is >>>>>> likely to change several points when new weight is sent. All part of the >>>>>> cascade to produce the changed mesh? >>>>>> Thanks, >>>>>> Joe >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Andreas Plesch >>>>>> Sent: Feb 9, 2025 4:25 AM >>>>>> To: Brutzman, Donald (Don) (CIV) >>>>>> Cc: Extensible 3D (X3D) Graphics public discussion < >>>>>> x3d-public at web3d.org>, Carol McDonald , Joe D >>>>>> Williams , John Carlson >>>>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>>> >>>>>> >>>>>> Don, Joe and John >>>>>> >>>>>> Thanks for collecting these references. >>>>>> >>>>>> But I am not sure if there is an answer to my original question. Let >>>>>> me rephrase a bit the question: >>>>>> >>>>>> After a Displacer contained in a Segment node receives a set_weight >>>>>> input, should then the coord node emit a point_changed event ? >>>>>> >>>>>> I do not think HAnim is concerned about that, so it is really a X3D >>>>>> question. >>>>>> >>>>>> Thanks, Andreas >>>>>> >>>>>> On Sun, Feb 9, 2025, 12:49?AM Brutzman, Donald (Don) (CIV) < >>>>>> brutzman at nps.edu> wrote: >>>>>> >>>>>> Thanks for pointing in the right direction John. >>>>>> >>>>>> Direct links to functional requirements for Displacer in HAnim 2.0 >>>>>> specification: >>>>>> >>>>>> - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, >>>>>> Clause 4 Concepts, 4.7 Displacer object >>>>>> - >>>>>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#DisplacerObject >>>>>> >>>>>> - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, >>>>>> Clause 6 Object interfaces, 6.6 Displacer >>>>>> - >>>>>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer >>>>>> >>>>>> and >>>>>> >>>>>> - X3D 4.0 Architecture, Clause 26 Humanoid Animation (HAnim) >>>>>> component, 26.3.1 HAnimDisplacer >>>>>> - >>>>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimDisplacer >>>>>> >>>>>> and informative >>>>>> >>>>>> - X3D Tooltips, HAnimDisplacer >>>>>> - >>>>>> https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimDisplacer >>>>>> >>>>>> Thanks for implementation efforts and careful scrutiny. >>>>>> >>>>>> Questions and potential issues/clarifications/corrections are always >>>>>> welcome. >>>>>> >>>>>> >>>>>> 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 >>>>>> https://faculty.nps.edu/brutzman >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------ >>>>>> *From:* x3d-public on behalf of John >>>>>> Carlson via x3d-public >>>>>> *Sent:* Saturday, February 8, 2025 3:43 AM >>>>>> *To:* Extensible 3D (X3D) Graphics public discussion < >>>>>> x3d-public at web3d.org>; Carol McDonald ; Joe D >>>>>> Williams >>>>>> *Cc:* John Carlson ; Andreas Plesch < >>>>>> andreasplesch at gmail.com> >>>>>> *Subject:* Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>>> >>>>>> Here?s what HAnim spec says under Displacer: >>>>>> >>>>>> https://www.web3d.org/documents/specifications/19774/V2.0/index.html >>>>>> >>>>>> ?For the *Displacer* objects that are contained in the *displacers* field >>>>>> of the *Segment* objects, the *displacements* are defined and >>>>>> applied in the *Segment* coordinate system. The base mesh for the >>>>>> morphed *Segment* is the original mesh defined in the *Segment*.? >>>>>> >>>>>> And here?s what it says under Segment: >>>>>> >>>>>> ? >>>>>> >>>>>> The *coord* field is used for *Segment* objects that have deformable >>>>>> meshes and shall contain coordinates referenced from the indexed mesh for >>>>>> the *Segment* object. The coordinates are given the same name as the >>>>>> *Segment* object, but with a "_coords" appended (e.g.,"skull_coords" >>>>>> ).? >>>>>> displacements are an offset from the mesh, with weight from 0 to 1. >>>>>> So weight times displacement is total offset from base mesh. 0 weight = no >>>>>> offset, 1 weight = full displacements offset >>>>>> >>>>>> The Coordinate point is maintained to handle weight = 0. Weight >>>>>> ranges from 0 to 1, but double check. >>>>>> >>>>>> Joe or Carol might know where to find it in the HAnim spec. >>>>>> >>>>>> I believe the answer is, ?during rendering,?. Since weight can vary >>>>>> with animation, and so can displacements, AFAIK. More than one displacer >>>>>> can be applied to the mesh. >>>>>> >>>>>> I have not read the spec. >>>>>> >>>>>> John >>>>>> >>>>>> >>>>>> >>>>>> On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public < >>>>>> x3d-public at web3d.org> wrote: >>>>>> >>>>>> >>>>>> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer >>>>>> >>>>>> does not directly explain what the effect of the displacer on the >>>>>> coord.point field of the containing HAnimSegment is. But it mentions the >>>>>> coord.point field and seems to imply that the coord.point field is involved. >>>>>> >>>>>> So the question is if the Displacer should alter the coord.point >>>>>> field in order to achieve a graphical displacement, or if the Browser >>>>>> should only apply the displacements during rendering without a change in >>>>>> the coord.point field ? >>>>>> >>>>>> This is relevant if the coord.point field is accessed by routes or >>>>>> scripts, in addition to displacers. >>>>>> >>>>>> Thanks for any feedback or ideas, >>>>>> >>>>>> Andreas >>>>>> >>>>>> -- >>>>>> Andreas Plesch >>>>>> Waltham, MA 02453 >>>>>> _______________________________________________ >>>>>> x3d-public mailing list >>>>>> x3d-public at web3d.org >>>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> x3d-public mailing list >>>>>> x3d-public at web3d.org >>>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> x3d-public mailing list >>>>>> x3d-public at web3d.org >>>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>>> >>>>> >>>> >>>> -- >>>> Andreas Plesch >>>> Waltham, MA 02453 >>>> >>>> >>>> >>> >> >> >> _______________________________________________ >> x3d-public mailing list >> x3d-public at web3d.org >> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Thu Feb 20 12:17:06 2025 From: yottzumm at gmail.com (John Carlson) Date: Thu, 20 Feb 2025 14:17:06 -0600 Subject: [x3d-public] HAnimDisplacer effect on coord.point In-Reply-To: <36E93FD5-C4F6-44DA-B202-B48E1CFA724B@yahoo.de> References: <36E93FD5-C4F6-44DA-B202-B48E1CFA724B@yahoo.de> Message-ID: I guess there could be some weird encoding or formatting issue. I use GitHub Bash inside Windows Terminal, I don?t know if I am encoding with Cp1252 or something Windows specific. I?ll do more research. On Thu, Feb 20, 2025 at 7:19?AM Holger Seelig via x3d-public < x3d-public at web3d.org> wrote: > For some reason I cannot open those *.zip files from you John. My system > say ?Unknown file format?. > > Best regards, > Holger > > -- > Holger Seelig > Leipzig, Germany > > holger.seelig at yahoo.de > https://create3000.github.io/x_ite/ > > Am 20.02.2025 um 00:24 schrieb John Carlson : > > Attached is an example with a Hud. I can't get the menu (with the Hud > ProximitySensor and Transforms) to move differently than Jin, so I'm kind > of stuck. > > There's probably some silly problem that I missed. The menus move > with the mouse. > > Thanks for looking, > > John > > On Tue, Feb 18, 2025 at 6:49?PM John Carlson wrote: > >> Thanks for code samples, Joe. It looks like I can take out my >> Layering/Layout code and just focus on the menu. Sorry I am so slow on >> this, I think I might be hibernating. >> >> I?m looking at my GitHub commits and they have dropped drastically. This >> might be because I am spending more time helping others with recovery or >> just using social media too much. >> >> I will try to get to the HUD in the next two days. It was so cold, we >> didn?t even go to the dentist 45 miles away. We got out today though. >> >> John >> >> On Tue, Feb 18, 2025 at 6:38?PM Joe D Williams >> wrote: >> >>> > a HUD for Joe >>> >>> >>> A hud for the FACS example is needed because any navigation causes the >>> menu to disappear. The menu can be just like used on the Jin scaled with >>> animation example. However that uses a ProximitySensor which x3dom does not >>> support, for some reason. We use that a lot for start timers, timers, >>> etc.as well as being the typical way to keep a menu or scene data in >>> view. >>> If HTML/SVG is better, I have not seen it. I don't think Stacking >>> canvas is appropriate. Fine to think of XR for in-world 2d or3d HUDS but >>> does that sort ofdisplay really work any different than using prox sensor? >>> ProximitySensor is just so basic. >>> >>> >>> >>> >>> >>> rest of menu >>> >> toField='set_translation' toNode='HudXform'/> >>> >> toField='set_rotation' toNode='HudXform'/> >>> >>> >>> Thanks and Best, >>> Joe >>> >>> >>> huds3d >>> XR >>> >>> -----Original Message----- >>> From: Andreas Plesch >>> Sent: Feb 18, 2025 11:45 AM >>> To: John Carlson >>> Cc: Extensible 3D (X3D) Graphics public discussion , >>> Holger Seelig , Joseph D Williams < >>> joedwil at earthlink.net>, Brutzman, Donald (Don) (CIV) , >>> Carol McDonald >>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>> >>> >>> Please do not wait for x3dom. Both ProximitySensor and the Layering >>> component are lower priority. HTML/SVG is better suited for 2D HUDs and >>> layering can be approximated by stacking multiple X3D canvases/scenes. You >>> may also consider XR where immersion typically strongly favors in-world 3d >>> HUDs. >>> >>> Best, -Andreas >>> >>> On Tue, Feb 18, 2025 at 2:25?PM John Carlson wrote: >>> >>>> Don, we?re currently working on a HUD for Joe, I don?t currently have >>>> an online example of that. >>>> >>>> Otherwise, I?m waiting on someone deciding which meshes to merge. I >>>> could take the lead on this. >>>> >>>> I could use a tutorial on the Layering and Layout components, examples >>>> don?t seem to help. I may try to adopt a 3D HUD based on examples. >>>> Something with the 2D overlay in WORLD space would help tremendously, or >>>> some conversion from WORLD space. >>>> >>>> We already have 3D menus, so a 3D HUD might be easiest. >>>> >>>> Thanks, >>>> >>>> John >>>> On Mon, Feb 17, 2025 at 11:18?PM Brutzman, Donald (Don) (CIV) via >>>> x3d-public wrote: >>>> >>>>> Wondering, do we have a simple excerpted example that we can look at >>>>> yet? That will help guide these discussions. >>>>> >>>>> Don't need a full human body animation in all its displaceable glory... >>>>> >>>>> >>>>> 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 >>>>> https://faculty.nps.edu/brutzman >>>>> >>>>> >>>>> >>>>> ------------------------------ >>>>> *From:* x3d-public on behalf of Joe D >>>>> Williams via x3d-public >>>>> *Sent:* Saturday, February 15, 2025 6:55 PM >>>>> *To:* Holger Seelig ; Andreas Plesch < >>>>> andreasplesch at gmail.com> >>>>> *Cc:* joedwil at earthlink.net ; X3D < >>>>> x3d-public at web3d.org>; Carol McDonald >>>>> >>>>> *Subject:* Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>> >>>>> > coord.point changes are very very expensive quickly, >>>>> >>>>> >>>>> Right, the processing time gets expensive as the number of points >>>>> moved. >>>>> If level 1 segment geometry where the mesh is driven directly by a >>>>> joint, then it easier since weight is always 1. >>>>> For level 2 skin, the the weight (radial movement) applied by maybe >>>>> multiple joints needs to be computed for each point. >>>>> Finally, for both levels, the displacements for selected set of points >>>>> needs to be applied. >>>>> This implies multiple passes on the subject coordinates? >>>>> Whatever, these operations are common where the applications deal with >>>>> a complete mesh and with sparse points of a mesh for blending. . >>>>> >>>>> >>>>> > with reference to CoordinateInterpolator, >>>>> >>>>> >>>>> These are useful when controlling all points of a target mesh. >>>>> All points of a mesh must be included and same number of points at >>>>> each keyframe. >>>>> This style was used in first step of the current example x3d FACS >>>>> because >>>>> face geometry is made from multiple shapes. CoordinateInterpolater >>>>> sets >>>>> for each shape for each elemental action moved the points. >>>>> This was simplified to using the same face for each action example >>>>> and then replaced the CIs with sets of Displacers. >>>>> Now have developed further to combine individual actions to make a >>>>> specific expression which consists of multiple elemental movements. >>>>> However, I think we want to evolve towards a basic single mesh face >>>>> with some individual shapes for like teeth, hair, eyeballs, eyelids, >>>>> tongue, maybe ears? >>>>> and using joint nodes to control, where appropriate. >>>>> >>>>> >>>>> Regardless of how the points are moved for the next frame, it has to >>>>> be >>>>> considered that geometry points will be moved directly by joint >>>>> rotations, >>>>> by a weighting algorithm using multiple joint rotation inputs, >>>>> and by one or more scalar-driven Displacer inputs. >>>>> >>>>> >>>>> Thanks for HAnim, >>>>> Joe >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -----Message----- >>>>> From: Holger Seelig >>>>> Sent: Feb 9, 2025 11:23 AM >>>>> To: Andreas Plesch >>>>> Cc: X3D , Joseph D Williams < >>>>> joedwil at earthlink.net>, Carol McDonald >>>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>> >>>>> >>>>> I don't think so, coord.point changes are very very expensive quickly, >>>>> and as Michalis said earlier, with reference to CoordinateInterpolator, we >>>>> should get rid of them. >>>>> >>>>> Holger >>>>> -- >>>>> Holger Seelig >>>>> Leipzig, Germany >>>>> >>>>> holger.seelig at yahoo.de >>>>> https://create3000.github.io/x_ite/ >>>>> >>>>> Am 09.02.2025 um 19:44 schrieb Andreas Plesch >>>> >: >>>>> Yes, that is an option. However,coord.point changes are very very >>>>> expensive quickly, and as Michalis said earlier, with reference to >>>>> CoordinateInterpolator, we should get rid of them. >>>>> >>>>> Andreas >>>>> >>>>> On Sun, Feb 9, 2025, 1:40?PM Holger Seelig >>>>> wrote: >>>>> >>>>> X_ITE applies the HAnimDisplacers in the shader, thus no coord.point >>>>> field has to be changed. >>>>> Maybe that helps. >>>>> >>>>> Best regards, >>>>> Holger >>>>> >>>>> -- >>>>> Holger Seelig >>>>> Leipzig, Germany >>>>> >>>>> holger.seelig at yahoo.de >>>>> https://create3000.github.io/x_ite/ >>>>> >>>>> Am 09.02.2025 um 19:33 schrieb Andreas Plesch via x3d-public < >>>>> x3d-public at web3d.org>: >>>>> >>>>> That would be the point field of a Coordinate node >>>>> >>>>> >>>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/rendering.html#Coordinate >>>>> >>>>> which is used by the coord field of >>>>> >>>>> >>>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimSegment >>>>> >>>>> Andreas >>>>> >>>>> On Sun, Feb 9, 2025, 12:36?PM Joe D Williams >>>>> wrote: >>>>> >>>>> > coord node emit a point_changed event >>>>> >>>>> >>>>> sorry,I don't see a field anywhere with that event. Displacer is >>>>> likely to change several points when new weight is sent. All part of the >>>>> cascade to produce the changed mesh? >>>>> Thanks, >>>>> Joe >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Andreas Plesch >>>>> Sent: Feb 9, 2025 4:25 AM >>>>> To: Brutzman, Donald (Don) (CIV) >>>>> Cc: Extensible 3D (X3D) Graphics public discussion < >>>>> x3d-public at web3d.org>, Carol McDonald , Joe D >>>>> Williams , John Carlson >>>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>> >>>>> >>>>> Don, Joe and John >>>>> >>>>> Thanks for collecting these references. >>>>> >>>>> But I am not sure if there is an answer to my original question. Let >>>>> me rephrase a bit the question: >>>>> >>>>> After a Displacer contained in a Segment node receives a set_weight >>>>> input, should then the coord node emit a point_changed event ? >>>>> >>>>> I do not think HAnim is concerned about that, so it is really a X3D >>>>> question. >>>>> >>>>> Thanks, Andreas >>>>> >>>>> On Sun, Feb 9, 2025, 12:49?AM Brutzman, Donald (Don) (CIV) < >>>>> brutzman at nps.edu> wrote: >>>>> >>>>> Thanks for pointing in the right direction John. >>>>> >>>>> Direct links to functional requirements for Displacer in HAnim 2.0 >>>>> specification: >>>>> >>>>> - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, >>>>> Clause 4 Concepts, 4.7 Displacer object >>>>> - >>>>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#DisplacerObject >>>>> >>>>> - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, >>>>> Clause 6 Object interfaces, 6.6 Displacer >>>>> - >>>>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer >>>>> >>>>> and >>>>> >>>>> - X3D 4.0 Architecture, Clause 26 Humanoid Animation (HAnim) >>>>> component, 26.3.1 HAnimDisplacer >>>>> - >>>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimDisplacer >>>>> >>>>> and informative >>>>> >>>>> - X3D Tooltips, HAnimDisplacer >>>>> - https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimDisplacer >>>>> >>>>> Thanks for implementation efforts and careful scrutiny. >>>>> >>>>> Questions and potential issues/clarifications/corrections are always >>>>> welcome. >>>>> >>>>> >>>>> 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 >>>>> https://faculty.nps.edu/brutzman >>>>> >>>>> >>>>> >>>>> ------------------------------ >>>>> *From:* x3d-public on behalf of John >>>>> Carlson via x3d-public >>>>> *Sent:* Saturday, February 8, 2025 3:43 AM >>>>> *To:* Extensible 3D (X3D) Graphics public discussion < >>>>> x3d-public at web3d.org>; Carol McDonald ; Joe D >>>>> Williams >>>>> *Cc:* John Carlson ; Andreas Plesch < >>>>> andreasplesch at gmail.com> >>>>> *Subject:* Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>> >>>>> Here?s what HAnim spec says under Displacer: >>>>> >>>>> https://www.web3d.org/documents/specifications/19774/V2.0/index.html >>>>> >>>>> ?For the *Displacer* objects that are contained in the *displacers* field >>>>> of the *Segment* objects, the *displacements* are defined and applied >>>>> in the *Segment* coordinate system. The base mesh for the morphed >>>>> *Segment* is the original mesh defined in the *Segment*.? >>>>> >>>>> And here?s what it says under Segment: >>>>> >>>>> ? >>>>> >>>>> The *coord* field is used for *Segment* objects that have deformable >>>>> meshes and shall contain coordinates referenced from the indexed mesh for >>>>> the *Segment* object. The coordinates are given the same name as the >>>>> *Segment* object, but with a "_coords" appended (e.g.,"skull_coords" >>>>> ).? >>>>> displacements are an offset from the mesh, with weight from 0 to 1. >>>>> So weight times displacement is total offset from base mesh. 0 weight = no >>>>> offset, 1 weight = full displacements offset >>>>> >>>>> The Coordinate point is maintained to handle weight = 0. Weight >>>>> ranges from 0 to 1, but double check. >>>>> >>>>> Joe or Carol might know where to find it in the HAnim spec. >>>>> >>>>> I believe the answer is, ?during rendering,?. Since weight can vary >>>>> with animation, and so can displacements, AFAIK. More than one displacer >>>>> can be applied to the mesh. >>>>> >>>>> I have not read the spec. >>>>> >>>>> John >>>>> >>>>> >>>>> >>>>> On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public < >>>>> x3d-public at web3d.org> wrote: >>>>> >>>>> >>>>> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer >>>>> >>>>> does not directly explain what the effect of the displacer on the >>>>> coord.point field of the containing HAnimSegment is. But it mentions the >>>>> coord.point field and seems to imply that the coord.point field is involved. >>>>> >>>>> So the question is if the Displacer should alter the coord.point field >>>>> in order to achieve a graphical displacement, or if the Browser should only >>>>> apply the displacements during rendering without a change in the >>>>> coord.point field ? >>>>> >>>>> This is relevant if the coord.point field is accessed by routes or >>>>> scripts, in addition to displacers. >>>>> >>>>> Thanks for any feedback or ideas, >>>>> >>>>> Andreas >>>>> >>>>> -- >>>>> Andreas Plesch >>>>> Waltham, MA 02453 >>>>> _______________________________________________ >>>>> x3d-public mailing list >>>>> x3d-public at web3d.org >>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> x3d-public mailing list >>>>> x3d-public at web3d.org >>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>>> >>>>> >>>>> _______________________________________________ >>>>> x3d-public mailing list >>>>> x3d-public at web3d.org >>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>> >>>> >>> >>> -- >>> Andreas Plesch >>> Waltham, MA 02453 >>> >>> >>> >> > > > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Thu Feb 20 12:23:25 2025 From: yottzumm at gmail.com (John Carlson) Date: Thu, 20 Feb 2025 14:23:25 -0600 Subject: [x3d-public] HAnimDisplacer effect on coord.point In-Reply-To: References: <36E93FD5-C4F6-44DA-B202-B48E1CFA724B@yahoo.de> Message-ID: I will try to use Windows Explorer to create zips in the future. Ugh! If there?s an agreement to use 7z as a community, I can swap to that. John On Thu, Feb 20, 2025 at 2:17?PM John Carlson wrote: > I guess there could be some weird encoding or formatting issue. I use > GitHub Bash inside Windows Terminal, I don?t know if I am encoding with > Cp1252 or something Windows specific. I?ll do more research. > > On Thu, Feb 20, 2025 at 7:19?AM Holger Seelig via x3d-public < > x3d-public at web3d.org> wrote: > >> For some reason I cannot open those *.zip files from you John. My system >> say ?Unknown file format?. >> >> Best regards, >> Holger >> >> -- >> Holger Seelig >> Leipzig, Germany >> >> holger.seelig at yahoo.de >> https://create3000.github.io/x_ite/ >> >> Am 20.02.2025 um 00:24 schrieb John Carlson : >> >> Attached is an example with a Hud. I can't get the menu (with the Hud >> ProximitySensor and Transforms) to move differently than Jin, so I'm kind >> of stuck. >> >> There's probably some silly problem that I missed. The menus move >> with the mouse. >> >> Thanks for looking, >> >> John >> >> On Tue, Feb 18, 2025 at 6:49?PM John Carlson wrote: >> >>> Thanks for code samples, Joe. It looks like I can take out my >>> Layering/Layout code and just focus on the menu. Sorry I am so slow on >>> this, I think I might be hibernating. >>> >>> I?m looking at my GitHub commits and they have dropped drastically. >>> This might be because I am spending more time helping others with recovery >>> or just using social media too much. >>> >>> I will try to get to the HUD in the next two days. It was so cold, we >>> didn?t even go to the dentist 45 miles away. We got out today though. >>> >>> John >>> >>> On Tue, Feb 18, 2025 at 6:38?PM Joe D Williams >>> wrote: >>> >>>> > a HUD for Joe >>>> >>>> >>>> A hud for the FACS example is needed because any navigation causes the >>>> menu to disappear. The menu can be just like used on the Jin scaled with >>>> animation example. However that uses a ProximitySensor which x3dom does not >>>> support, for some reason. We use that a lot for start timers, timers, >>>> etc.as well as being the typical way to keep a menu or scene data in >>>> view. >>>> If HTML/SVG is better, I have not seen it. I don't think Stacking >>>> canvas is appropriate. Fine to think of XR for in-world 2d or3d HUDS but >>>> does that sort ofdisplay really work any different than using prox sensor? >>>> ProximitySensor is just so basic. >>>> >>>> >>>> >>>> >>>> >>>> rest of menu >>>> >>> toField='set_translation' toNode='HudXform'/> >>>> >>> toField='set_rotation' toNode='HudXform'/> >>>> >>>> >>>> Thanks and Best, >>>> Joe >>>> >>>> >>>> huds3d >>>> XR >>>> >>>> -----Original Message----- >>>> From: Andreas Plesch >>>> Sent: Feb 18, 2025 11:45 AM >>>> To: John Carlson >>>> Cc: Extensible 3D (X3D) Graphics public discussion < >>>> x3d-public at web3d.org>, Holger Seelig , Joseph >>>> D Williams , Brutzman, Donald (Don) (CIV) < >>>> brutzman at nps.edu>, Carol McDonald >>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>> >>>> >>>> Please do not wait for x3dom. Both ProximitySensor and the Layering >>>> component are lower priority. HTML/SVG is better suited for 2D HUDs and >>>> layering can be approximated by stacking multiple X3D canvases/scenes. You >>>> may also consider XR where immersion typically strongly favors in-world 3d >>>> HUDs. >>>> >>>> Best, -Andreas >>>> >>>> On Tue, Feb 18, 2025 at 2:25?PM John Carlson >>>> wrote: >>>> >>>>> Don, we?re currently working on a HUD for Joe, I don?t currently have >>>>> an online example of that. >>>>> >>>>> Otherwise, I?m waiting on someone deciding which meshes to merge. I >>>>> could take the lead on this. >>>>> >>>>> I could use a tutorial on the Layering and Layout components, examples >>>>> don?t seem to help. I may try to adopt a 3D HUD based on examples. >>>>> Something with the 2D overlay in WORLD space would help tremendously, or >>>>> some conversion from WORLD space. >>>>> >>>>> We already have 3D menus, so a 3D HUD might be easiest. >>>>> >>>>> Thanks, >>>>> >>>>> John >>>>> On Mon, Feb 17, 2025 at 11:18?PM Brutzman, Donald (Don) (CIV) via >>>>> x3d-public wrote: >>>>> >>>>>> Wondering, do we have a simple excerpted example that we can look at >>>>>> yet? That will help guide these discussions. >>>>>> >>>>>> Don't need a full human body animation in all its displaceable >>>>>> glory... >>>>>> >>>>>> >>>>>> 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 >>>>>> https://faculty.nps.edu/brutzman >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------ >>>>>> *From:* x3d-public on behalf of Joe D >>>>>> Williams via x3d-public >>>>>> *Sent:* Saturday, February 15, 2025 6:55 PM >>>>>> *To:* Holger Seelig ; Andreas Plesch < >>>>>> andreasplesch at gmail.com> >>>>>> *Cc:* joedwil at earthlink.net ; X3D < >>>>>> x3d-public at web3d.org>; Carol McDonald >>>>>> >>>>>> *Subject:* Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>>> >>>>>> > coord.point changes are very very expensive quickly, >>>>>> >>>>>> >>>>>> Right, the processing time gets expensive as the number of points >>>>>> moved. >>>>>> If level 1 segment geometry where the mesh is driven directly by a >>>>>> joint, then it easier since weight is always 1. >>>>>> For level 2 skin, the the weight (radial movement) applied by maybe >>>>>> multiple joints needs to be computed for each point. >>>>>> Finally, for both levels, the displacements for selected set of >>>>>> points needs to be applied. >>>>>> This implies multiple passes on the subject coordinates? >>>>>> Whatever, these operations are common where the applications deal >>>>>> with >>>>>> a complete mesh and with sparse points of a mesh for blending. . >>>>>> >>>>>> >>>>>> > with reference to CoordinateInterpolator, >>>>>> >>>>>> >>>>>> These are useful when controlling all points of a target mesh. >>>>>> All points of a mesh must be included and same number of points at >>>>>> each keyframe. >>>>>> This style was used in first step of the current example x3d FACS >>>>>> because >>>>>> face geometry is made from multiple shapes. CoordinateInterpolater >>>>>> sets >>>>>> for each shape for each elemental action moved the points. >>>>>> This was simplified to using the same face for each action example >>>>>> and then replaced the CIs with sets of Displacers. >>>>>> Now have developed further to combine individual actions to make a >>>>>> specific expression which consists of multiple elemental movements. >>>>>> However, I think we want to evolve towards a basic single mesh face >>>>>> with some individual shapes for like teeth, hair, eyeballs, eyelids, >>>>>> tongue, maybe ears? >>>>>> and using joint nodes to control, where appropriate. >>>>>> >>>>>> >>>>>> Regardless of how the points are moved for the next frame, it has to >>>>>> be >>>>>> considered that geometry points will be moved directly by joint >>>>>> rotations, >>>>>> by a weighting algorithm using multiple joint rotation inputs, >>>>>> and by one or more scalar-driven Displacer inputs. >>>>>> >>>>>> >>>>>> Thanks for HAnim, >>>>>> Joe >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -----Message----- >>>>>> From: Holger Seelig >>>>>> Sent: Feb 9, 2025 11:23 AM >>>>>> To: Andreas Plesch >>>>>> Cc: X3D , Joseph D Williams < >>>>>> joedwil at earthlink.net>, Carol McDonald >>>>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>>> >>>>>> >>>>>> I don't think so, coord.point changes are very very expensive >>>>>> quickly, and as Michalis said earlier, with reference to >>>>>> CoordinateInterpolator, we should get rid of them. >>>>>> >>>>>> Holger >>>>>> -- >>>>>> Holger Seelig >>>>>> Leipzig, Germany >>>>>> >>>>>> holger.seelig at yahoo.de >>>>>> https://create3000.github.io/x_ite/ >>>>>> >>>>>> Am 09.02.2025 um 19:44 schrieb Andreas Plesch < >>>>>> andreasplesch at gmail.com>: >>>>>> Yes, that is an option. However,coord.point changes are very very >>>>>> expensive quickly, and as Michalis said earlier, with reference to >>>>>> CoordinateInterpolator, we should get rid of them. >>>>>> >>>>>> Andreas >>>>>> >>>>>> On Sun, Feb 9, 2025, 1:40?PM Holger Seelig >>>>>> wrote: >>>>>> >>>>>> X_ITE applies the HAnimDisplacers in the shader, thus no coord.point >>>>>> field has to be changed. >>>>>> Maybe that helps. >>>>>> >>>>>> Best regards, >>>>>> Holger >>>>>> >>>>>> -- >>>>>> Holger Seelig >>>>>> Leipzig, Germany >>>>>> >>>>>> holger.seelig at yahoo.de >>>>>> https://create3000.github.io/x_ite/ >>>>>> >>>>>> Am 09.02.2025 um 19:33 schrieb Andreas Plesch via x3d-public < >>>>>> x3d-public at web3d.org>: >>>>>> >>>>>> That would be the point field of a Coordinate node >>>>>> >>>>>> >>>>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/rendering.html#Coordinate >>>>>> >>>>>> which is used by the coord field of >>>>>> >>>>>> >>>>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimSegment >>>>>> >>>>>> Andreas >>>>>> >>>>>> On Sun, Feb 9, 2025, 12:36?PM Joe D Williams >>>>>> wrote: >>>>>> >>>>>> > coord node emit a point_changed event >>>>>> >>>>>> >>>>>> sorry,I don't see a field anywhere with that event. Displacer is >>>>>> likely to change several points when new weight is sent. All part of the >>>>>> cascade to produce the changed mesh? >>>>>> Thanks, >>>>>> Joe >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Andreas Plesch >>>>>> Sent: Feb 9, 2025 4:25 AM >>>>>> To: Brutzman, Donald (Don) (CIV) >>>>>> Cc: Extensible 3D (X3D) Graphics public discussion < >>>>>> x3d-public at web3d.org>, Carol McDonald , Joe D >>>>>> Williams , John Carlson >>>>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>>> >>>>>> >>>>>> Don, Joe and John >>>>>> >>>>>> Thanks for collecting these references. >>>>>> >>>>>> But I am not sure if there is an answer to my original question. Let >>>>>> me rephrase a bit the question: >>>>>> >>>>>> After a Displacer contained in a Segment node receives a set_weight >>>>>> input, should then the coord node emit a point_changed event ? >>>>>> >>>>>> I do not think HAnim is concerned about that, so it is really a X3D >>>>>> question. >>>>>> >>>>>> Thanks, Andreas >>>>>> >>>>>> On Sun, Feb 9, 2025, 12:49?AM Brutzman, Donald (Don) (CIV) < >>>>>> brutzman at nps.edu> wrote: >>>>>> >>>>>> Thanks for pointing in the right direction John. >>>>>> >>>>>> Direct links to functional requirements for Displacer in HAnim 2.0 >>>>>> specification: >>>>>> >>>>>> - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, >>>>>> Clause 4 Concepts, 4.7 Displacer object >>>>>> - >>>>>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#DisplacerObject >>>>>> >>>>>> - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, >>>>>> Clause 6 Object interfaces, 6.6 Displacer >>>>>> - >>>>>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer >>>>>> >>>>>> and >>>>>> >>>>>> - X3D 4.0 Architecture, Clause 26 Humanoid Animation (HAnim) >>>>>> component, 26.3.1 HAnimDisplacer >>>>>> - >>>>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimDisplacer >>>>>> >>>>>> and informative >>>>>> >>>>>> - X3D Tooltips, HAnimDisplacer >>>>>> - >>>>>> https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimDisplacer >>>>>> >>>>>> Thanks for implementation efforts and careful scrutiny. >>>>>> >>>>>> Questions and potential issues/clarifications/corrections are always >>>>>> welcome. >>>>>> >>>>>> >>>>>> 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 >>>>>> https://faculty.nps.edu/brutzman >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------ >>>>>> *From:* x3d-public on behalf of John >>>>>> Carlson via x3d-public >>>>>> *Sent:* Saturday, February 8, 2025 3:43 AM >>>>>> *To:* Extensible 3D (X3D) Graphics public discussion < >>>>>> x3d-public at web3d.org>; Carol McDonald ; Joe D >>>>>> Williams >>>>>> *Cc:* John Carlson ; Andreas Plesch < >>>>>> andreasplesch at gmail.com> >>>>>> *Subject:* Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>>> >>>>>> Here?s what HAnim spec says under Displacer: >>>>>> >>>>>> https://www.web3d.org/documents/specifications/19774/V2.0/index.html >>>>>> >>>>>> ?For the *Displacer* objects that are contained in the *displacers* field >>>>>> of the *Segment* objects, the *displacements* are defined and >>>>>> applied in the *Segment* coordinate system. The base mesh for the >>>>>> morphed *Segment* is the original mesh defined in the *Segment*.? >>>>>> >>>>>> And here?s what it says under Segment: >>>>>> >>>>>> ? >>>>>> >>>>>> The *coord* field is used for *Segment* objects that have deformable >>>>>> meshes and shall contain coordinates referenced from the indexed mesh for >>>>>> the *Segment* object. The coordinates are given the same name as the >>>>>> *Segment* object, but with a "_coords" appended (e.g.,"skull_coords" >>>>>> ).? >>>>>> displacements are an offset from the mesh, with weight from 0 to 1. >>>>>> So weight times displacement is total offset from base mesh. 0 weight = no >>>>>> offset, 1 weight = full displacements offset >>>>>> >>>>>> The Coordinate point is maintained to handle weight = 0. Weight >>>>>> ranges from 0 to 1, but double check. >>>>>> >>>>>> Joe or Carol might know where to find it in the HAnim spec. >>>>>> >>>>>> I believe the answer is, ?during rendering,?. Since weight can vary >>>>>> with animation, and so can displacements, AFAIK. More than one displacer >>>>>> can be applied to the mesh. >>>>>> >>>>>> I have not read the spec. >>>>>> >>>>>> John >>>>>> >>>>>> >>>>>> >>>>>> On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public < >>>>>> x3d-public at web3d.org> wrote: >>>>>> >>>>>> >>>>>> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer >>>>>> >>>>>> does not directly explain what the effect of the displacer on the >>>>>> coord.point field of the containing HAnimSegment is. But it mentions the >>>>>> coord.point field and seems to imply that the coord.point field is involved. >>>>>> >>>>>> So the question is if the Displacer should alter the coord.point >>>>>> field in order to achieve a graphical displacement, or if the Browser >>>>>> should only apply the displacements during rendering without a change in >>>>>> the coord.point field ? >>>>>> >>>>>> This is relevant if the coord.point field is accessed by routes or >>>>>> scripts, in addition to displacers. >>>>>> >>>>>> Thanks for any feedback or ideas, >>>>>> >>>>>> Andreas >>>>>> >>>>>> -- >>>>>> Andreas Plesch >>>>>> Waltham, MA 02453 >>>>>> _______________________________________________ >>>>>> x3d-public mailing list >>>>>> x3d-public at web3d.org >>>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> x3d-public mailing list >>>>>> x3d-public at web3d.org >>>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> x3d-public mailing list >>>>>> x3d-public at web3d.org >>>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>>> >>>>> >>>> >>>> -- >>>> Andreas Plesch >>>> Waltham, MA 02453 >>>> >>>> >>>> >>> >> >> >> _______________________________________________ >> x3d-public mailing list >> x3d-public at web3d.org >> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreasplesch at gmail.com Thu Feb 20 14:21:56 2025 From: andreasplesch at gmail.com (Andreas Plesch) Date: Thu, 20 Feb 2025 17:21:56 -0500 Subject: [x3d-public] UnlitMaterial Message-ID: Looking at UnlitMaterial: https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/lighting.html#LightingUnlit Can UnlitMaterial be thought of as Material without light contributions ? Eg. on_i for all lights is 0 ? It looks equivalent but perhaps there is a subtle difference. Yeah, one subtle difference appears to be that the transparency field is applied to diffuse.a rather than emissive.a . Related, the Phong lighting in the case of on_i all zero, does not seem to have a way to specify an alpha for emissive ? Not sure how much use emissive alpha has but UnlitMaterial has it. Thanks for any input, -Andreas -- Andreas Plesch Waltham, MA 02453 -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger.seelig at yahoo.de Fri Feb 21 04:42:36 2025 From: holger.seelig at yahoo.de (Holger Seelig) Date: Fri, 21 Feb 2025 13:42:36 +0100 Subject: [x3d-public] UnlitMaterial In-Reply-To: References: Message-ID: There seems to be lot of differences across browsers: X_ITE https://create3000.github.io/x_ite/playground/?url=https://create3000.github.io/Library/Tests/Components/Shape/CompareEmissive.x3d X3DOM https://andreasplesch.github.io/Library/Viewer/index.html?url=https://create3000.github.io/Library/Tests/Components/Shape/CompareEmissive.x3d Download URL for Castle and FreeWrl: https://create3000.github.io/Library/Tests/Components/Shape/CompareEmissive.x3d Best regards, Holger -- Holger Seelig Leipzig, Germany holger.seelig at yahoo.de https://create3000.github.io/x_ite/ > Am 20.02.2025 um 23:21 schrieb Andreas Plesch via x3d-public : > > Looking at UnlitMaterial: > > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/lighting.html#LightingUnlit > > Can UnlitMaterial be thought of as Material without light contributions ? Eg. on_i for all lights is 0 ? > > It looks equivalent but perhaps there is a subtle difference. Yeah, one subtle difference appears to be that the transparency field is applied to diffuse.a rather than emissive.a . > > Related, the Phong lighting in the case of on_i all zero, does not seem to have a way to specify an alpha for emissive ? Not sure how much use emissive alpha has but UnlitMaterial has it. > > Thanks for any input, -Andreas > > -- > Andreas Plesch > Waltham, MA 02453 > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From michalis.kambi at gmail.com Fri Feb 21 04:44:11 2025 From: michalis.kambi at gmail.com (Michalis Kamburelis) Date: Fri, 21 Feb 2025 13:44:11 +0100 Subject: [x3d-public] UnlitMaterial In-Reply-To: References: Message-ID: UnlitMaterial is *similar but not exactly the same* as Material with all lights=off. It's a similar question with similar answers as "is UnlitMaterial like Material with all fields except emissieColor equal to zero". See https://github.com/michaliskambi/x3d-tests/wiki/Why-is-UnlitMaterial-useful for my reasoning. In short: - Better interaction with Appearance.texture : UnlitMaterial says that emissive parameter (not diffuse, as would be for Material) is multiplied by Appearance.texture. - Better interaction with Color / ColorRGBA : UnlitMaterial says that emissive parameter (not diffuse, as would be for Material) are replaced by per-vertex color. (or multiplied by per-vertex color, if you use CGE extension https://github.com/michaliskambi/x3d-tests/wiki/Converting-glTF-to-X3D#per-vertex-colors "Color { mode "MODULATE" ... }" ). - In UnlitMaterial, the texture that affects transparency is emissiveTexture, not diffuseTexture. I see you also mentioned this. Regards, Michalis czw., 20 lut 2025 o 23:23 Andreas Plesch via x3d-public napisa?(a): > > Looking at UnlitMaterial: > > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/lighting.html#LightingUnlit > > Can UnlitMaterial be thought of as Material without light contributions ? Eg. on_i for all lights is 0 ? > > It looks equivalent but perhaps there is a subtle difference. Yeah, one subtle difference appears to be that the transparency field is applied to diffuse.a rather than emissive.a . > > Related, the Phong lighting in the case of on_i all zero, does not seem to have a way to specify an alpha for emissive ? Not sure how much use emissive alpha has but UnlitMaterial has it. > > Thanks for any input, -Andreas > > -- > Andreas Plesch > Waltham, MA 02453 > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org From andreasplesch at gmail.com Fri Feb 21 05:02:00 2025 From: andreasplesch at gmail.com (Andreas Plesch) Date: Fri, 21 Feb 2025 08:02:00 -0500 Subject: [x3d-public] UnlitMaterial In-Reply-To: References: Message-ID: Thanks, Holger. x3dom currently does not have UnlitMaterial. Andreas On Fri, Feb 21, 2025, 7:42?AM Holger Seelig wrote: > There seems to be lot of differences across browsers: > > X_ITE > > https://create3000.github.io/x_ite/playground/?url=https://create3000.github.io/Library/Tests/Components/Shape/CompareEmissive.x3d > > X3DOM > > https://andreasplesch.github.io/Library/Viewer/index.html?url=https://create3000.github.io/Library/Tests/Components/Shape/CompareEmissive.x3d > > Download URL for Castle and FreeWrl: > > https://create3000.github.io/Library/Tests/Components/Shape/CompareEmissive.x3d > > Best regards, > Holger > > -- > Holger Seelig > Leipzig, Germany > > holger.seelig at yahoo.de > https://create3000.github.io/x_ite/ > > Am 20.02.2025 um 23:21 schrieb Andreas Plesch via x3d-public < > x3d-public at web3d.org>: > > Looking at UnlitMaterial: > > > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/lighting.html#LightingUnlit > > Can UnlitMaterial be thought of as Material without light contributions ? > Eg. on_i for all lights is 0 ? > > It looks equivalent but perhaps there is a subtle difference. Yeah, one > subtle difference appears to be that the transparency field is applied to > diffuse.a rather than emissive.a . > > Related, the Phong lighting in the case of on_i all zero, does not seem to > have a way to specify an alpha for emissive ? Not sure how much use > emissive alpha has but UnlitMaterial has it. > > Thanks for any input, -Andreas > > -- > Andreas Plesch > Waltham, MA 02453 > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger.seelig at yahoo.de Fri Feb 21 05:05:40 2025 From: holger.seelig at yahoo.de (Holger Seelig) Date: Fri, 21 Feb 2025 14:05:40 +0100 Subject: [x3d-public] UnlitMaterial In-Reply-To: References: Message-ID: <75D6C1C6-1FB2-4759-9889-FA8623C9916C@yahoo.de> Additionally added PhysicalMaterial boxes for comparison. Best regards, Holger -- Holger Seelig Leipzig, Germany holger.seelig at yahoo.de https://create3000.github.io/x_ite/ > Am 21.02.2025 um 14:02 schrieb Andreas Plesch : > > Thanks, Holger. x3dom currently does not have UnlitMaterial. > > Andreas > > On Fri, Feb 21, 2025, 7:42?AM Holger Seelig > wrote: >> There seems to be lot of differences across browsers: >> >> X_ITE >> https://create3000.github.io/x_ite/playground/?url=https://create3000.github.io/Library/Tests/Components/Shape/CompareEmissive.x3d >> >> X3DOM >> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://create3000.github.io/Library/Tests/Components/Shape/CompareEmissive.x3d >> >> Download URL for Castle and FreeWrl: >> https://create3000.github.io/Library/Tests/Components/Shape/CompareEmissive.x3d >> >> Best regards, >> Holger >> >> -- >> Holger Seelig >> Leipzig, Germany >> >> holger.seelig at yahoo.de >> https://create3000.github.io/x_ite/ >> >>> Am 20.02.2025 um 23:21 schrieb Andreas Plesch via x3d-public >: >>> >>> Looking at UnlitMaterial: >>> >>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/lighting.html#LightingUnlit >>> >>> Can UnlitMaterial be thought of as Material without light contributions ? Eg. on_i for all lights is 0 ? >>> >>> It looks equivalent but perhaps there is a subtle difference. Yeah, one subtle difference appears to be that the transparency field is applied to diffuse.a rather than emissive.a . >>> >>> Related, the Phong lighting in the case of on_i all zero, does not seem to have a way to specify an alpha for emissive ? Not sure how much use emissive alpha has but UnlitMaterial has it. >>> >>> Thanks for any input, -Andreas >>> >>> -- >>> Andreas Plesch >>> Waltham, MA 02453 >>> _______________________________________________ >>> x3d-public mailing list >>> x3d-public at web3d.org >>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreasplesch at gmail.com Fri Feb 21 05:07:40 2025 From: andreasplesch at gmail.com (Andreas Plesch) Date: Fri, 21 Feb 2025 08:07:40 -0500 Subject: [x3d-public] UnlitMaterial In-Reply-To: References: Message-ID: Thanks for list. UnlitMaterial is certainly useful. I was just looking for the features which are not covered by the current Material with no lights since this would the rough starting point for supporting. Andreas On Fri, Feb 21, 2025, 7:44?AM Michalis Kamburelis wrote: > UnlitMaterial is *similar but not exactly the same* as Material with > all lights=off. > > It's a similar question with similar answers as "is UnlitMaterial like > Material with all fields except emissieColor equal to zero". See > https://github.com/michaliskambi/x3d-tests/wiki/Why-is-UnlitMaterial-useful > for my reasoning. In short: > > - Better interaction with Appearance.texture : UnlitMaterial says that > emissive parameter (not diffuse, as would be for Material) is > multiplied by Appearance.texture. > > - Better interaction with Color / ColorRGBA : UnlitMaterial says that > emissive parameter (not diffuse, as would be for Material) are > replaced by per-vertex color. > > (or multiplied by per-vertex color, if you use CGE extension > > https://github.com/michaliskambi/x3d-tests/wiki/Converting-glTF-to-X3D#per-vertex-colors > "Color { mode "MODULATE" ... }" ). > > - In UnlitMaterial, the texture that affects transparency is > emissiveTexture, not diffuseTexture. I see you also mentioned this. > > Regards, > Michalis > > czw., 20 lut 2025 o 23:23 Andreas Plesch via x3d-public > napisa?(a): > > > > Looking at UnlitMaterial: > > > > > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/lighting.html#LightingUnlit > > > > Can UnlitMaterial be thought of as Material without light contributions > ? Eg. on_i for all lights is 0 ? > > > > It looks equivalent but perhaps there is a subtle difference. Yeah, one > subtle difference appears to be that the transparency field is applied to > diffuse.a rather than emissive.a . > > > > Related, the Phong lighting in the case of on_i all zero, does not seem > to have a way to specify an alpha for emissive ? Not sure how much use > emissive alpha has but UnlitMaterial has it. > > > > Thanks for any input, -Andreas > > > > -- > > Andreas Plesch > > Waltham, MA 02453 > > _______________________________________________ > > x3d-public mailing list > > x3d-public at web3d.org > > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joedwil at earthlink.net Fri Feb 21 09:17:41 2025 From: joedwil at earthlink.net (Joe D Williams) Date: Fri, 21 Feb 2025 17:17:41 +0000 Subject: [x3d-public] UnlitMaterial Message-ID: <45311514-1176-2caf-efac-cc76b81fae88@earthlink.net> Just logically, to me now anyway, if no light then all that is left is emissive. The shape can emit some kind of light (glow), according to transparency, but not reflect of absorb. So diffuse doesn't count for unlit because that is response due to effect of lighting. ? Joe. -----Original Message----- From: Extensible 3D (X3D) Graphics public discussion Sent: Feb 20, 2025 2:23 PM To: X3D Graphics public mailing list Cc: Andreas Plesch Subject: [x3d-public] UnlitMaterial Looking at UnlitMaterial: https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/lighting.html#LightingUnlit Can UnlitMaterial be thought of as Material without light contributions ? Eg. on_i for all lights is 0 ? It looks equivalent but perhaps there is a subtle difference. Yeah, one subtle difference appears to be that the transparency field is applied to diffuse.a rather than emissive.a . Related, the Phong lighting in the case of on_i all zero, does not seem to have a way to specify an alpha for emissive ? Not sure how much use emissive alpha has but UnlitMaterial has it. Thanks for any input, -Andreas -- Andreas Plesch Waltham, MA 02453 -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreasplesch at gmail.com Fri Feb 21 10:14:02 2025 From: andreasplesch at gmail.com (Andreas Plesch) Date: Fri, 21 Feb 2025 13:14:02 -0500 Subject: [x3d-public] UnlitMaterial In-Reply-To: <45311514-1176-2caf-efac-cc76b81fae88@earthlink.net> References: <45311514-1176-2caf-efac-cc76b81fae88@earthlink.net> Message-ID: Yes, that is the overall idea and captured by the equations in the spec. In addition, there are a few more considerations which UnlitMaterial covers as carefully determined by Michalis. -Andreas On Fri, Feb 21, 2025 at 12:18?PM Joe D Williams wrote: > Just logically, to me now anyway, if no light then all that is left is > emissive. > > The shape can emit some kind of light (glow), according to transparency, > but not reflect of absorb. > > So diffuse doesn't count for unlit because that is response due to effect > of lighting. > > ? > > Joe. > > > > > > -----Original Message----- > From: Extensible 3D (X3D) Graphics public discussion > > Sent: Feb 20, 2025 2:23 PM > To: X3D Graphics public mailing list > Cc: Andreas Plesch > Subject: [x3d-public] UnlitMaterial > > > Looking at UnlitMaterial: > > > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/lighting.html#LightingUnlit > > Can UnlitMaterial be thought of as Material without light contributions ? > Eg. on_i for all lights is 0 ? > > It looks equivalent but perhaps there is a subtle difference. Yeah, one > subtle difference appears to be that the transparency field is applied to > diffuse.a rather than emissive.a . > > Related, the Phong lighting in the case of on_i all zero, does not seem to > have a way to specify an alpha for emissive ? Not sure how much use > emissive alpha has but UnlitMaterial has it. > > Thanks for any input, -Andreas > > -- > Andreas Plesch > Waltham, MA 02453 > > > -- Andreas Plesch Waltham, MA 02453 -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreasplesch at gmail.com Fri Feb 21 10:30:11 2025 From: andreasplesch at gmail.com (Andreas Plesch) Date: Fri, 21 Feb 2025 13:30:11 -0500 Subject: [x3d-public] unmatched xxxTextureMapping Message-ID: As https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/shape.html#TextureMappingCoordinate and co. explains the xxxTextureMapping field can be used to have multiple sets/channels of TextureCoordinates for the same Shape, for different types of Textures. There is one case which is not covered, presumably because it typically would indicate a mistake or oversight by the author. What should a browser implementation do if a material has a (non-default) xxxTextureMapping which does not match any of the provided TextureCoordinates for the Shape ? Possibilities are fall-back to default texture coordinates, fall-back to the first provided mapping, fall-back to constant uv 0,0 to indicate visually a problem, or undefined behaviour. Undefined behaviour might be ok but it is then worth pointing out in the spec. Thanks, -Andreas -- Andreas Plesch Waltham, MA 02453 -------------- next part -------------- An HTML attachment was scrubbed... URL: From joedwil at earthlink.net Fri Feb 21 10:55:48 2025 From: joedwil at earthlink.net (Joe D Williams) Date: Fri, 21 Feb 2025 18:55:48 +0000 Subject: [x3d-public] HAnimDisplacer effect on coord.point Message-ID: <45a3be18-cfc5-ee96-12ce-6b129caea508@earthlink.net> > take out layering code ... I still don't see how layering will help in making a HUD. Can you have one viewpoint in one layer and navigate but have a second viewpoint in another layer that keeps the menu up front? Ithinktheprox sensor works everywhere bu x3dom? Thanks, Joe -----Original Message----- From: Extensible 3D (X3D) Graphics public discussion Sent: Feb 20, 2025 12:18 PM To: Extensible 3D (X3D) Graphics public discussion Cc: John Carlson Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point I guess there could be some weird encoding or formatting issue. I use GitHub Bash inside Windows Terminal, I don’t know if I am encoding with Cp1252 or something Windows specific. I’ll do more research. On Thu, Feb 20, 2025 at 7:19?AM Holger Seelig via x3d-public wrote: For some reason I cannot open those *.zip files from you John. My system say „Unknown file format“. Best regards, Holger -- Holger Seelig Leipzig, Germany holger.seelig at yahoo.de (mailto:holger.seelig at yahoo.de) https://create3000.github.io/x_ite/ Am 20.02.2025 um 00:24 schrieb John Carlson : Attached is an example with a Hud. I can't get the menu (with the Hud ProximitySensor and Transforms) to move differently than Jin, so I'm kind of stuck. There's probably some silly problem that I missed. The menus move with the mouse. Thanks for looking, John On Tue, Feb 18, 2025 at 6:49?PM John Carlson wrote: Thanks for code samples, Joe. It looks like I can take out my Layering/Layout code and just focus on the menu. Sorry I am so slow on this, I think I might be hibernating. I’m looking at my GitHub commits and they have dropped drastically. This might be because I am spending more time helping others with recovery or just using social media too much. I will try to get to the HUD in the next two days. It was so cold, we didn’t even go to the dentist 45 miles away. We got out today though. John On Tue, Feb 18, 2025 at 6:38?PM Joe D Williams wrote: > a HUD for Joe A hud for the FACS example is needed because any navigation causes the menu to disappear. The menu can be just like used on the Jin scaled with animation example. However that uses a ProximitySensor which x3dom does not support, for some reason. We use that a lot for start timers, timers, etc.as (http://etc.as/) well as being the typical way to keep a menu or scene data in view. If HTML/SVG is better, I have not seen it. I don't think Stacking canvas is appropriate. Fine to think of XR for in-world 2d or3d HUDS but does that sort ofdisplay really work any different than using prox sensor? ProximitySensor is just so basic. rest of menu Thanks and Best, Joe huds3d XR -----Original Message----- From: Andreas Plesch Sent: Feb 18, 2025 11:45 AM To: John Carlson Cc: Extensible 3D (X3D) Graphics public discussion , Holger Seelig , Joseph D Williams , Brutzman, Donald (Don) (CIV) , Carol McDonald Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point Please do not wait for x3dom. Both ProximitySensor and the Layering component are lower priority. HTML/SVG is better suited for 2D HUDs and layering can be approximated by stacking multiple X3D canvases/scenes. You may also consider XR where immersion typically strongly favors in-world 3d HUDs. Best, -Andreas On Tue, Feb 18, 2025 at 2:25?PM John Carlson wrote: Don, we’re currently working on a HUD for Joe, I don’t currently have an online example of that. Otherwise, I’m waiting on someone deciding which meshes to merge. I could take the lead on this. I could use a tutorial on the Layering and Layout components, examples don’t seem to help. I may try to adopt a 3D HUD based on examples. Something with the 2D overlay in WORLD space would help tremendously, or some conversion from WORLD space. We already have 3D menus, so a 3D HUD might be easiest. Thanks, John On Mon, Feb 17, 2025 at 11:18?PM Brutzman, Donald (Don) (CIV) via x3d-public wrote: Wondering, do we have a simple excerpted example that we can look at yet? That will help guide these discussions. Don't need a full human body animation in all its displaceable glory... all the best, Don -- Don Brutzman Naval Postgraduate School, Code USW/Br brutzman at nps.edu (mailto:brutzman at nps.edu) Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149 X3D graphics, virtual worlds, navy robotics https://faculty.nps.edu/brutzman From: x3d-public on behalf of Joe D Williams via x3d-public Sent: Saturday, February 15, 2025 6:55 PM To: Holger Seelig ; Andreas Plesch Cc: joedwil at earthlink.net (mailto:joedwil at earthlink.net) ; X3D ; Carol McDonald Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point > coord.point changes are very very expensive quickly, Right, the processing time gets expensive as the number of points moved. If level 1 segment geometry where the mesh is driven directly by a joint, then it easier since weight is always 1. For level 2 skin, the the weight (radial movement) applied by maybe multiple joints needs to be computed for each point. Finally, for both levels, the displacements for selected set of points needs to be applied. This implies multiple passes on the subject coordinates? Whatever, these operations are common where the applications deal with a complete mesh and with sparse points of a mesh for blending. . > with reference to CoordinateInterpolator, These are useful when controlling all points of a target mesh. All points of a mesh must be included and same number of points at each keyframe. This style was used in first step of the current example x3d FACS because face geometry is made from multiple shapes. CoordinateInterpolater sets for each shape for each elemental action moved the points. This was simplified to using the same face for each action example and then replaced the CIs with sets of Displacers. Now have developed further to combine individual actions to make a specific expression which consists of multiple elemental movements. However, I think we want to evolve towards a basic single mesh face with some individual shapes for like teeth, hair, eyeballs, eyelids, tongue, maybe ears? and using joint nodes to control, where appropriate. Regardless of how the points are moved for the next frame, it has to be considered that geometry points will be moved directly by joint rotations, by a weighting algorithm using multiple joint rotation inputs, and by one or more scalar-driven Displacer inputs. Thanks for HAnim, Joe -----Message----- From: Holger Seelig Sent: Feb 9, 2025 11:23 AM To: Andreas Plesch Cc: X3D , Joseph D Williams , Carol McDonald Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point I don't think so, coord.point changes are very very expensive quickly, and as Michalis said earlier, with reference to CoordinateInterpolator, we should get rid of them. Holger-- Holger Seelig Leipzig, Germany holger.seelig at yahoo.de (mailto:holger.seelig at yahoo.de) https://create3000.github.io/x_ite/ Am 09.02.2025 um 19:44 schrieb Andreas Plesch : Yes, that is an option. However,coord.point changes are very very expensive quickly, and as Michalis said earlier, with reference to CoordinateInterpolator, we should get rid of them. Andreas On Sun, Feb 9, 2025, 1:40?PM Holger Seelig wrote: X_ITE applies the HAnimDisplacers in the shader, thus no coord.point field has to be changed.Maybe that helps. Best regards, Holger -- Holger Seelig Leipzig, Germany holger.seelig at yahoo.de (mailto:holger.seelig at yahoo.de) https://create3000.github.io/x_ite/ Am 09.02.2025 um 19:33 schrieb Andreas Plesch via x3d-public : That would be the point field of a Coordinate node https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/rendering.html#Coordinate which is used by the coord field of https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimSegment Andreas On Sun, Feb 9, 2025, 12:36?PM Joe D Williams wrote: > coord node emit a point_changed event sorry,I don't see a field anywhere with that event. Displacer is likely to change several points when new weight is sent. All part of the cascade to produce the changed mesh? Thanks, Joe -----Original Message----- From: Andreas Plesch Sent: Feb 9, 2025 4:25 AM To: Brutzman, Donald (Don) (CIV) Cc: Extensible 3D (X3D) Graphics public discussion , Carol McDonald , Joe D Williams , John Carlson Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point Don, Joe and John Thanks for collecting these references. But I am not sure if there is an answer to my original question. Let me rephrase a bit the question: After a Displacer contained in a Segment node receives a set_weight input, should then the coord node emit a point_changed event ? I do not think HAnim is concerned about that, so it is really a X3D question. Thanks, Andreas On Sun, Feb 9, 2025, 12:49?AM Brutzman, Donald (Don) (CIV) wrote: Thanks for pointing in the right direction John. Direct links to functional requirements for Displacer in HAnim 2.0 specification: * HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, Clause 4 Concepts, 4.7 Displacer object * https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#DisplacerObject * HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, Clause 6 Object interfaces, 6.6 Displacer * https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer and * X3D 4.0 Architecture, Clause 26 Humanoid Animation (HAnim) component, 26.3.1 HAnimDisplacer * https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimDisplacer and informative * X3D Tooltips, HAnimDisplacer * https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimDisplacer Thanks for implementation efforts and careful scrutiny. Questions and potential issues/clarifications/corrections are always welcome. all the best, Don -- Don Brutzman Naval Postgraduate School, Code USW/Br brutzman at nps.edu (mailto:brutzman at nps.edu) Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149 X3D graphics, virtual worlds, navy robotics https://faculty.nps.edu/brutzman From: x3d-public on behalf of John Carlson via x3d-public Sent: Saturday, February 8, 2025 3:43 AM To: Extensible 3D (X3D) Graphics public discussion ; Carol McDonald ; Joe D Williams Cc: John Carlson ; Andreas Plesch Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point Here’s what HAnim spec says under Displacer: https://www.web3d.org/documents/specifications/19774/V2.0/index.html “For the Displacer objects that are contained in the displacers field of the Segment objects, the displacements are defined and applied in the Segment coordinate system. The base mesh for the morphed Segment is the original mesh defined in the Segment.” And here’s what it says under Segment: “ The coord field is used for Segment objects that have deformable meshes and shall contain coordinates referenced from the indexed mesh for the Segment object. The coordinates are given the same name as the Segment object, but with a "_coords" appended (e.g.,"skull_coords").” displacements are an offset from the mesh, with weight from 0 to 1. So weight times displacement is total offset from base mesh. 0 weight = no offset, 1 weight = full displacements offset The Coordinate point is maintained to handle weight = 0. Weight ranges from 0 to 1, but double check. Joe or Carol might know where to find it in the HAnim spec. I believe the answer is, “during rendering,”. Since weight can vary with animation, and so can displacements, AFAIK. More than one displacer can be applied to the mesh. I have not read the spec. John On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public wrote: https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer does not directly explain what the effect of the displacer on the coord.point field of the containing HAnimSegment is. But it mentions the coord.point field and seems to imply that the coord.point field is involved. So the question is if the Displacer should alter the coord.point field in order to achieve a graphical displacement, or if the Browser should only apply the displacements during rendering without a change in the coord.point field ? This is relevant if the coord.point field is accessed by routes or scripts, in addition to displacers. Thanks for any feedback or ideas, Andreas -- Andreas Plesch Waltham, MA 02453 _______________________________________________ x3d-public mailing list x3d-public at web3d.org (mailto:x3d-public at web3d.org) http://web3d.org/mailman/listinfo/x3d-public_web3d.org _______________________________________________ x3d-public mailing list x3d-public at web3d.org (mailto:x3d-public at web3d.org) http://web3d.org/mailman/listinfo/x3d-public_web3d.org _______________________________________________ x3d-public mailing list x3d-public at web3d.org (mailto:x3d-public at web3d.org) http://web3d.org/mailman/listinfo/x3d-public_web3d.org -- Andreas Plesch Waltham, MA 02453 _______________________________________________ x3d-public mailing list x3d-public at web3d.org (mailto:x3d-public at web3d.org) http://web3d.org/mailman/listinfo/x3d-public_web3d.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Fri Feb 21 11:37:58 2025 From: yottzumm at gmail.com (John Carlson) Date: Fri, 21 Feb 2025 13:37:58 -0600 Subject: [x3d-public] HAnimDisplacer effect on coord.point In-Reply-To: <45a3be18-cfc5-ee96-12ce-6b129caea508@earthlink.net> References: <45a3be18-cfc5-ee96-12ce-6b129caea508@earthlink.net> Message-ID: Hmm. I took out the layering code in the latest zip, Clocks6.zip. Check out Andreas? version if you?re having trouble unpacking it. Layering/Layout is like a 2D layer on top of a 3D layer. Holger?s point was that it might be useful for a HUD. Please view current zip, around the ProximitySensor, and Hud ROUTEs. I don?t know how to make the menu rotate opposite the mouse, or how to keep the menu in the HUD. I will look into Viewpoints. John On Fri, Feb 21, 2025 at 12:56?PM Joe D Williams wrote: > > take out layering code ... > > > > I still don't see how layering will help in making a HUD. > > Can you have one viewpoint in one layer and navigate but have a second > viewpoint in another layer that keeps the menu up front? > > Ithinktheprox sensor works everywhere bu x3dom? > > > > Thanks, > > Joe > > > > -----Original Message----- > From: Extensible 3D (X3D) Graphics public discussion > > Sent: Feb 20, 2025 12:18 PM > To: Extensible 3D (X3D) Graphics public discussion > Cc: John Carlson > Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point > > > I guess there could be some weird encoding or formatting issue. I use > GitHub Bash inside Windows Terminal, I don?t know if I am encoding with > Cp1252 or something Windows specific. I?ll do more research. > > On Thu, Feb 20, 2025 at 7:19?AM Holger Seelig via x3d-public < > x3d-public at web3d.org> wrote: > >> For some reason I cannot open those *.zip files from you John. My system >> say ?Unknown file format?. >> >> Best regards, >> Holger >> >> -- >> Holger Seelig >> Leipzig, Germany >> >> holger.seelig at yahoo.de >> https://create3000.github.io/x_ite/ >> >> >> Am 20.02.2025 um 00:24 schrieb John Carlson : >> >> >> >> Attached is an example with a Hud. I can't get the menu (with the Hud >> ProximitySensor and Transforms) to move differently than Jin, so I'm kind >> of stuck. >> >> There's probably some silly problem that I missed. The menus move >> with the mouse. >> >> Thanks for looking, >> >> John >> >> On Tue, Feb 18, 2025 at 6:49?PM John Carlson wrote: >> >>> Thanks for code samples, Joe. It looks like I can take out my >>> Layering/Layout code and just focus on the menu. Sorry I am so slow on >>> this, I think I might be hibernating. >>> >>> I?m looking at my GitHub commits and they have dropped drastically. >>> This might be because I am spending more time helping others with recovery >>> or just using social media too much. >>> >>> I will try to get to the HUD in the next two days. It was so cold, we >>> didn?t even go to the dentist 45 miles away. We got out today though. >>> >>> John >>> >>> On Tue, Feb 18, 2025 at 6:38?PM Joe D Williams >>> wrote: >>> >>>> > a HUD for Joe >>>> >>>> >>>> A hud for the FACS example is needed because any navigation causes the >>>> menu to disappear. The menu can be just like used on the Jin scaled with >>>> animation example. However that uses a ProximitySensor which x3dom does not >>>> support, for some reason. We use that a lot for start timers, timers, >>>> etc.as well as being the typical way to keep a menu or scene data in >>>> view. >>>> If HTML/SVG is better, I have not seen it. I don't think Stacking >>>> canvas is appropriate. Fine to think of XR for in-world 2d or3d HUDS but >>>> does that sort ofdisplay really work any different than using prox sensor? >>>> ProximitySensor is just so basic. >>>> >>>> >>>> >>>> >>>> >>>> rest of menu >>>> >>> toField='set_translation' toNode='HudXform'/> >>>> >>> toField='set_rotation' toNode='HudXform'/> >>>> >>>> >>>> Thanks and Best, >>>> Joe >>>> >>>> >>>> huds3d >>>> XR >>>> >>>> >>>> -----Original Message----- >>>> From: Andreas Plesch >>>> Sent: Feb 18, 2025 11:45 AM >>>> To: John Carlson >>>> Cc: Extensible 3D (X3D) Graphics public discussion < >>>> x3d-public at web3d.org>, Holger Seelig , Joseph >>>> D Williams , Brutzman, Donald (Don) (CIV) < >>>> brutzman at nps.edu>, Carol McDonald >>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>> >>>> >>>> Please do not wait for x3dom. Both ProximitySensor and the Layering >>>> component are lower priority. HTML/SVG is better suited for 2D HUDs and >>>> layering can be approximated by stacking multiple X3D canvases/scenes. You >>>> may also consider XR where immersion typically strongly favors in-world 3d >>>> HUDs. >>>> >>>> Best, -Andreas >>>> >>>> On Tue, Feb 18, 2025 at 2:25?PM John Carlson >>>> wrote: >>>> >>>>> Don, we?re currently working on a HUD for Joe, I don?t currently have >>>>> an online example of that. >>>>> >>>>> Otherwise, I?m waiting on someone deciding which meshes to merge. I >>>>> could take the lead on this. >>>>> >>>>> I could use a tutorial on the Layering and Layout components, examples >>>>> don?t seem to help. I may try to adopt a 3D HUD based on examples. >>>>> Something with the 2D overlay in WORLD space would help tremendously, or >>>>> some conversion from WORLD space. >>>>> >>>>> We already have 3D menus, so a 3D HUD might be easiest. >>>>> >>>>> Thanks, >>>>> >>>>> John >>>>> On Mon, Feb 17, 2025 at 11:18?PM Brutzman, Donald (Don) (CIV) via >>>>> x3d-public wrote: >>>>> >>>>>> Wondering, do we have a simple excerpted example that we can look at >>>>>> yet? That will help guide these discussions. >>>>>> >>>>>> Don't need a full human body animation in all its displaceable >>>>>> glory... >>>>>> >>>>>> >>>>>> 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 >>>>>> https://faculty.nps.edu/brutzman >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------ >>>>>> *From:* x3d-public on behalf of Joe D >>>>>> Williams via x3d-public >>>>>> *Sent:* Saturday, February 15, 2025 6:55 PM >>>>>> *To:* Holger Seelig ; Andreas Plesch < >>>>>> andreasplesch at gmail.com> >>>>>> *Cc:* joedwil at earthlink.net ; X3D < >>>>>> x3d-public at web3d.org>; Carol McDonald >>>>>> >>>>>> *Subject:* Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>>> >>>>>> > coord.point changes are very very expensive quickly, >>>>>> >>>>>> >>>>>> Right, the processing time gets expensive as the number of points >>>>>> moved. >>>>>> If level 1 segment geometry where the mesh is driven directly by a >>>>>> joint, then it easier since weight is always 1. >>>>>> For level 2 skin, the the weight (radial movement) applied by maybe >>>>>> multiple joints needs to be computed for each point. >>>>>> Finally, for both levels, the displacements for selected set of >>>>>> points needs to be applied. >>>>>> This implies multiple passes on the subject coordinates? >>>>>> Whatever, these operations are common where the applications deal >>>>>> with >>>>>> a complete mesh and with sparse points of a mesh for blending. . >>>>>> >>>>>> >>>>>> > with reference to CoordinateInterpolator, >>>>>> >>>>>> >>>>>> These are useful when controlling all points of a target mesh. >>>>>> All points of a mesh must be included and same number of points at >>>>>> each keyframe. >>>>>> This style was used in first step of the current example x3d FACS >>>>>> because >>>>>> face geometry is made from multiple shapes. CoordinateInterpolater >>>>>> sets >>>>>> for each shape for each elemental action moved the points. >>>>>> This was simplified to using the same face for each action example >>>>>> and then replaced the CIs with sets of Displacers. >>>>>> Now have developed further to combine individual actions to make a >>>>>> specific expression which consists of multiple elemental movements. >>>>>> However, I think we want to evolve towards a basic single mesh face >>>>>> with some individual shapes for like teeth, hair, eyeballs, eyelids, >>>>>> tongue, maybe ears? >>>>>> and using joint nodes to control, where appropriate. >>>>>> >>>>>> >>>>>> Regardless of how the points are moved for the next frame, it has to >>>>>> be >>>>>> considered that geometry points will be moved directly by joint >>>>>> rotations, >>>>>> by a weighting algorithm using multiple joint rotation inputs, >>>>>> and by one or more scalar-driven Displacer inputs. >>>>>> >>>>>> >>>>>> Thanks for HAnim, >>>>>> Joe >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -----Message----- >>>>>> From: Holger Seelig >>>>>> Sent: Feb 9, 2025 11:23 AM >>>>>> To: Andreas Plesch >>>>>> Cc: X3D , Joseph D Williams < >>>>>> joedwil at earthlink.net>, Carol McDonald >>>>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>>> >>>>>> >>>>>> I don't think so, coord.point changes are very very expensive >>>>>> quickly, and as Michalis said earlier, with reference to >>>>>> CoordinateInterpolator, we should get rid of them. >>>>>> >>>>>> Holger >>>>>> -- >>>>>> Holger Seelig >>>>>> Leipzig, Germany >>>>>> >>>>>> holger.seelig at yahoo.de >>>>>> https://create3000.github.io/x_ite/ >>>>>> >>>>>> Am 09.02.2025 um 19:44 schrieb Andreas Plesch < >>>>>> andreasplesch at gmail.com>: >>>>>> Yes, that is an option. However,coord.point changes are very very >>>>>> expensive quickly, and as Michalis said earlier, with reference to >>>>>> CoordinateInterpolator, we should get rid of them. >>>>>> >>>>>> Andreas >>>>>> >>>>>> On Sun, Feb 9, 2025, 1:40?PM Holger Seelig >>>>>> wrote: >>>>>> >>>>>> X_ITE applies the HAnimDisplacers in the shader, thus no coord.point >>>>>> field has to be changed. >>>>>> Maybe that helps. >>>>>> >>>>>> Best regards, >>>>>> Holger >>>>>> >>>>>> -- >>>>>> Holger Seelig >>>>>> Leipzig, Germany >>>>>> >>>>>> holger.seelig at yahoo.de >>>>>> https://create3000.github.io/x_ite/ >>>>>> >>>>>> Am 09.02.2025 um 19:33 schrieb Andreas Plesch via x3d-public < >>>>>> x3d-public at web3d.org>: >>>>>> >>>>>> That would be the point field of a Coordinate node >>>>>> >>>>>> >>>>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/rendering.html#Coordinate >>>>>> >>>>>> which is used by the coord field of >>>>>> >>>>>> >>>>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimSegment >>>>>> >>>>>> Andreas >>>>>> >>>>>> On Sun, Feb 9, 2025, 12:36?PM Joe D Williams >>>>>> wrote: >>>>>> >>>>>> > coord node emit a point_changed event >>>>>> >>>>>> >>>>>> sorry,I don't see a field anywhere with that event. Displacer is >>>>>> likely to change several points when new weight is sent. All part of the >>>>>> cascade to produce the changed mesh? >>>>>> Thanks, >>>>>> Joe >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Andreas Plesch >>>>>> Sent: Feb 9, 2025 4:25 AM >>>>>> To: Brutzman, Donald (Don) (CIV) >>>>>> Cc: Extensible 3D (X3D) Graphics public discussion < >>>>>> x3d-public at web3d.org>, Carol McDonald , Joe D >>>>>> Williams , John Carlson >>>>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>>> >>>>>> >>>>>> Don, Joe and John >>>>>> >>>>>> Thanks for collecting these references. >>>>>> >>>>>> But I am not sure if there is an answer to my original question. Let >>>>>> me rephrase a bit the question: >>>>>> >>>>>> After a Displacer contained in a Segment node receives a set_weight >>>>>> input, should then the coord node emit a point_changed event ? >>>>>> >>>>>> I do not think HAnim is concerned about that, so it is really a X3D >>>>>> question. >>>>>> >>>>>> Thanks, Andreas >>>>>> >>>>>> On Sun, Feb 9, 2025, 12:49?AM Brutzman, Donald (Don) (CIV) < >>>>>> brutzman at nps.edu> wrote: >>>>>> >>>>>> Thanks for pointing in the right direction John. >>>>>> >>>>>> Direct links to functional requirements for Displacer in HAnim 2.0 >>>>>> specification: >>>>>> >>>>>> - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, >>>>>> Clause 4 Concepts, 4.7 Displacer object >>>>>> - >>>>>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#DisplacerObject >>>>>> >>>>>> - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, >>>>>> Clause 6 Object interfaces, 6.6 Displacer >>>>>> - >>>>>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer >>>>>> >>>>>> and >>>>>> >>>>>> - X3D 4.0 Architecture, Clause 26 Humanoid Animation (HAnim) >>>>>> component, 26.3.1 HAnimDisplacer >>>>>> - >>>>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimDisplacer >>>>>> >>>>>> and informative >>>>>> >>>>>> - X3D Tooltips, HAnimDisplacer >>>>>> - >>>>>> https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimDisplacer >>>>>> >>>>>> Thanks for implementation efforts and careful scrutiny. >>>>>> >>>>>> Questions and potential issues/clarifications/corrections are always >>>>>> welcome. >>>>>> >>>>>> >>>>>> 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 >>>>>> https://faculty.nps.edu/brutzman >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------ >>>>>> *From:* x3d-public on behalf of John >>>>>> Carlson via x3d-public >>>>>> *Sent:* Saturday, February 8, 2025 3:43 AM >>>>>> *To:* Extensible 3D (X3D) Graphics public discussion < >>>>>> x3d-public at web3d.org>; Carol McDonald ; Joe D >>>>>> Williams >>>>>> *Cc:* John Carlson ; Andreas Plesch < >>>>>> andreasplesch at gmail.com> >>>>>> *Subject:* Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>>> >>>>>> Here?s what HAnim spec says under Displacer: >>>>>> >>>>>> https://www.web3d.org/documents/specifications/19774/V2.0/index.html >>>>>> >>>>>> ?For the *Displacer* objects that are contained in the *displacers* field >>>>>> of the *Segment* objects, the *displacements* are defined and >>>>>> applied in the *Segment* coordinate system. The base mesh for the >>>>>> morphed *Segment* is the original mesh defined in the *Segment*.? >>>>>> >>>>>> And here?s what it says under Segment: >>>>>> >>>>>> ? >>>>>> >>>>>> The *coord* field is used for *Segment* objects that have deformable >>>>>> meshes and shall contain coordinates referenced from the indexed mesh for >>>>>> the *Segment* object. The coordinates are given the same name as the >>>>>> *Segment* object, but with a "_coords" appended (e.g.,"skull_coords" >>>>>> ).? >>>>>> displacements are an offset from the mesh, with weight from 0 to 1. >>>>>> So weight times displacement is total offset from base mesh. 0 weight = no >>>>>> offset, 1 weight = full displacements offset >>>>>> >>>>>> The Coordinate point is maintained to handle weight = 0. Weight >>>>>> ranges from 0 to 1, but double check. >>>>>> >>>>>> Joe or Carol might know where to find it in the HAnim spec. >>>>>> >>>>>> I believe the answer is, ?during rendering,?. Since weight can vary >>>>>> with animation, and so can displacements, AFAIK. More than one displacer >>>>>> can be applied to the mesh. >>>>>> >>>>>> I have not read the spec. >>>>>> >>>>>> John >>>>>> >>>>>> >>>>>> >>>>>> On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public < >>>>>> x3d-public at web3d.org> wrote: >>>>>> >>>>>> >>>>>> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer >>>>>> >>>>>> does not directly explain what the effect of the displacer on the >>>>>> coord.point field of the containing HAnimSegment is. But it mentions the >>>>>> coord.point field and seems to imply that the coord.point field is involved. >>>>>> >>>>>> So the question is if the Displacer should alter the coord.point >>>>>> field in order to achieve a graphical displacement, or if the Browser >>>>>> should only apply the displacements during rendering without a change in >>>>>> the coord.point field ? >>>>>> >>>>>> This is relevant if the coord.point field is accessed by routes or >>>>>> scripts, in addition to displacers. >>>>>> >>>>>> Thanks for any feedback or ideas, >>>>>> >>>>>> Andreas >>>>>> >>>>>> -- >>>>>> Andreas Plesch >>>>>> Waltham, MA 02453 >>>>>> _______________________________________________ >>>>>> x3d-public mailing list >>>>>> x3d-public at web3d.org >>>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> x3d-public mailing list >>>>>> x3d-public at web3d.org >>>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> x3d-public mailing list >>>>>> x3d-public at web3d.org >>>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>>> >>>>> >>>> >>>> -- >>>> Andreas Plesch >>>> Waltham, MA 02453 >>>> >>>> >>>> >>> >> >> _______________________________________________ >> x3d-public mailing list >> x3d-public at web3d.org >> http://web3d.org/mailman/listinfo/x3d-public_web3d.org > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger.seelig at yahoo.de Fri Feb 21 12:02:44 2025 From: holger.seelig at yahoo.de (Holger Seelig) Date: Fri, 21 Feb 2025 21:02:44 +0100 Subject: [x3d-public] HAnimDisplacer effect on coord.point In-Reply-To: References: <45a3be18-cfc5-ee96-12ce-6b129caea508@earthlink.net> Message-ID: Using layer is more easy as using a ProximitySensor. Each Layer node has its own X3DBindableNode stack, thus own viewpoints, background, fog, navigation info. There can only be one active layer where navigation takes place, to be specified with LayerSet.activeLayer. Example attached. Best regards, Holger ? -- Holger Seelig Leipzig, Germany holger.seelig at yahoo.de https://create3000.github.io/x_ite/ > Am 21.02.2025 um 20:37 schrieb John Carlson via x3d-public : > > Hmm. I took out the layering code in the latest zip, Clocks6.zip. Check out Andreas? version if you?re having trouble unpacking it. > > Layering/Layout is like a 2D layer on top of a 3D layer. Holger?s point was that it might be useful for a HUD. > > Please view current zip, around the ProximitySensor, and Hud ROUTEs. > > I don?t know how to make the menu rotate opposite the mouse, or how to keep the menu in the HUD. > > I will look into Viewpoints. > > John > > On Fri, Feb 21, 2025 at 12:56?PM Joe D Williams > wrote: >> > take out layering code ... >> >> I still don't see how layering will help in making a HUD. >> Can you have one viewpoint in one layer and navigate but have a second viewpoint in another layer that keeps the menu up front? >> Ithinktheprox sensor works everywhere bu x3dom? >> >> Thanks, >> Joe >> >> -----Original Message----- >> From: Extensible 3D (X3D) Graphics public discussion > >> Sent: Feb 20, 2025 12:18 PM >> To: Extensible 3D (X3D) Graphics public discussion > >> Cc: John Carlson > >> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >> >> >> I guess there could be some weird encoding or formatting issue. I use GitHub Bash inside Windows Terminal, I don?t know if I am encoding with Cp1252 or something Windows specific. I?ll do more research. >> >> On Thu, Feb 20, 2025 at 7:19?AM Holger Seelig via x3d-public > wrote: >>> For some reason I cannot open those *.zip files from you John. My system say ?Unknown file format?. >>> >>> Best regards, >>> Holger >>> >>> -- >>> Holger Seelig >>> Leipzig, Germany >>> >>> holger.seelig at yahoo.de >>> https://create3000.github.io/x_ite/ >>> >>> Am 20.02.2025 um 00:24 schrieb John Carlson >: >>> >>> Attached is an example with a Hud. I can't get the menu (with the Hud ProximitySensor and Transforms) to move differently than Jin, so I'm kind of stuck. >>> >>> There's probably some silly problem that I missed. The menus move with the mouse. >>> >>> Thanks for looking, >>> >>> John >>> >>> On Tue, Feb 18, 2025 at 6:49?PM John Carlson > wrote: >>>> Thanks for code samples, Joe. It looks like I can take out my Layering/Layout code and just focus on the menu. Sorry I am so slow on this, I think I might be hibernating. >>>> >>>> I?m looking at my GitHub commits and they have dropped drastically. This might be because I am spending more time helping others with recovery or just using social media too much. >>>> >>>> I will try to get to the HUD in the next two days. It was so cold, we didn?t even go to the dentist 45 miles away. We got out today though. >>>> >>>> John >>>> >>>> On Tue, Feb 18, 2025 at 6:38?PM Joe D Williams > wrote: >>>>> > a HUD for Joe >>>>> >>>>> A hud for the FACS example is needed because any navigation causes the menu to disappear. The menu can be just like used on the Jin scaled with animation example. However that uses a ProximitySensor which x3dom does not support, for some reason. We use that a lot for start timers, timers, etc.as well as being the typical way to keep a menu or scene data in view. >>>>> If HTML/SVG is better, I have not seen it. I don't think Stacking canvas is appropriate. Fine to think of XR for in-world 2d or3d HUDS but does that sort ofdisplay really work any different than using prox sensor? ProximitySensor is just so basic. >>>>> >>>>> >>>>> >>>>> >>>>> rest of menu >>>>> >>>>> >>>>> >>>>> Thanks and Best, >>>>> Joe >>>>> >>>>> huds3d >>>>> XR >>>>> >>>>> -----Original Message----- >>>>> From: Andreas Plesch > >>>>> Sent: Feb 18, 2025 11:45 AM >>>>> To: John Carlson > >>>>> Cc: Extensible 3D (X3D) Graphics public discussion >, Holger Seelig >, Joseph D Williams >, Brutzman, Donald (Don) (CIV) >, Carol McDonald > >>>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>> >>>>> >>>>> Please do not wait for x3dom. Both ProximitySensor and the Layering component are lower priority. HTML/SVG is better suited for 2D HUDs and layering can be approximated by stacking multiple X3D canvases/scenes. You may also consider XR where immersion typically strongly favors in-world 3d HUDs. >>>>> >>>>> Best, -Andreas >>>>> >>>>> On Tue, Feb 18, 2025 at 2:25?PM John Carlson > wrote: >>>>>> Don, we?re currently working on a HUD for Joe, I don?t currently have an online example of that. >>>>>> >>>>>> Otherwise, I?m waiting on someone deciding which meshes to merge. I could take the lead on this. >>>>>> >>>>>> I could use a tutorial on the Layering and Layout components, examples don?t seem to help. I may try to adopt a 3D HUD based on examples. Something with the 2D overlay in WORLD space would help tremendously, or some conversion from WORLD space. >>>>>> >>>>>> We already have 3D menus, so a 3D HUD might be easiest. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> John >>>>>> On Mon, Feb 17, 2025 at 11:18?PM Brutzman, Donald (Don) (CIV) via x3d-public > wrote: >>>>>>> Wondering, do we have a simple excerpted example that we can look at yet? That will help guide these discussions. >>>>>>> >>>>>>> Don't need a full human body animation in all its displaceable glory... >>>>>>> >>>>>>> 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 https://faculty.nps.edu/brutzman >>>>>>> >>>>>>> >>>>>>> From: x3d-public > on behalf of Joe D Williams via x3d-public > >>>>>>> Sent: Saturday, February 15, 2025 6:55 PM >>>>>>> To: Holger Seelig >; Andreas Plesch > >>>>>>> Cc: joedwil at earthlink.net >; X3D >; Carol McDonald > >>>>>>> >>>>>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>>>> >>>>>>> > coord.point changes are very very expensive quickly, >>>>>>> >>>>>>> Right, the processing time gets expensive as the number of points moved. >>>>>>> If level 1 segment geometry where the mesh is driven directly by a joint, then it easier since weight is always 1. >>>>>>> For level 2 skin, the the weight (radial movement) applied by maybe multiple joints needs to be computed for each point. >>>>>>> Finally, for both levels, the displacements for selected set of points needs to be applied. >>>>>>> This implies multiple passes on the subject coordinates? >>>>>>> Whatever, these operations are common where the applications deal with >>>>>>> a complete mesh and with sparse points of a mesh for blending. . >>>>>>> >>>>>>> > with reference to CoordinateInterpolator, >>>>>>> >>>>>>> These are useful when controlling all points of a target mesh. >>>>>>> All points of a mesh must be included and same number of points at each keyframe. >>>>>>> This style was used in first step of the current example x3d FACS because >>>>>>> face geometry is made from multiple shapes. CoordinateInterpolater sets >>>>>>> for each shape for each elemental action moved the points. >>>>>>> This was simplified to using the same face for each action example >>>>>>> and then replaced the CIs with sets of Displacers. >>>>>>> Now have developed further to combine individual actions to make a >>>>>>> specific expression which consists of multiple elemental movements. >>>>>>> However, I think we want to evolve towards a basic single mesh face >>>>>>> with some individual shapes for like teeth, hair, eyeballs, eyelids, tongue, maybe ears? >>>>>>> and using joint nodes to control, where appropriate. >>>>>>> >>>>>>> Regardless of how the points are moved for the next frame, it has to be >>>>>>> considered that geometry points will be moved directly by joint rotations, >>>>>>> by a weighting algorithm using multiple joint rotation inputs, >>>>>>> and by one or more scalar-driven Displacer inputs. >>>>>>> >>>>>>> Thanks for HAnim, >>>>>>> Joe >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Message----- >>>>>>> From: Holger Seelig > >>>>>>> Sent: Feb 9, 2025 11:23 AM >>>>>>> To: Andreas Plesch > >>>>>>> Cc: X3D >, Joseph D Williams >, Carol McDonald > >>>>>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>>>> >>>>>>> I don't think so, coord.point changes are very very expensive quickly, and as Michalis said earlier, with reference to CoordinateInterpolator, we should get rid of them. >>>>>>> >>>>>>> Holger >>>>>>> -- >>>>>>> Holger Seelig >>>>>>> Leipzig, Germany >>>>>>> >>>>>>> holger.seelig at yahoo.de >>>>>>> https://create3000.github.io/x_ite/ >>>>>>> >>>>>>> Am 09.02.2025 um 19:44 schrieb Andreas Plesch >: >>>>>>> Yes, that is an option. However,coord.point changes are very very expensive quickly, and as Michalis said earlier, with reference to CoordinateInterpolator, we should get rid of them. >>>>>>> >>>>>>> Andreas >>>>>>> >>>>>>> On Sun, Feb 9, 2025, 1:40?PM Holger Seelig > wrote: >>>>>>> X_ITE applies the HAnimDisplacers in the shader, thus no coord.point field has to be changed. >>>>>>> Maybe that helps. >>>>>>> >>>>>>> Best regards, >>>>>>> Holger >>>>>>> >>>>>>> -- >>>>>>> Holger Seelig >>>>>>> Leipzig, Germany >>>>>>> >>>>>>> holger.seelig at yahoo.de >>>>>>> https://create3000.github.io/x_ite/ >>>>>>> >>>>>>> Am 09.02.2025 um 19:33 schrieb Andreas Plesch via x3d-public >: >>>>>>> >>>>>>> That would be the point field of a Coordinate node >>>>>>> >>>>>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/rendering.html#Coordinate >>>>>>> >>>>>>> which is used by the coord field of >>>>>>> >>>>>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimSegment >>>>>>> >>>>>>> Andreas >>>>>>> >>>>>>> On Sun, Feb 9, 2025, 12:36?PM Joe D Williams > wrote: >>>>>>> > coord node emit a point_changed event >>>>>>> >>>>>>> sorry,I don't see a field anywhere with that event. Displacer is likely to change several points when new weight is sent. All part of the cascade to produce the changed mesh? >>>>>>> Thanks, >>>>>>> Joe >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Andreas Plesch > >>>>>>> Sent: Feb 9, 2025 4:25 AM >>>>>>> To: Brutzman, Donald (Don) (CIV) > >>>>>>> Cc: Extensible 3D (X3D) Graphics public discussion >, Carol McDonald >, Joe D Williams >, John Carlson > >>>>>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>>>> >>>>>>> >>>>>>> Don, Joe and John >>>>>>> >>>>>>> Thanks for collecting these references. >>>>>>> >>>>>>> But I am not sure if there is an answer to my original question. Let me rephrase a bit the question: >>>>>>> >>>>>>> After a Displacer contained in a Segment node receives a set_weight input, should then the coord node emit a point_changed event ? >>>>>>> >>>>>>> I do not think HAnim is concerned about that, so it is really a X3D question. >>>>>>> >>>>>>> Thanks, Andreas >>>>>>> >>>>>>> On Sun, Feb 9, 2025, 12:49?AM Brutzman, Donald (Don) (CIV) > wrote: >>>>>>> Thanks for pointing in the right direction John. >>>>>>> >>>>>>> Direct links to functional requirements for Displacer in HAnim 2.0 specification: >>>>>>> HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, Clause 4 Concepts, 4.7 Displacer object >>>>>>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#DisplacerObject >>>>>>> >>>>>>> HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, Clause 6 Object interfaces, 6.6 Displacer >>>>>>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer >>>>>>> and >>>>>>> X3D 4.0 Architecture, Clause 26 Humanoid Animation (HAnim) component, 26.3.1 HAnimDisplacer >>>>>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimDisplacer >>>>>>> and informative >>>>>>> X3D Tooltips, HAnimDisplacer >>>>>>> https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimDisplacer >>>>>>> Thanks for implementation efforts and careful scrutiny. >>>>>>> >>>>>>> Questions and potential issues/clarifications/corrections are always welcome. >>>>>>> >>>>>>> >>>>>>> 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 https://faculty.nps.edu/brutzman >>>>>>> >>>>>>> >>>>>>> From: x3d-public > on behalf of John Carlson via x3d-public > >>>>>>> Sent: Saturday, February 8, 2025 3:43 AM >>>>>>> To: Extensible 3D (X3D) Graphics public discussion >; Carol McDonald >; Joe D Williams > >>>>>>> Cc: John Carlson >; Andreas Plesch > >>>>>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>>>> >>>>>>> Here?s what HAnim spec says under Displacer: >>>>>>> >>>>>>> https://www.web3d.org/documents/specifications/19774/V2.0/index.html >>>>>>> >>>>>>> ?For the Displacer objects that are contained in the displacers field of the Segment objects, the displacements are defined and applied in the Segment coordinate system. The base mesh for the morphed Segment is the original mesh defined in the Segment.? >>>>>>> >>>>>>> And here?s what it says under Segment: >>>>>>> >>>>>>> ? >>>>>>> The coord field is used for Segment objects that have deformable meshes and shall contain coordinates referenced from the indexed mesh for the Segment object. The coordinates are given the same name as the Segment object, but with a "_coords" appended (e.g.,"skull_coords").? >>>>>>> >>>>>>> displacements are an offset from the mesh, with weight from 0 to 1. So weight times displacement is total offset from base mesh. 0 weight = no offset, 1 weight = full displacements offset >>>>>>> >>>>>>> The Coordinate point is maintained to handle weight = 0. Weight ranges from 0 to 1, but double check. >>>>>>> >>>>>>> Joe or Carol might know where to find it in the HAnim spec. >>>>>>> >>>>>>> I believe the answer is, ?during rendering,?. Since weight can vary with animation, and so can displacements, AFAIK. More than one displacer can be applied to the mesh. >>>>>>> >>>>>>> I have not read the spec. >>>>>>> >>>>>>> John >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public > wrote: >>>>>>> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer >>>>>>> >>>>>>> does not directly explain what the effect of the displacer on the coord.point field of the containing HAnimSegment is. But it mentions the coord.point field and seems to imply that the coord.point field is involved. >>>>>>> >>>>>>> So the question is if the Displacer should alter the coord.point field in order to achieve a graphical displacement, or if the Browser should only apply the displacements during rendering without a change in the coord.point field ? >>>>>>> >>>>>>> This is relevant if the coord.point field is accessed by routes or scripts, in addition to displacers. >>>>>>> >>>>>>> Thanks for any feedback or ideas, >>>>>>> >>>>>>> Andreas >>>>>>> >>>>>>> -- >>>>>>> Andreas Plesch >>>>>>> Waltham, MA 02453 >>>>>>> _______________________________________________ >>>>>>> x3d-public mailing list >>>>>>> x3d-public at web3d.org >>>>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>>>>> >>>>>>> _______________________________________________ >>>>>>> x3d-public mailing list >>>>>>> x3d-public at web3d.org >>>>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>>>>> >>>>>>> _______________________________________________ >>>>>>> x3d-public mailing list >>>>>>> x3d-public at web3d.org >>>>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>>> >>>>> >>>>> >>>>> -- >>>>> Andreas Plesch >>>>> Waltham, MA 02453 >>>>> >>> >>> >>> _______________________________________________ >>> x3d-public mailing list >>> x3d-public at web3d.org >>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >> >> > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Layers.x3d Type: model/x3d+xml Size: 1971 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger.seelig at yahoo.de Fri Feb 21 12:22:42 2025 From: holger.seelig at yahoo.de (Holger Seelig) Date: Fri, 21 Feb 2025 21:22:42 +0100 Subject: [x3d-public] HAnimDisplacer effect on coord.point In-Reply-To: References: <45a3be18-cfc5-ee96-12ce-6b129caea508@earthlink.net> Message-ID: <6AEE6DDB-4A65-4E35-BF24-8811A22B1AB1@yahoo.de> Think easy. Don?t make things more difficult than they are. Here a link ready to try out for the lazy ones: https://create3000.github.io/x_ite/playground/?url=https://gist.githubusercontent.com/create3000/7c9b576f8b3b52d1b51e3fb98b2e93dc/raw/23d76cfb19f7719af4c942f7d9553f386005238d/Layers.x3d Best regards, Holger -- Holger Seelig Leipzig, Germany holger.seelig at yahoo.de https://create3000.github.io/x_ite/ > Am 21.02.2025 um 21:02 schrieb Holger Seelig via x3d-public : > > Using layer is more easy as using a ProximitySensor. Each Layer node has its own X3DBindableNode stack, thus own viewpoints, background, fog, navigation info. There can only be one active layer where navigation takes place, to be specified with LayerSet.activeLayer. Example attached. > > Best regards, > Holger > > > > -- > Holger Seelig > Leipzig, Germany > > holger.seelig at yahoo.de > https://create3000.github.io/x_ite/ > >> Am 21.02.2025 um 20:37 schrieb John Carlson via x3d-public : >> >> Hmm. I took out the layering code in the latest zip, Clocks6.zip. Check out Andreas? version if you?re having trouble unpacking it. >> >> Layering/Layout is like a 2D layer on top of a 3D layer. Holger?s point was that it might be useful for a HUD. >> >> Please view current zip, around the ProximitySensor, and Hud ROUTEs. >> >> I don?t know how to make the menu rotate opposite the mouse, or how to keep the menu in the HUD. >> >> I will look into Viewpoints. >> >> John >> >> On Fri, Feb 21, 2025 at 12:56?PM Joe D Williams > wrote: >>> > take out layering code ... >>> >>> I still don't see how layering will help in making a HUD. >>> Can you have one viewpoint in one layer and navigate but have a second viewpoint in another layer that keeps the menu up front? >>> Ithinktheprox sensor works everywhere bu x3dom? >>> >>> Thanks, >>> Joe >>> >>> -----Original Message----- >>> From: Extensible 3D (X3D) Graphics public discussion > >>> Sent: Feb 20, 2025 12:18 PM >>> To: Extensible 3D (X3D) Graphics public discussion > >>> Cc: John Carlson > >>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>> >>> >>> I guess there could be some weird encoding or formatting issue. I use GitHub Bash inside Windows Terminal, I don?t know if I am encoding with Cp1252 or something Windows specific. I?ll do more research. >>> >>> On Thu, Feb 20, 2025 at 7:19?AM Holger Seelig via x3d-public > wrote: >>>> For some reason I cannot open those *.zip files from you John. My system say ?Unknown file format?. >>>> >>>> Best regards, >>>> Holger >>>> >>>> -- >>>> Holger Seelig >>>> Leipzig, Germany >>>> >>>> holger.seelig at yahoo.de >>>> https://create3000.github.io/x_ite/ >>>> >>>> Am 20.02.2025 um 00:24 schrieb John Carlson >: >>>> >>>> Attached is an example with a Hud. I can't get the menu (with the Hud ProximitySensor and Transforms) to move differently than Jin, so I'm kind of stuck. >>>> >>>> There's probably some silly problem that I missed. The menus move with the mouse. >>>> >>>> Thanks for looking, >>>> >>>> John >>>> >>>> On Tue, Feb 18, 2025 at 6:49?PM John Carlson > wrote: >>>>> Thanks for code samples, Joe. It looks like I can take out my Layering/Layout code and just focus on the menu. Sorry I am so slow on this, I think I might be hibernating. >>>>> >>>>> I?m looking at my GitHub commits and they have dropped drastically. This might be because I am spending more time helping others with recovery or just using social media too much. >>>>> >>>>> I will try to get to the HUD in the next two days. It was so cold, we didn?t even go to the dentist 45 miles away. We got out today though. >>>>> >>>>> John >>>>> >>>>> On Tue, Feb 18, 2025 at 6:38?PM Joe D Williams > wrote: >>>>>> > a HUD for Joe >>>>>> >>>>>> A hud for the FACS example is needed because any navigation causes the menu to disappear. The menu can be just like used on the Jin scaled with animation example. However that uses a ProximitySensor which x3dom does not support, for some reason. We use that a lot for start timers, timers, etc.as well as being the typical way to keep a menu or scene data in view. >>>>>> If HTML/SVG is better, I have not seen it. I don't think Stacking canvas is appropriate. Fine to think of XR for in-world 2d or3d HUDS but does that sort ofdisplay really work any different than using prox sensor? ProximitySensor is just so basic. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> rest of menu >>>>>> >>>>>> >>>>>> >>>>>> Thanks and Best, >>>>>> Joe >>>>>> >>>>>> huds3d >>>>>> XR >>>>>> >>>>>> -----Original Message----- >>>>>> From: Andreas Plesch > >>>>>> Sent: Feb 18, 2025 11:45 AM >>>>>> To: John Carlson > >>>>>> Cc: Extensible 3D (X3D) Graphics public discussion >, Holger Seelig >, Joseph D Williams >, Brutzman, Donald (Don) (CIV) >, Carol McDonald > >>>>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>>> >>>>>> >>>>>> Please do not wait for x3dom. Both ProximitySensor and the Layering component are lower priority. HTML/SVG is better suited for 2D HUDs and layering can be approximated by stacking multiple X3D canvases/scenes. You may also consider XR where immersion typically strongly favors in-world 3d HUDs. >>>>>> >>>>>> Best, -Andreas >>>>>> >>>>>> On Tue, Feb 18, 2025 at 2:25?PM John Carlson > wrote: >>>>>>> Don, we?re currently working on a HUD for Joe, I don?t currently have an online example of that. >>>>>>> >>>>>>> Otherwise, I?m waiting on someone deciding which meshes to merge. I could take the lead on this. >>>>>>> >>>>>>> I could use a tutorial on the Layering and Layout components, examples don?t seem to help. I may try to adopt a 3D HUD based on examples. Something with the 2D overlay in WORLD space would help tremendously, or some conversion from WORLD space. >>>>>>> >>>>>>> We already have 3D menus, so a 3D HUD might be easiest. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> John >>>>>>> On Mon, Feb 17, 2025 at 11:18?PM Brutzman, Donald (Don) (CIV) via x3d-public > wrote: >>>>>>>> Wondering, do we have a simple excerpted example that we can look at yet? That will help guide these discussions. >>>>>>>> >>>>>>>> Don't need a full human body animation in all its displaceable glory... >>>>>>>> >>>>>>>> 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 https://faculty.nps.edu/brutzman >>>>>>>> >>>>>>>> >>>>>>>> From: x3d-public > on behalf of Joe D Williams via x3d-public > >>>>>>>> Sent: Saturday, February 15, 2025 6:55 PM >>>>>>>> To: Holger Seelig >; Andreas Plesch > >>>>>>>> Cc: joedwil at earthlink.net >; X3D >; Carol McDonald > >>>>>>>> >>>>>>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>>>>> >>>>>>>> > coord.point changes are very very expensive quickly, >>>>>>>> >>>>>>>> Right, the processing time gets expensive as the number of points moved. >>>>>>>> If level 1 segment geometry where the mesh is driven directly by a joint, then it easier since weight is always 1. >>>>>>>> For level 2 skin, the the weight (radial movement) applied by maybe multiple joints needs to be computed for each point. >>>>>>>> Finally, for both levels, the displacements for selected set of points needs to be applied. >>>>>>>> This implies multiple passes on the subject coordinates? >>>>>>>> Whatever, these operations are common where the applications deal with >>>>>>>> a complete mesh and with sparse points of a mesh for blending. . >>>>>>>> >>>>>>>> > with reference to CoordinateInterpolator, >>>>>>>> >>>>>>>> These are useful when controlling all points of a target mesh. >>>>>>>> All points of a mesh must be included and same number of points at each keyframe. >>>>>>>> This style was used in first step of the current example x3d FACS because >>>>>>>> face geometry is made from multiple shapes. CoordinateInterpolater sets >>>>>>>> for each shape for each elemental action moved the points. >>>>>>>> This was simplified to using the same face for each action example >>>>>>>> and then replaced the CIs with sets of Displacers. >>>>>>>> Now have developed further to combine individual actions to make a >>>>>>>> specific expression which consists of multiple elemental movements. >>>>>>>> However, I think we want to evolve towards a basic single mesh face >>>>>>>> with some individual shapes for like teeth, hair, eyeballs, eyelids, tongue, maybe ears? >>>>>>>> and using joint nodes to control, where appropriate. >>>>>>>> >>>>>>>> Regardless of how the points are moved for the next frame, it has to be >>>>>>>> considered that geometry points will be moved directly by joint rotations, >>>>>>>> by a weighting algorithm using multiple joint rotation inputs, >>>>>>>> and by one or more scalar-driven Displacer inputs. >>>>>>>> >>>>>>>> Thanks for HAnim, >>>>>>>> Joe >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -----Message----- >>>>>>>> From: Holger Seelig > >>>>>>>> Sent: Feb 9, 2025 11:23 AM >>>>>>>> To: Andreas Plesch > >>>>>>>> Cc: X3D >, Joseph D Williams >, Carol McDonald > >>>>>>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>>>>> >>>>>>>> I don't think so, coord.point changes are very very expensive quickly, and as Michalis said earlier, with reference to CoordinateInterpolator, we should get rid of them. >>>>>>>> >>>>>>>> Holger >>>>>>>> -- >>>>>>>> Holger Seelig >>>>>>>> Leipzig, Germany >>>>>>>> >>>>>>>> holger.seelig at yahoo.de >>>>>>>> https://create3000.github.io/x_ite/ >>>>>>>> >>>>>>>> Am 09.02.2025 um 19:44 schrieb Andreas Plesch >: >>>>>>>> Yes, that is an option. However,coord.point changes are very very expensive quickly, and as Michalis said earlier, with reference to CoordinateInterpolator, we should get rid of them. >>>>>>>> >>>>>>>> Andreas >>>>>>>> >>>>>>>> On Sun, Feb 9, 2025, 1:40?PM Holger Seelig > wrote: >>>>>>>> X_ITE applies the HAnimDisplacers in the shader, thus no coord.point field has to be changed. >>>>>>>> Maybe that helps. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Holger >>>>>>>> >>>>>>>> -- >>>>>>>> Holger Seelig >>>>>>>> Leipzig, Germany >>>>>>>> >>>>>>>> holger.seelig at yahoo.de >>>>>>>> https://create3000.github.io/x_ite/ >>>>>>>> >>>>>>>> Am 09.02.2025 um 19:33 schrieb Andreas Plesch via x3d-public >: >>>>>>>> >>>>>>>> That would be the point field of a Coordinate node >>>>>>>> >>>>>>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/rendering.html#Coordinate >>>>>>>> >>>>>>>> which is used by the coord field of >>>>>>>> >>>>>>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimSegment >>>>>>>> >>>>>>>> Andreas >>>>>>>> >>>>>>>> On Sun, Feb 9, 2025, 12:36?PM Joe D Williams > wrote: >>>>>>>> > coord node emit a point_changed event >>>>>>>> >>>>>>>> sorry,I don't see a field anywhere with that event. Displacer is likely to change several points when new weight is sent. All part of the cascade to produce the changed mesh? >>>>>>>> Thanks, >>>>>>>> Joe >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Andreas Plesch > >>>>>>>> Sent: Feb 9, 2025 4:25 AM >>>>>>>> To: Brutzman, Donald (Don) (CIV) > >>>>>>>> Cc: Extensible 3D (X3D) Graphics public discussion >, Carol McDonald >, Joe D Williams >, John Carlson > >>>>>>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>>>>> >>>>>>>> >>>>>>>> Don, Joe and John >>>>>>>> >>>>>>>> Thanks for collecting these references. >>>>>>>> >>>>>>>> But I am not sure if there is an answer to my original question. Let me rephrase a bit the question: >>>>>>>> >>>>>>>> After a Displacer contained in a Segment node receives a set_weight input, should then the coord node emit a point_changed event ? >>>>>>>> >>>>>>>> I do not think HAnim is concerned about that, so it is really a X3D question. >>>>>>>> >>>>>>>> Thanks, Andreas >>>>>>>> >>>>>>>> On Sun, Feb 9, 2025, 12:49?AM Brutzman, Donald (Don) (CIV) > wrote: >>>>>>>> Thanks for pointing in the right direction John. >>>>>>>> >>>>>>>> Direct links to functional requirements for Displacer in HAnim 2.0 specification: >>>>>>>> HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, Clause 4 Concepts, 4.7 Displacer object >>>>>>>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#DisplacerObject >>>>>>>> >>>>>>>> HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, Clause 6 Object interfaces, 6.6 Displacer >>>>>>>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer >>>>>>>> and >>>>>>>> X3D 4.0 Architecture, Clause 26 Humanoid Animation (HAnim) component, 26.3.1 HAnimDisplacer >>>>>>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimDisplacer >>>>>>>> and informative >>>>>>>> X3D Tooltips, HAnimDisplacer >>>>>>>> https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimDisplacer >>>>>>>> Thanks for implementation efforts and careful scrutiny. >>>>>>>> >>>>>>>> Questions and potential issues/clarifications/corrections are always welcome. >>>>>>>> >>>>>>>> >>>>>>>> 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 https://faculty.nps.edu/brutzman >>>>>>>> >>>>>>>> >>>>>>>> From: x3d-public > on behalf of John Carlson via x3d-public > >>>>>>>> Sent: Saturday, February 8, 2025 3:43 AM >>>>>>>> To: Extensible 3D (X3D) Graphics public discussion >; Carol McDonald >; Joe D Williams > >>>>>>>> Cc: John Carlson >; Andreas Plesch > >>>>>>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>>>>> >>>>>>>> Here?s what HAnim spec says under Displacer: >>>>>>>> >>>>>>>> https://www.web3d.org/documents/specifications/19774/V2.0/index.html >>>>>>>> >>>>>>>> ?For the Displacer objects that are contained in the displacers field of the Segment objects, the displacements are defined and applied in the Segment coordinate system. The base mesh for the morphed Segment is the original mesh defined in the Segment.? >>>>>>>> >>>>>>>> And here?s what it says under Segment: >>>>>>>> >>>>>>>> ? >>>>>>>> The coord field is used for Segment objects that have deformable meshes and shall contain coordinates referenced from the indexed mesh for the Segment object. The coordinates are given the same name as the Segment object, but with a "_coords" appended (e.g.,"skull_coords").? >>>>>>>> >>>>>>>> displacements are an offset from the mesh, with weight from 0 to 1. So weight times displacement is total offset from base mesh. 0 weight = no offset, 1 weight = full displacements offset >>>>>>>> >>>>>>>> The Coordinate point is maintained to handle weight = 0. Weight ranges from 0 to 1, but double check. >>>>>>>> >>>>>>>> Joe or Carol might know where to find it in the HAnim spec. >>>>>>>> >>>>>>>> I believe the answer is, ?during rendering,?. Since weight can vary with animation, and so can displacements, AFAIK. More than one displacer can be applied to the mesh. >>>>>>>> >>>>>>>> I have not read the spec. >>>>>>>> >>>>>>>> John >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public > wrote: >>>>>>>> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer >>>>>>>> >>>>>>>> does not directly explain what the effect of the displacer on the coord.point field of the containing HAnimSegment is. But it mentions the coord.point field and seems to imply that the coord.point field is involved. >>>>>>>> >>>>>>>> So the question is if the Displacer should alter the coord.point field in order to achieve a graphical displacement, or if the Browser should only apply the displacements during rendering without a change in the coord.point field ? >>>>>>>> >>>>>>>> This is relevant if the coord.point field is accessed by routes or scripts, in addition to displacers. >>>>>>>> >>>>>>>> Thanks for any feedback or ideas, >>>>>>>> >>>>>>>> Andreas >>>>>>>> >>>>>>>> -- >>>>>>>> Andreas Plesch >>>>>>>> Waltham, MA 02453 >>>>>>>> _______________________________________________ >>>>>>>> x3d-public mailing list >>>>>>>> x3d-public at web3d.org >>>>>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> x3d-public mailing list >>>>>>>> x3d-public at web3d.org >>>>>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> x3d-public mailing list >>>>>>>> x3d-public at web3d.org >>>>>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Andreas Plesch >>>>>> Waltham, MA 02453 >>>>>> >>>> >>>> >>>> _______________________________________________ >>>> x3d-public mailing list >>>> x3d-public at web3d.org >>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>> >>> >> _______________________________________________ >> x3d-public mailing list >> x3d-public at web3d.org >> http://web3d.org/mailman/listinfo/x3d-public_web3d.org > > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Fri Feb 21 13:31:12 2025 From: yottzumm at gmail.com (John Carlson) Date: Fri, 21 Feb 2025 15:31:12 -0600 Subject: [x3d-public] HAnimDisplacer effect on coord.point In-Reply-To: <6AEE6DDB-4A65-4E35-BF24-8811A22B1AB1@yahoo.de> References: <45a3be18-cfc5-ee96-12ce-6b129caea508@earthlink.net> <6AEE6DDB-4A65-4E35-BF24-8811A22B1AB1@yahoo.de> Message-ID: I didn?t understand that I needed a viewpoint inside the layers. Yes, I have been taking some time off for other activities. At one point, I worked 3 days straight without sleep or food. If I get going, sometimes I work even when the keyboard starts glowing (it?s not lighted). On Fri, Feb 21, 2025 at 2:23?PM Holger Seelig via x3d-public < x3d-public at web3d.org> wrote: > Think easy. Don?t make things more difficult than they are. > > Here a link ready to try out for the lazy ones: > > https://create3000.github.io/x_ite/playground/?url=https://gist.githubusercontent.com/create3000/7c9b576f8b3b52d1b51e3fb98b2e93dc/raw/23d76cfb19f7719af4c942f7d9553f386005238d/Layers.x3d > > Best regards, > Holger > > -- > Holger Seelig > Leipzig, Germany > > holger.seelig at yahoo.de > https://create3000.github.io/x_ite/ > > Am 21.02.2025 um 21:02 schrieb Holger Seelig via x3d-public < > x3d-public at web3d.org>: > > Using layer is more easy as using a ProximitySensor. Each Layer node has > its own X3DBindableNode stack, thus own viewpoints, background, fog, > navigation info. There can only be one active layer where navigation takes > place, to be specified with LayerSet.activeLayer. Example attached. > > Best regards, > Holger > > > > > -- > Holger Seelig > Leipzig, Germany > > holger.seelig at yahoo.de > https://create3000.github.io/x_ite/ > > Am 21.02.2025 um 20:37 schrieb John Carlson via x3d-public < > x3d-public at web3d.org>: > > Hmm. I took out the layering code in the latest zip, Clocks6.zip. Check > out Andreas? version if you?re having trouble unpacking it. > > Layering/Layout is like a 2D layer on top of a 3D layer. Holger?s point > was that it might be useful for a HUD. > > Please view current zip, around the ProximitySensor, and Hud ROUTEs. > > I don?t know how to make the menu rotate opposite the mouse, or how to > keep the menu in the HUD. > > I will look into Viewpoints. > > John > > On Fri, Feb 21, 2025 at 12:56?PM Joe D Williams > wrote: > >> > take out layering code ... >> >> >> I still don't see how layering will help in making a HUD. >> Can you have one viewpoint in one layer and navigate but have a second >> viewpoint in another layer that keeps the menu up front? >> Ithinktheprox sensor works everywhere bu x3dom? >> >> >> Thanks, >> Joe >> >> >> >> -----Original Message----- >> From: Extensible 3D (X3D) Graphics public discussion < >> x3d-public at web3d.org> >> Sent: Feb 20, 2025 12:18 PM >> To: Extensible 3D (X3D) Graphics public discussion >> Cc: John Carlson >> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >> >> >> I guess there could be some weird encoding or formatting issue. I use >> GitHub Bash inside Windows Terminal, I don?t know if I am encoding with >> Cp1252 or something Windows specific. I?ll do more research. >> >> On Thu, Feb 20, 2025 at 7:19?AM Holger Seelig via x3d-public < >> x3d-public at web3d.org> wrote: >> >>> For some reason I cannot open those *.zip files from you John. My system >>> say ?Unknown file format?. >>> >>> Best regards, >>> Holger >>> >>> -- >>> Holger Seelig >>> Leipzig, Germany >>> >>> holger.seelig at yahoo.de >>> https://create3000.github.io/x_ite/ >>> >>> >>> Am 20.02.2025 um 00:24 schrieb John Carlson : >>> >>> >>> >>> Attached is an example with a Hud. I can't get the menu (with the Hud >>> ProximitySensor and Transforms) to move differently than Jin, so I'm kind >>> of stuck. >>> >>> There's probably some silly problem that I missed. The menus move >>> with the mouse. >>> >>> Thanks for looking, >>> >>> John >>> >>> On Tue, Feb 18, 2025 at 6:49?PM John Carlson wrote: >>> >>>> Thanks for code samples, Joe. It looks like I can take out my >>>> Layering/Layout code and just focus on the menu. Sorry I am so slow on >>>> this, I think I might be hibernating. >>>> >>>> I?m looking at my GitHub commits and they have dropped drastically. >>>> This might be because I am spending more time helping others with recovery >>>> or just using social media too much. >>>> >>>> I will try to get to the HUD in the next two days. It was so cold, we >>>> didn?t even go to the dentist 45 miles away. We got out today though. >>>> >>>> John >>>> >>>> On Tue, Feb 18, 2025 at 6:38?PM Joe D Williams >>>> wrote: >>>> >>>>> > a HUD for Joe >>>>> >>>>> >>>>> A hud for the FACS example is needed because any navigation causes the >>>>> menu to disappear. The menu can be just like used on the Jin scaled with >>>>> animation example. However that uses a ProximitySensor which x3dom does not >>>>> support, for some reason. We use that a lot for start timers, timers, >>>>> etc.as well as being the typical way to keep a menu or scene data in >>>>> view. >>>>> If HTML/SVG is better, I have not seen it. I don't think Stacking >>>>> canvas is appropriate. Fine to think of XR for in-world 2d or3d HUDS but >>>>> does that sort ofdisplay really work any different than using prox sensor? >>>>> ProximitySensor is just so basic. >>>>> >>>>> >>>>> >>>>> >>>>> >>>> translation='-0.38 0.05 -0.75'> >>>>> rest of menu >>>>> >>>> toField='set_translation' toNode='HudXform'/> >>>>> >>>> toField='set_rotation' toNode='HudXform'/> >>>>> >>>>> >>>>> Thanks and Best, >>>>> Joe >>>>> >>>>> >>>>> huds3d >>>>> XR >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Andreas Plesch >>>>> Sent: Feb 18, 2025 11:45 AM >>>>> To: John Carlson >>>>> Cc: Extensible 3D (X3D) Graphics public discussion < >>>>> x3d-public at web3d.org>, Holger Seelig , Joseph >>>>> D Williams , Brutzman, Donald (Don) (CIV) < >>>>> brutzman at nps.edu>, Carol McDonald >>>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>> >>>>> >>>>> Please do not wait for x3dom. Both ProximitySensor and the Layering >>>>> component are lower priority. HTML/SVG is better suited for 2D HUDs and >>>>> layering can be approximated by stacking multiple X3D canvases/scenes. You >>>>> may also consider XR where immersion typically strongly favors in-world 3d >>>>> HUDs. >>>>> >>>>> Best, -Andreas >>>>> >>>>> On Tue, Feb 18, 2025 at 2:25?PM John Carlson >>>>> wrote: >>>>> >>>>>> Don, we?re currently working on a HUD for Joe, I don?t currently have >>>>>> an online example of that. >>>>>> >>>>>> Otherwise, I?m waiting on someone deciding which meshes to merge. I >>>>>> could take the lead on this. >>>>>> >>>>>> I could use a tutorial on the Layering and Layout components, >>>>>> examples don?t seem to help. I may try to adopt a 3D HUD based on >>>>>> examples. Something with the 2D overlay in WORLD space would help >>>>>> tremendously, or some conversion from WORLD space. >>>>>> >>>>>> We already have 3D menus, so a 3D HUD might be easiest. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> John >>>>>> On Mon, Feb 17, 2025 at 11:18?PM Brutzman, Donald (Don) (CIV) via >>>>>> x3d-public wrote: >>>>>> >>>>>>> Wondering, do we have a simple excerpted example that we can look at >>>>>>> yet? That will help guide these discussions. >>>>>>> >>>>>>> Don't need a full human body animation in all its displaceable >>>>>>> glory... >>>>>>> >>>>>>> >>>>>>> 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 >>>>>>> https://faculty.nps.edu/brutzman >>>>>>> >>>>>>> >>>>>>> >>>>>>> ------------------------------ >>>>>>> *From:* x3d-public on behalf of Joe >>>>>>> D Williams via x3d-public >>>>>>> *Sent:* Saturday, February 15, 2025 6:55 PM >>>>>>> *To:* Holger Seelig ; Andreas Plesch < >>>>>>> andreasplesch at gmail.com> >>>>>>> *Cc:* joedwil at earthlink.net ; X3D < >>>>>>> x3d-public at web3d.org>; Carol McDonald >>>>>>> >>>>>>> *Subject:* Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>>>> >>>>>>> > coord.point changes are very very expensive quickly, >>>>>>> >>>>>>> >>>>>>> Right, the processing time gets expensive as the number of points >>>>>>> moved. >>>>>>> If level 1 segment geometry where the mesh is driven directly by a >>>>>>> joint, then it easier since weight is always 1. >>>>>>> For level 2 skin, the the weight (radial movement) applied by maybe >>>>>>> multiple joints needs to be computed for each point. >>>>>>> Finally, for both levels, the displacements for selected set of >>>>>>> points needs to be applied. >>>>>>> This implies multiple passes on the subject coordinates? >>>>>>> Whatever, these operations are common where the applications deal >>>>>>> with >>>>>>> a complete mesh and with sparse points of a mesh for blending. . >>>>>>> >>>>>>> >>>>>>> > with reference to CoordinateInterpolator, >>>>>>> >>>>>>> >>>>>>> These are useful when controlling all points of a target mesh. >>>>>>> All points of a mesh must be included and same number of points at >>>>>>> each keyframe. >>>>>>> This style was used in first step of the current example x3d FACS >>>>>>> because >>>>>>> face geometry is made from multiple shapes. CoordinateInterpolater >>>>>>> sets >>>>>>> for each shape for each elemental action moved the points. >>>>>>> This was simplified to using the same face for each action example >>>>>>> and then replaced the CIs with sets of Displacers. >>>>>>> Now have developed further to combine individual actions to make a >>>>>>> specific expression which consists of multiple elemental movements. >>>>>>> However, I think we want to evolve towards a basic single mesh face >>>>>>> with some individual shapes for like teeth, hair, eyeballs, eyelids, >>>>>>> tongue, maybe ears? >>>>>>> and using joint nodes to control, where appropriate. >>>>>>> >>>>>>> >>>>>>> Regardless of how the points are moved for the next frame, it has to >>>>>>> be >>>>>>> considered that geometry points will be moved directly by joint >>>>>>> rotations, >>>>>>> by a weighting algorithm using multiple joint rotation inputs, >>>>>>> and by one or more scalar-driven Displacer inputs. >>>>>>> >>>>>>> >>>>>>> Thanks for HAnim, >>>>>>> Joe >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Message----- >>>>>>> From: Holger Seelig >>>>>>> Sent: Feb 9, 2025 11:23 AM >>>>>>> To: Andreas Plesch >>>>>>> Cc: X3D , Joseph D Williams < >>>>>>> joedwil at earthlink.net>, Carol McDonald >>>>>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>>>> >>>>>>> >>>>>>> I don't think so, coord.point changes are very very expensive >>>>>>> quickly, and as Michalis said earlier, with reference to >>>>>>> CoordinateInterpolator, we should get rid of them. >>>>>>> >>>>>>> Holger >>>>>>> -- >>>>>>> Holger Seelig >>>>>>> Leipzig, Germany >>>>>>> >>>>>>> holger.seelig at yahoo.de >>>>>>> https://create3000.github.io/x_ite/ >>>>>>> >>>>>>> Am 09.02.2025 um 19:44 schrieb Andreas Plesch < >>>>>>> andreasplesch at gmail.com>: >>>>>>> Yes, that is an option. However,coord.point changes are very very >>>>>>> expensive quickly, and as Michalis said earlier, with reference to >>>>>>> CoordinateInterpolator, we should get rid of them. >>>>>>> >>>>>>> Andreas >>>>>>> >>>>>>> On Sun, Feb 9, 2025, 1:40?PM Holger Seelig >>>>>>> wrote: >>>>>>> >>>>>>> X_ITE applies the HAnimDisplacers in the shader, thus no coord.point >>>>>>> field has to be changed. >>>>>>> Maybe that helps. >>>>>>> >>>>>>> Best regards, >>>>>>> Holger >>>>>>> >>>>>>> -- >>>>>>> Holger Seelig >>>>>>> Leipzig, Germany >>>>>>> >>>>>>> holger.seelig at yahoo.de >>>>>>> https://create3000.github.io/x_ite/ >>>>>>> >>>>>>> Am 09.02.2025 um 19:33 schrieb Andreas Plesch via x3d-public < >>>>>>> x3d-public at web3d.org>: >>>>>>> >>>>>>> That would be the point field of a Coordinate node >>>>>>> >>>>>>> >>>>>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/rendering.html#Coordinate >>>>>>> >>>>>>> which is used by the coord field of >>>>>>> >>>>>>> >>>>>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimSegment >>>>>>> >>>>>>> Andreas >>>>>>> >>>>>>> On Sun, Feb 9, 2025, 12:36?PM Joe D Williams >>>>>>> wrote: >>>>>>> >>>>>>> > coord node emit a point_changed event >>>>>>> >>>>>>> >>>>>>> sorry,I don't see a field anywhere with that event. Displacer is >>>>>>> likely to change several points when new weight is sent. All part of the >>>>>>> cascade to produce the changed mesh? >>>>>>> Thanks, >>>>>>> Joe >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Andreas Plesch >>>>>>> Sent: Feb 9, 2025 4:25 AM >>>>>>> To: Brutzman, Donald (Don) (CIV) >>>>>>> Cc: Extensible 3D (X3D) Graphics public discussion < >>>>>>> x3d-public at web3d.org>, Carol McDonald , Joe D >>>>>>> Williams , John Carlson >>>>>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>>>> >>>>>>> >>>>>>> Don, Joe and John >>>>>>> >>>>>>> Thanks for collecting these references. >>>>>>> >>>>>>> But I am not sure if there is an answer to my original question. Let >>>>>>> me rephrase a bit the question: >>>>>>> >>>>>>> After a Displacer contained in a Segment node receives a set_weight >>>>>>> input, should then the coord node emit a point_changed event ? >>>>>>> >>>>>>> I do not think HAnim is concerned about that, so it is really a X3D >>>>>>> question. >>>>>>> >>>>>>> Thanks, Andreas >>>>>>> >>>>>>> On Sun, Feb 9, 2025, 12:49?AM Brutzman, Donald (Don) (CIV) < >>>>>>> brutzman at nps.edu> wrote: >>>>>>> >>>>>>> Thanks for pointing in the right direction John. >>>>>>> >>>>>>> Direct links to functional requirements for Displacer in HAnim 2.0 >>>>>>> specification: >>>>>>> >>>>>>> - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, >>>>>>> Clause 4 Concepts, 4.7 Displacer object >>>>>>> - >>>>>>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#DisplacerObject >>>>>>> >>>>>>> - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, >>>>>>> Clause 6 Object interfaces, 6.6 Displacer >>>>>>> - >>>>>>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer >>>>>>> >>>>>>> and >>>>>>> >>>>>>> - X3D 4.0 Architecture, Clause 26 Humanoid Animation (HAnim) >>>>>>> component, 26.3.1 HAnimDisplacer >>>>>>> - >>>>>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimDisplacer >>>>>>> >>>>>>> and informative >>>>>>> >>>>>>> - X3D Tooltips, HAnimDisplacer >>>>>>> - >>>>>>> https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimDisplacer >>>>>>> >>>>>>> Thanks for implementation efforts and careful scrutiny. >>>>>>> >>>>>>> Questions and potential issues/clarifications/corrections are always >>>>>>> welcome. >>>>>>> >>>>>>> >>>>>>> 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 >>>>>>> https://faculty.nps.edu/brutzman >>>>>>> >>>>>>> >>>>>>> >>>>>>> ------------------------------ >>>>>>> *From:* x3d-public on behalf of John >>>>>>> Carlson via x3d-public >>>>>>> *Sent:* Saturday, February 8, 2025 3:43 AM >>>>>>> *To:* Extensible 3D (X3D) Graphics public discussion < >>>>>>> x3d-public at web3d.org>; Carol McDonald ; Joe D >>>>>>> Williams >>>>>>> *Cc:* John Carlson ; Andreas Plesch < >>>>>>> andreasplesch at gmail.com> >>>>>>> *Subject:* Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>>>> >>>>>>> Here?s what HAnim spec says under Displacer: >>>>>>> >>>>>>> https://www.web3d.org/documents/specifications/19774/V2.0/index.html >>>>>>> >>>>>>> ?For the *Displacer* objects that are contained in the *displacers* field >>>>>>> of the *Segment* objects, the *displacements* are defined and >>>>>>> applied in the *Segment* coordinate system. The base mesh for the >>>>>>> morphed *Segment* is the original mesh defined in the *Segment*.? >>>>>>> >>>>>>> And here?s what it says under Segment: >>>>>>> >>>>>>> ? >>>>>>> >>>>>>> The *coord* field is used for *Segment* objects that have >>>>>>> deformable meshes and shall contain coordinates referenced from the indexed >>>>>>> mesh for the *Segment* object. The coordinates are given the same >>>>>>> name as the *Segment* object, but with a "_coords" appended (e.g., >>>>>>> "skull_coords").? >>>>>>> displacements are an offset from the mesh, with weight from 0 to >>>>>>> 1. So weight times displacement is total offset from base mesh. 0 weight >>>>>>> = no offset, 1 weight = full displacements offset >>>>>>> >>>>>>> The Coordinate point is maintained to handle weight = 0. Weight >>>>>>> ranges from 0 to 1, but double check. >>>>>>> >>>>>>> Joe or Carol might know where to find it in the HAnim spec. >>>>>>> >>>>>>> I believe the answer is, ?during rendering,?. Since weight can vary >>>>>>> with animation, and so can displacements, AFAIK. More than one displacer >>>>>>> can be applied to the mesh. >>>>>>> >>>>>>> I have not read the spec. >>>>>>> >>>>>>> John >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public < >>>>>>> x3d-public at web3d.org> wrote: >>>>>>> >>>>>>> >>>>>>> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer >>>>>>> >>>>>>> does not directly explain what the effect of the displacer on the >>>>>>> coord.point field of the containing HAnimSegment is. But it mentions the >>>>>>> coord.point field and seems to imply that the coord.point field is involved. >>>>>>> >>>>>>> So the question is if the Displacer should alter the coord.point >>>>>>> field in order to achieve a graphical displacement, or if the Browser >>>>>>> should only apply the displacements during rendering without a change in >>>>>>> the coord.point field ? >>>>>>> >>>>>>> This is relevant if the coord.point field is accessed by routes or >>>>>>> scripts, in addition to displacers. >>>>>>> >>>>>>> Thanks for any feedback or ideas, >>>>>>> >>>>>>> Andreas >>>>>>> >>>>>>> -- >>>>>>> Andreas Plesch >>>>>>> Waltham, MA 02453 >>>>>>> _______________________________________________ >>>>>>> x3d-public mailing list >>>>>>> x3d-public at web3d.org >>>>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> x3d-public mailing list >>>>>>> x3d-public at web3d.org >>>>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> x3d-public mailing list >>>>>>> x3d-public at web3d.org >>>>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>>>> >>>>>> >>>>> >>>>> -- >>>>> Andreas Plesch >>>>> Waltham, MA 02453 >>>>> >>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> x3d-public mailing list >>> x3d-public at web3d.org >>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >> >> >> > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > > > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > > > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joedwil at earthlink.net Fri Feb 21 13:37:41 2025 From: joedwil at earthlink.net (Joe D Williams) Date: Fri, 21 Feb 2025 21:37:41 +0000 Subject: [x3d-public] HAnimDisplacer effect on coord.point Message-ID: That is real nice and readable. Not working in Castle, fine in freewrl. Does not decrease my simple need for ProximitySensor, especially when that basic tech is getting more important. Thanks and Very Best, Joe. -----Original Message----- From: Extensible 3D (X3D) Graphics public discussion Sent: Feb 21, 2025 12:23 PM To: X3D Cc: Holger Seelig Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point Think easy. Don’t make things more difficult than they are. Here a link ready to try out for the lazy ones: https://create3000.github.io/x_ite/playground/?url=https://gist.githubusercontent.com/create3000/7c9b576f8b3b52d1b51e3fb98b2e93dc/raw/23d76cfb19f7719af4c942f7d9553f386005238d/Layers.x3d Best regards, Holger -- Holger Seelig Leipzig, Germany holger.seelig at yahoo.de https://create3000.github.io/x_ite/ Am 21.02.2025 um 21:02 schrieb Holger Seelig via x3d-public : Using layer is more easy as using a ProximitySensor. Each Layer node has its own X3DBindableNode stack, thus own viewpoints, background, fog, navigation info. There can only be one active layer where navigation takes place, to be specified with LayerSet.activeLayer. Example attached. Best regards, Holger -- Holger Seelig Leipzig, Germany holger.seelig at yahoo.de https://create3000.github.io/x_ite/ Am 21.02.2025 um 20:37 schrieb John Carlson via x3d-public : Hmm. I took out the layering code in the latest zip, Clocks6.zip. Check out Andreas’ version if you’re having trouble unpacking it. Layering/Layout is like a 2D layer on top of a 3D layer. Holger’s point was that it might be useful for a HUD. Please view current zip, around the ProximitySensor, and Hud ROUTEs. I don’t know how to make the menu rotate opposite the mouse, or how to keep the menu in the HUD. I will look into Viewpoints. John On Fri, Feb 21, 2025 at 12:56?PM Joe D Williams wrote: > take out layering code ... I still don't see how layering will help in making a HUD. Can you have one viewpoint in one layer and navigate but have a second viewpoint in another layer that keeps the menu up front? Ithinktheprox sensor works everywhere bu x3dom? Thanks, Joe -----Original Message----- From: Extensible 3D (X3D) Graphics public discussion Sent: Feb 20, 2025 12:18 PM To: Extensible 3D (X3D) Graphics public discussion Cc: John Carlson Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point I guess there could be some weird encoding or formatting issue. I use GitHub Bash inside Windows Terminal, I don’t know if I am encoding with Cp1252 or something Windows specific. I’ll do more research. On Thu, Feb 20, 2025 at 7:19?AM Holger Seelig via x3d-public wrote: For some reason I cannot open those *.zip files from you John. My system say „Unknown file format“. Best regards, Holger -- Holger Seelig Leipzig, Germany holger.seelig at yahoo.de (mailto:holger.seelig at yahoo.de) https://create3000.github.io/x_ite/ Am 20.02.2025 um 00:24 schrieb John Carlson : Attached is an example with a Hud. I can't get the menu (with the Hud ProximitySensor and Transforms) to move differently than Jin, so I'm kind of stuck. There's probably some silly problem that I missed. The menus move with the mouse. Thanks for looking, John On Tue, Feb 18, 2025 at 6:49?PM John Carlson wrote: Thanks for code samples, Joe. It looks like I can take out my Layering/Layout code and just focus on the menu. Sorry I am so slow on this, I think I might be hibernating. I’m looking at my GitHub commits and they have dropped drastically. This might be because I am spending more time helping others with recovery or just using social media too much. I will try to get to the HUD in the next two days. It was so cold, we didn’t even go to the dentist 45 miles away. We got out today though. John On Tue, Feb 18, 2025 at 6:38?PM Joe D Williams wrote: > a HUD for Joe A hud for the FACS example is needed because any navigation causes the menu to disappear. The menu can be just like used on the Jin scaled with animation example. However that uses a ProximitySensor which x3dom does not support, for some reason. We use that a lot for start timers, timers, etc.as (http://etc.as/) well as being the typical way to keep a menu or scene data in view. If HTML/SVG is better, I have not seen it. I don't think Stacking canvas is appropriate. Fine to think of XR for in-world 2d or3d HUDS but does that sort ofdisplay really work any different than using prox sensor? ProximitySensor is just so basic. rest of menu Thanks and Best, Joe huds3d XR -----Original Message----- From: Andreas Plesch Sent: Feb 18, 2025 11:45 AM To: John Carlson Cc: Extensible 3D (X3D) Graphics public discussion , Holger Seelig , Joseph D Williams , Brutzman, Donald (Don) (CIV) , Carol McDonald Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point Please do not wait for x3dom. Both ProximitySensor and the Layering component are lower priority. HTML/SVG is better suited for 2D HUDs and layering can be approximated by stacking multiple X3D canvases/scenes. You may also consider XR where immersion typically strongly favors in-world 3d HUDs. Best, -Andreas On Tue, Feb 18, 2025 at 2:25?PM John Carlson wrote: Don, we’re currently working on a HUD for Joe, I don’t currently have an online example of that. Otherwise, I’m waiting on someone deciding which meshes to merge. I could take the lead on this. I could use a tutorial on the Layering and Layout components, examples don’t seem to help. I may try to adopt a 3D HUD based on examples. Something with the 2D overlay in WORLD space would help tremendously, or some conversion from WORLD space. We already have 3D menus, so a 3D HUD might be easiest. Thanks, John On Mon, Feb 17, 2025 at 11:18?PM Brutzman, Donald (Don) (CIV) via x3d-public wrote: Wondering, do we have a simple excerpted example that we can look at yet? That will help guide these discussions. Don't need a full human body animation in all its displaceable glory... all the best, Don -- Don Brutzman Naval Postgraduate School, Code USW/Br brutzman at nps.edu (mailto:brutzman at nps.edu) Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149 X3D graphics, virtual worlds, navy robotics https://faculty.nps.edu/brutzman From: x3d-public on behalf of Joe D Williams via x3d-public Sent: Saturday, February 15, 2025 6:55 PM To: Holger Seelig ; Andreas Plesch Cc: joedwil at earthlink.net (mailto:joedwil at earthlink.net) ; X3D ; Carol McDonald Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point > coord.point changes are very very expensive quickly, Right, the processing time gets expensive as the number of points moved. If level 1 segment geometry where the mesh is driven directly by a joint, then it easier since weight is always 1. For level 2 skin, the the weight (radial movement) applied by maybe multiple joints needs to be computed for each point. Finally, for both levels, the displacements for selected set of points needs to be applied. This implies multiple passes on the subject coordinates? Whatever, these operations are common where the applications deal with a complete mesh and with sparse points of a mesh for blending. . > with reference to CoordinateInterpolator, These are useful when controlling all points of a target mesh. All points of a mesh must be included and same number of points at each keyframe. This style was used in first step of the current example x3d FACS because face geometry is made from multiple shapes. CoordinateInterpolater sets for each shape for each elemental action moved the points. This was simplified to using the same face for each action example and then replaced the CIs with sets of Displacers. Now have developed further to combine individual actions to make a specific expression which consists of multiple elemental movements. However, I think we want to evolve towards a basic single mesh face with some individual shapes for like teeth, hair, eyeballs, eyelids, tongue, maybe ears? and using joint nodes to control, where appropriate. Regardless of how the points are moved for the next frame, it has to be considered that geometry points will be moved directly by joint rotations, by a weighting algorithm using multiple joint rotation inputs, and by one or more scalar-driven Displacer inputs. Thanks for HAnim, Joe -----Message----- From: Holger Seelig Sent: Feb 9, 2025 11:23 AM To: Andreas Plesch Cc: X3D , Joseph D Williams , Carol McDonald Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point I don't think so, coord.point changes are very very expensive quickly, and as Michalis said earlier, with reference to CoordinateInterpolator, we should get rid of them. Holger-- Holger Seelig Leipzig, Germany holger.seelig at yahoo.de (mailto:holger.seelig at yahoo.de) https://create3000.github.io/x_ite/ Am 09.02.2025 um 19:44 schrieb Andreas Plesch : Yes, that is an option. However,coord.point changes are very very expensive quickly, and as Michalis said earlier, with reference to CoordinateInterpolator, we should get rid of them. Andreas On Sun, Feb 9, 2025, 1:40?PM Holger Seelig wrote: X_ITE applies the HAnimDisplacers in the shader, thus no coord.point field has to be changed.Maybe that helps. Best regards, Holger -- Holger Seelig Leipzig, Germany holger.seelig at yahoo.de (mailto:holger.seelig at yahoo.de) https://create3000.github.io/x_ite/ Am 09.02.2025 um 19:33 schrieb Andreas Plesch via x3d-public : That would be the point field of a Coordinate node https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/rendering.html#Coordinate which is used by the coord field of https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimSegment Andreas On Sun, Feb 9, 2025, 12:36?PM Joe D Williams wrote: > coord node emit a point_changed event sorry,I don't see a field anywhere with that event. Displacer is likely to change several points when new weight is sent. All part of the cascade to produce the changed mesh? Thanks, Joe -----Original Message----- From: Andreas Plesch Sent: Feb 9, 2025 4:25 AM To: Brutzman, Donald (Don) (CIV) Cc: Extensible 3D (X3D) Graphics public discussion , Carol McDonald , Joe D Williams , John Carlson Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point Don, Joe and John Thanks for collecting these references. But I am not sure if there is an answer to my original question. Let me rephrase a bit the question: After a Displacer contained in a Segment node receives a set_weight input, should then the coord node emit a point_changed event ? I do not think HAnim is concerned about that, so it is really a X3D question. Thanks, Andreas On Sun, Feb 9, 2025, 12:49?AM Brutzman, Donald (Don) (CIV) wrote: Thanks for pointing in the right direction John. Direct links to functional requirements for Displacer in HAnim 2.0 specification: * HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, Clause 4 Concepts, 4.7 Displacer object * https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#DisplacerObject * HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, Clause 6 Object interfaces, 6.6 Displacer * https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer and * X3D 4.0 Architecture, Clause 26 Humanoid Animation (HAnim) component, 26.3.1 HAnimDisplacer * https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimDisplacer and informative * X3D Tooltips, HAnimDisplacer * https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimDisplacer Thanks for implementation efforts and careful scrutiny. Questions and potential issues/clarifications/corrections are always welcome. all the best, Don -- Don Brutzman Naval Postgraduate School, Code USW/Br brutzman at nps.edu (mailto:brutzman at nps.edu) Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149 X3D graphics, virtual worlds, navy robotics https://faculty.nps.edu/brutzman From: x3d-public on behalf of John Carlson via x3d-public Sent: Saturday, February 8, 2025 3:43 AM To: Extensible 3D (X3D) Graphics public discussion ; Carol McDonald ; Joe D Williams Cc: John Carlson ; Andreas Plesch Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point Here’s what HAnim spec says under Displacer: https://www.web3d.org/documents/specifications/19774/V2.0/index.html “For the Displacer objects that are contained in the displacers field of the Segment objects, the displacements are defined and applied in the Segment coordinate system. The base mesh for the morphed Segment is the original mesh defined in the Segment.” And here’s what it says under Segment: “ The coord field is used for Segment objects that have deformable meshes and shall contain coordinates referenced from the indexed mesh for the Segment object. The coordinates are given the same name as the Segment object, but with a "_coords" appended (e.g.,"skull_coords").” displacements are an offset from the mesh, with weight from 0 to 1. So weight times displacement is total offset from base mesh. 0 weight = no offset, 1 weight = full displacements offset The Coordinate point is maintained to handle weight = 0. Weight ranges from 0 to 1, but double check. Joe or Carol might know where to find it in the HAnim spec. I believe the answer is, “during rendering,”. Since weight can vary with animation, and so can displacements, AFAIK. More than one displacer can be applied to the mesh. I have not read the spec. John On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public wrote: https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer does not directly explain what the effect of the displacer on the coord.point field of the containing HAnimSegment is. But it mentions the coord.point field and seems to imply that the coord.point field is involved. So the question is if the Displacer should alter the coord.point field in order to achieve a graphical displacement, or if the Browser should only apply the displacements during rendering without a change in the coord.point field ? This is relevant if the coord.point field is accessed by routes or scripts, in addition to displacers. Thanks for any feedback or ideas, Andreas -- Andreas Plesch Waltham, MA 02453 _______________________________________________ x3d-public mailing list x3d-public at web3d.org (mailto:x3d-public at web3d.org) http://web3d.org/mailman/listinfo/x3d-public_web3d.org _______________________________________________ x3d-public mailing list x3d-public at web3d.org (mailto:x3d-public at web3d.org) http://web3d.org/mailman/listinfo/x3d-public_web3d.org _______________________________________________ x3d-public mailing list x3d-public at web3d.org (mailto:x3d-public at web3d.org) http://web3d.org/mailman/listinfo/x3d-public_web3d.org -- Andreas Plesch Waltham, MA 02453 _______________________________________________ x3d-public mailing list x3d-public at web3d.org (mailto:x3d-public at web3d.org) http://web3d.org/mailman/listinfo/x3d-public_web3d.org _______________________________________________ x3d-public mailing list x3d-public at web3d.org http://web3d.org/mailman/listinfo/x3d-public_web3d.org _______________________________________________ x3d-public mailing list x3d-public at web3d.org http://web3d.org/mailman/listinfo/x3d-public_web3d.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Fri Feb 21 13:48:53 2025 From: yottzumm at gmail.com (John Carlson) Date: Fri, 21 Feb 2025 15:48:53 -0600 Subject: [x3d-public] HAnimDisplacer effect on coord.point In-Reply-To: References: Message-ID: I agree. I had missed the required viewpoint to achieve what was necessary. I?ll try to get a FACS version out tonight, but no promises. I did try a simple approach, but without viewpoint, it failed. Maybe we can use Holger?s example as a test case for a Castle issue? Can we mix a ProximitySensor with layering? Ideas welcome. John On Fri, Feb 21, 2025 at 3:38?PM Joe D Williams via x3d-public < x3d-public at web3d.org> wrote: > That is real nice and readable. Not working in Castle, fine in freewrl. > > Does not decrease my simple need for ProximitySensor, especially when that > basic tech is getting more important. > > Thanks and Very Best, > > Joe. > > > > > > -----Original Message----- > From: Extensible 3D (X3D) Graphics public discussion > > Sent: Feb 21, 2025 12:23 PM > To: X3D > Cc: Holger Seelig > Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point > > > Think easy. Don?t make things more difficult than they are. > > Here a link ready to try out for the lazy ones: > > https://create3000.github.io/x_ite/playground/?url=https://gist.githubusercontent.com/create3000/7c9b576f8b3b52d1b51e3fb98b2e93dc/raw/23d76cfb19f7719af4c942f7d9553f386005238d/Layers.x3d > > Best regards, > Holger > > -- > Holger Seelig > Leipzig, Germany > > holger.seelig at yahoo.de > https://create3000.github.io/x_ite/ > > Am 21.02.2025 um 21:02 schrieb Holger Seelig via x3d-public < > x3d-public at web3d.org>: > Using layer is more easy as using a ProximitySensor. Each Layer node has > its own X3DBindableNode stack, thus own viewpoints, background, fog, > navigation info. There can only be one active layer where navigation takes > place, to be specified with LayerSet.activeLayer. Example attached. > > Best regards, > Holger > > > > > -- > Holger Seelig > Leipzig, Germany > > holger.seelig at yahoo.de > https://create3000.github.io/x_ite/ > > Am 21.02.2025 um 20:37 schrieb John Carlson via x3d-public < > x3d-public at web3d.org>: > Hmm. I took out the layering code in the latest zip, Clocks6.zip. Check > out Andreas? version if you?re having trouble unpacking it. > > Layering/Layout is like a 2D layer on top of a 3D layer. Holger?s point > was that it might be useful for a HUD. > > Please view current zip, around the ProximitySensor, and Hud ROUTEs. > > I don?t know how to make the menu rotate opposite the mouse, or how to > keep the menu in the HUD. > > I will look into Viewpoints. > > John > > On Fri, Feb 21, 2025 at 12:56?PM Joe D Williams > wrote: > >> > take out layering code ... >> >> >> I still don't see how layering will help in making a HUD. >> Can you have one viewpoint in one layer and navigate but have a second >> viewpoint in another layer that keeps the menu up front? >> Ithinktheprox sensor works everywhere bu x3dom? >> >> >> Thanks, >> Joe >> >> >> >> -----Original Message----- >> From: Extensible 3D (X3D) Graphics public discussion < >> x3d-public at web3d.org> >> Sent: Feb 20, 2025 12:18 PM >> To: Extensible 3D (X3D) Graphics public discussion >> Cc: John Carlson >> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >> >> >> I guess there could be some weird encoding or formatting issue. I use >> GitHub Bash inside Windows Terminal, I don?t know if I am encoding with >> Cp1252 or something Windows specific. I?ll do more research. >> >> On Thu, Feb 20, 2025 at 7:19?AM Holger Seelig via x3d-public < >> x3d-public at web3d.org> wrote: >> >>> For some reason I cannot open those *.zip files from you John. My system >>> say ?Unknown file format?. >>> >>> Best regards, >>> Holger >>> >>> -- >>> Holger Seelig >>> Leipzig, Germany >>> >>> holger.seelig at yahoo.de >>> https://create3000.github.io/x_ite/ >>> >>> >>> Am 20.02.2025 um 00:24 schrieb John Carlson : >>> >>> >>> >>> Attached is an example with a Hud. I can't get the menu (with the Hud >>> ProximitySensor and Transforms) to move differently than Jin, so I'm kind >>> of stuck. >>> >>> There's probably some silly problem that I missed. The menus move >>> with the mouse. >>> >>> Thanks for looking, >>> >>> John >>> >>> On Tue, Feb 18, 2025 at 6:49?PM John Carlson wrote: >>> >>>> Thanks for code samples, Joe. It looks like I can take out my >>>> Layering/Layout code and just focus on the menu. Sorry I am so slow on >>>> this, I think I might be hibernating. >>>> >>>> I?m looking at my GitHub commits and they have dropped drastically. >>>> This might be because I am spending more time helping others with recovery >>>> or just using social media too much. >>>> >>>> I will try to get to the HUD in the next two days. It was so cold, we >>>> didn?t even go to the dentist 45 miles away. We got out today though. >>>> >>>> John >>>> >>>> On Tue, Feb 18, 2025 at 6:38?PM Joe D Williams >>>> wrote: >>>> >>>>> > a HUD for Joe >>>>> >>>>> >>>>> A hud for the FACS example is needed because any navigation causes the >>>>> menu to disappear. The menu can be just like used on the Jin scaled with >>>>> animation example. However that uses a ProximitySensor which x3dom does not >>>>> support, for some reason. We use that a lot for start timers, timers, >>>>> etc.as well as being the typical way to keep a menu or scene data in >>>>> view. >>>>> If HTML/SVG is better, I have not seen it. I don't think Stacking >>>>> canvas is appropriate. Fine to think of XR for in-world 2d or3d HUDS but >>>>> does that sort ofdisplay really work any different than using prox sensor? >>>>> ProximitySensor is just so basic. >>>>> >>>>> >>>>> >>>>> >>>>> >>>> translation='-0.38 0.05 -0.75'> >>>>> rest of menu >>>>> >>>> toField='set_translation' toNode='HudXform'/> >>>>> >>>> toField='set_rotation' toNode='HudXform'/> >>>>> >>>>> >>>>> Thanks and Best, >>>>> Joe >>>>> >>>>> >>>>> huds3d >>>>> XR >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Andreas Plesch >>>>> Sent: Feb 18, 2025 11:45 AM >>>>> To: John Carlson >>>>> Cc: Extensible 3D (X3D) Graphics public discussion < >>>>> x3d-public at web3d.org>, Holger Seelig , Joseph >>>>> D Williams , Brutzman, Donald (Don) (CIV) < >>>>> brutzman at nps.edu>, Carol McDonald >>>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>> >>>>> >>>>> Please do not wait for x3dom. Both ProximitySensor and the Layering >>>>> component are lower priority. HTML/SVG is better suited for 2D HUDs and >>>>> layering can be approximated by stacking multiple X3D canvases/scenes. You >>>>> may also consider XR where immersion typically strongly favors in-world 3d >>>>> HUDs. >>>>> >>>>> Best, -Andreas >>>>> >>>>> On Tue, Feb 18, 2025 at 2:25?PM John Carlson >>>>> wrote: >>>>> >>>>>> Don, we?re currently working on a HUD for Joe, I don?t currently have >>>>>> an online example of that. >>>>>> >>>>>> Otherwise, I?m waiting on someone deciding which meshes to merge. I >>>>>> could take the lead on this. >>>>>> >>>>>> I could use a tutorial on the Layering and Layout components, >>>>>> examples don?t seem to help. I may try to adopt a 3D HUD based on >>>>>> examples. Something with the 2D overlay in WORLD space would help >>>>>> tremendously, or some conversion from WORLD space. >>>>>> >>>>>> We already have 3D menus, so a 3D HUD might be easiest. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> John >>>>>> On Mon, Feb 17, 2025 at 11:18?PM Brutzman, Donald (Don) (CIV) via >>>>>> x3d-public wrote: >>>>>> >>>>>>> Wondering, do we have a simple excerpted example that we can look at >>>>>>> yet? That will help guide these discussions. >>>>>>> >>>>>>> Don't need a full human body animation in all its displaceable >>>>>>> glory... >>>>>>> >>>>>>> >>>>>>> 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 >>>>>>> https://faculty.nps.edu/brutzman >>>>>>> >>>>>>> >>>>>>> >>>>>>> ------------------------------ >>>>>>> *From:* x3d-public on behalf of Joe >>>>>>> D Williams via x3d-public >>>>>>> *Sent:* Saturday, February 15, 2025 6:55 PM >>>>>>> *To:* Holger Seelig ; Andreas Plesch < >>>>>>> andreasplesch at gmail.com> >>>>>>> *Cc:* joedwil at earthlink.net ; X3D < >>>>>>> x3d-public at web3d.org>; Carol McDonald >>>>>>> >>>>>>> *Subject:* Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>>>> >>>>>>> > coord.point changes are very very expensive quickly, >>>>>>> >>>>>>> >>>>>>> Right, the processing time gets expensive as the number of points >>>>>>> moved. >>>>>>> If level 1 segment geometry where the mesh is driven directly by a >>>>>>> joint, then it easier since weight is always 1. >>>>>>> For level 2 skin, the the weight (radial movement) applied by maybe >>>>>>> multiple joints needs to be computed for each point. >>>>>>> Finally, for both levels, the displacements for selected set of >>>>>>> points needs to be applied. >>>>>>> This implies multiple passes on the subject coordinates? >>>>>>> Whatever, these operations are common where the applications deal >>>>>>> with >>>>>>> a complete mesh and with sparse points of a mesh for blending. . >>>>>>> >>>>>>> >>>>>>> > with reference to CoordinateInterpolator, >>>>>>> >>>>>>> >>>>>>> These are useful when controlling all points of a target mesh. >>>>>>> All points of a mesh must be included and same number of points at >>>>>>> each keyframe. >>>>>>> This style was used in first step of the current example x3d FACS >>>>>>> because >>>>>>> face geometry is made from multiple shapes. CoordinateInterpolater >>>>>>> sets >>>>>>> for each shape for each elemental action moved the points. >>>>>>> This was simplified to using the same face for each action example >>>>>>> and then replaced the CIs with sets of Displacers. >>>>>>> Now have developed further to combine individual actions to make a >>>>>>> specific expression which consists of multiple elemental movements. >>>>>>> However, I think we want to evolve towards a basic single mesh face >>>>>>> with some individual shapes for like teeth, hair, eyeballs, eyelids, >>>>>>> tongue, maybe ears? >>>>>>> and using joint nodes to control, where appropriate. >>>>>>> >>>>>>> >>>>>>> Regardless of how the points are moved for the next frame, it has to >>>>>>> be >>>>>>> considered that geometry points will be moved directly by joint >>>>>>> rotations, >>>>>>> by a weighting algorithm using multiple joint rotation inputs, >>>>>>> and by one or more scalar-driven Displacer inputs. >>>>>>> >>>>>>> >>>>>>> Thanks for HAnim, >>>>>>> Joe >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Message----- >>>>>>> From: Holger Seelig >>>>>>> Sent: Feb 9, 2025 11:23 AM >>>>>>> To: Andreas Plesch >>>>>>> Cc: X3D , Joseph D Williams < >>>>>>> joedwil at earthlink.net>, Carol McDonald >>>>>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>>>> >>>>>>> >>>>>>> I don't think so, coord.point changes are very very expensive >>>>>>> quickly, and as Michalis said earlier, with reference to >>>>>>> CoordinateInterpolator, we should get rid of them. >>>>>>> >>>>>>> Holger >>>>>>> -- >>>>>>> Holger Seelig >>>>>>> Leipzig, Germany >>>>>>> >>>>>>> holger.seelig at yahoo.de >>>>>>> https://create3000.github.io/x_ite/ >>>>>>> >>>>>>> Am 09.02.2025 um 19:44 schrieb Andreas Plesch < >>>>>>> andreasplesch at gmail.com>: >>>>>>> Yes, that is an option. However,coord.point changes are very very >>>>>>> expensive quickly, and as Michalis said earlier, with reference to >>>>>>> CoordinateInterpolator, we should get rid of them. >>>>>>> >>>>>>> Andreas >>>>>>> >>>>>>> On Sun, Feb 9, 2025, 1:40?PM Holger Seelig >>>>>>> wrote: >>>>>>> >>>>>>> X_ITE applies the HAnimDisplacers in the shader, thus no coord.point >>>>>>> field has to be changed. >>>>>>> Maybe that helps. >>>>>>> >>>>>>> Best regards, >>>>>>> Holger >>>>>>> >>>>>>> -- >>>>>>> Holger Seelig >>>>>>> Leipzig, Germany >>>>>>> >>>>>>> holger.seelig at yahoo.de >>>>>>> https://create3000.github.io/x_ite/ >>>>>>> >>>>>>> Am 09.02.2025 um 19:33 schrieb Andreas Plesch via x3d-public < >>>>>>> x3d-public at web3d.org>: >>>>>>> >>>>>>> That would be the point field of a Coordinate node >>>>>>> >>>>>>> >>>>>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/rendering.html#Coordinate >>>>>>> >>>>>>> which is used by the coord field of >>>>>>> >>>>>>> >>>>>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimSegment >>>>>>> >>>>>>> Andreas >>>>>>> >>>>>>> On Sun, Feb 9, 2025, 12:36?PM Joe D Williams >>>>>>> wrote: >>>>>>> >>>>>>> > coord node emit a point_changed event >>>>>>> >>>>>>> >>>>>>> sorry,I don't see a field anywhere with that event. Displacer is >>>>>>> likely to change several points when new weight is sent. All part of the >>>>>>> cascade to produce the changed mesh? >>>>>>> Thanks, >>>>>>> Joe >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Andreas Plesch >>>>>>> Sent: Feb 9, 2025 4:25 AM >>>>>>> To: Brutzman, Donald (Don) (CIV) >>>>>>> Cc: Extensible 3D (X3D) Graphics public discussion < >>>>>>> x3d-public at web3d.org>, Carol McDonald , Joe D >>>>>>> Williams , John Carlson >>>>>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>>>> >>>>>>> >>>>>>> Don, Joe and John >>>>>>> >>>>>>> Thanks for collecting these references. >>>>>>> >>>>>>> But I am not sure if there is an answer to my original question. Let >>>>>>> me rephrase a bit the question: >>>>>>> >>>>>>> After a Displacer contained in a Segment node receives a set_weight >>>>>>> input, should then the coord node emit a point_changed event ? >>>>>>> >>>>>>> I do not think HAnim is concerned about that, so it is really a X3D >>>>>>> question. >>>>>>> >>>>>>> Thanks, Andreas >>>>>>> >>>>>>> On Sun, Feb 9, 2025, 12:49?AM Brutzman, Donald (Don) (CIV) < >>>>>>> brutzman at nps.edu> wrote: >>>>>>> >>>>>>> Thanks for pointing in the right direction John. >>>>>>> >>>>>>> Direct links to functional requirements for Displacer in HAnim 2.0 >>>>>>> specification: >>>>>>> >>>>>>> - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, >>>>>>> Clause 4 Concepts, 4.7 Displacer object >>>>>>> - >>>>>>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#DisplacerObject >>>>>>> >>>>>>> - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, >>>>>>> Clause 6 Object interfaces, 6.6 Displacer >>>>>>> - >>>>>>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer >>>>>>> >>>>>>> and >>>>>>> >>>>>>> - X3D 4.0 Architecture, Clause 26 Humanoid Animation (HAnim) >>>>>>> component, 26.3.1 HAnimDisplacer >>>>>>> - >>>>>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimDisplacer >>>>>>> >>>>>>> and informative >>>>>>> >>>>>>> - X3D Tooltips, HAnimDisplacer >>>>>>> - >>>>>>> https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimDisplacer >>>>>>> >>>>>>> Thanks for implementation efforts and careful scrutiny. >>>>>>> >>>>>>> Questions and potential issues/clarifications/corrections are always >>>>>>> welcome. >>>>>>> >>>>>>> >>>>>>> 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 >>>>>>> https://faculty.nps.edu/brutzman >>>>>>> >>>>>>> >>>>>>> >>>>>>> ------------------------------ >>>>>>> *From:* x3d-public on behalf of John >>>>>>> Carlson via x3d-public >>>>>>> *Sent:* Saturday, February 8, 2025 3:43 AM >>>>>>> *To:* Extensible 3D (X3D) Graphics public discussion < >>>>>>> x3d-public at web3d.org>; Carol McDonald ; Joe D >>>>>>> Williams >>>>>>> *Cc:* John Carlson ; Andreas Plesch < >>>>>>> andreasplesch at gmail.com> >>>>>>> *Subject:* Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>>>> >>>>>>> Here?s what HAnim spec says under Displacer: >>>>>>> >>>>>>> https://www.web3d.org/documents/specifications/19774/V2.0/index.html >>>>>>> >>>>>>> ?For the *Displacer* objects that are contained in the *displacers* field >>>>>>> of the *Segment* objects, the *displacements* are defined and >>>>>>> applied in the *Segment* coordinate system. The base mesh for the >>>>>>> morphed *Segment* is the original mesh defined in the *Segment*.? >>>>>>> >>>>>>> And here?s what it says under Segment: >>>>>>> >>>>>>> ? >>>>>>> >>>>>>> The *coord* field is used for *Segment* objects that have >>>>>>> deformable meshes and shall contain coordinates referenced from the indexed >>>>>>> mesh for the *Segment* object. The coordinates are given the same >>>>>>> name as the *Segment* object, but with a "_coords" appended (e.g., >>>>>>> "skull_coords").? >>>>>>> displacements are an offset from the mesh, with weight from 0 to >>>>>>> 1. So weight times displacement is total offset from base mesh. 0 weight >>>>>>> = no offset, 1 weight = full displacements offset >>>>>>> >>>>>>> The Coordinate point is maintained to handle weight = 0. Weight >>>>>>> ranges from 0 to 1, but double check. >>>>>>> >>>>>>> Joe or Carol might know where to find it in the HAnim spec. >>>>>>> >>>>>>> I believe the answer is, ?during rendering,?. Since weight can vary >>>>>>> with animation, and so can displacements, AFAIK. More than one displacer >>>>>>> can be applied to the mesh. >>>>>>> >>>>>>> I have not read the spec. >>>>>>> >>>>>>> John >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public < >>>>>>> x3d-public at web3d.org> wrote: >>>>>>> >>>>>>> >>>>>>> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer >>>>>>> >>>>>>> does not directly explain what the effect of the displacer on the >>>>>>> coord.point field of the containing HAnimSegment is. But it mentions the >>>>>>> coord.point field and seems to imply that the coord.point field is involved. >>>>>>> >>>>>>> So the question is if the Displacer should alter the coord.point >>>>>>> field in order to achieve a graphical displacement, or if the Browser >>>>>>> should only apply the displacements during rendering without a change in >>>>>>> the coord.point field ? >>>>>>> >>>>>>> This is relevant if the coord.point field is accessed by routes or >>>>>>> scripts, in addition to displacers. >>>>>>> >>>>>>> Thanks for any feedback or ideas, >>>>>>> >>>>>>> Andreas >>>>>>> >>>>>>> -- >>>>>>> Andreas Plesch >>>>>>> Waltham, MA 02453 >>>>>>> _______________________________________________ >>>>>>> x3d-public mailing list >>>>>>> x3d-public at web3d.org >>>>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> x3d-public mailing list >>>>>>> x3d-public at web3d.org >>>>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> x3d-public mailing list >>>>>>> x3d-public at web3d.org >>>>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>>>> >>>>>> >>>>> >>>>> -- >>>>> Andreas Plesch >>>>> Waltham, MA 02453 >>>>> >>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> x3d-public mailing list >>> x3d-public at web3d.org >>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >> >> >> > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > > > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joedwil at earthlink.net Fri Feb 21 14:15:28 2025 From: joedwil at earthlink.net (Joe D Williams) Date: Fri, 21 Feb 2025 22:15:28 +0000 Subject: [x3d-public] HAnimDisplacer effect on coord.point Message-ID: <7854b9ea-7486-1e3b-ce6f-1cdaad7f0d6a@earthlink.net> > test case... fine idea, maybe add a layer maybe a sphere and switch between cube and sphere.leavingmenu asis. Thamks, Joe -----Original Message----- From: John Carlson Sent: Feb 21, 2025 2:12 PM To: Extensible 3D (X3D) Graphics public discussion , Michalis Kamburelis , Holger Seelig Cc: Joe D Williams Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point I agree. I had missed the required viewpoint to achieve what was necessary. I’ll try to get a FACS version out tonight, but no promises. I did try a simple approach, but without viewpoint, it failed. Maybe we can use Holger’s example as a test case for a Castle issue? Can we mix a ProximitySensor with layering? Ideas welcome. John On Fri, Feb 21, 2025 at 3:38?PM Joe D Williams via x3d-public wrote: That is real nice and readable. Not working in Castle, fine in freewrl. Does not decrease my simple need for ProximitySensor, especially when that basic tech is getting more important. Thanks and Very Best, Joe. -----Original Message----- From: Extensible 3D (X3D) Graphics public discussion Sent: Feb 21, 2025 12:23 PM To: X3D Cc: Holger Seelig Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point Think easy. Don’t make things more difficult than they are. Here a link ready to try out for the lazy ones: https://create3000.github.io/x_ite/playground/?url=https://gist.githubusercontent.com/create3000/7c9b576f8b3b52d1b51e3fb98b2e93dc/raw/23d76cfb19f7719af4c942f7d9553f386005238d/Layers.x3d Best regards, Holger -- Holger Seelig Leipzig, Germany holger.seelig at yahoo.de (mailto:holger.seelig at yahoo.de) https://create3000.github.io/x_ite/ Am 21.02.2025 um 21:02 schrieb Holger Seelig via x3d-public : Using layer is more easy as using a ProximitySensor. Each Layer node has its own X3DBindableNode stack, thus own viewpoints, background, fog, navigation info. There can only be one active layer where navigation takes place, to be specified with LayerSet.activeLayer. Example attached. Best regards, Holger -- Holger Seelig Leipzig, Germany holger.seelig at yahoo.de (mailto:holger.seelig at yahoo.de) https://create3000.github.io/x_ite/ Am 21.02.2025 um 20:37 schrieb John Carlson via x3d-public : Hmm. I took out the layering code in the latest zip, Clocks6.zip. Check out Andreas’ version if you’re having trouble unpacking it. Layering/Layout is like a 2D layer on top of a 3D layer. Holger’s point was that it might be useful for a HUD. Please view current zip, around the ProximitySensor, and Hud ROUTEs. I don’t know how to make the menu rotate opposite the mouse, or how to keep the menu in the HUD. I will look into Viewpoints. John On Fri, Feb 21, 2025 at 12:56?PM Joe D Williams wrote: > take out layering code ... I still don't see how layering will help in making a HUD. Can you have one viewpoint in one layer and navigate but have a second viewpoint in another layer that keeps the menu up front? Ithinktheprox sensor works everywhere bu x3dom? Thanks, Joe -----Original Message----- From: Extensible 3D (X3D) Graphics public discussion Sent: Feb 20, 2025 12:18 PM To: Extensible 3D (X3D) Graphics public discussion Cc: John Carlson Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point I guess there could be some weird encoding or formatting issue. I use GitHub Bash inside Windows Terminal, I don’t know if I am encoding with Cp1252 or something Windows specific. I’ll do more research. On Thu, Feb 20, 2025 at 7:19?AM Holger Seelig via x3d-public wrote: For some reason I cannot open those *.zip files from you John. My system say „Unknown file format“. Best regards, Holger -- Holger Seelig Leipzig, Germany holger.seelig at yahoo.de (mailto:holger.seelig at yahoo.de) https://create3000.github.io/x_ite/ Am 20.02.2025 um 00:24 schrieb John Carlson : Attached is an example with a Hud. I can't get the menu (with the Hud ProximitySensor and Transforms) to move differently than Jin, so I'm kind of stuck. There's probably some silly problem that I missed. The menus move with the mouse. Thanks for looking, John On Tue, Feb 18, 2025 at 6:49?PM John Carlson wrote: Thanks for code samples, Joe. It looks like I can take out my Layering/Layout code and just focus on the menu. Sorry I am so slow on this, I think I might be hibernating. I’m looking at my GitHub commits and they have dropped drastically. This might be because I am spending more time helping others with recovery or just using social media too much. I will try to get to the HUD in the next two days. It was so cold, we didn’t even go to the dentist 45 miles away. We got out today though. John On Tue, Feb 18, 2025 at 6:38?PM Joe D Williams wrote: > a HUD for Joe A hud for the FACS example is needed because any navigation causes the menu to disappear. The menu can be just like used on the Jin scaled with animation example. However that uses a ProximitySensor which x3dom does not support, for some reason. We use that a lot for start timers, timers, etc.as (http://etc.as/) well as being the typical way to keep a menu or scene data in view. If HTML/SVG is better, I have not seen it. I don't think Stacking canvas is appropriate. Fine to think of XR for in-world 2d or3d HUDS but does that sort ofdisplay really work any different than using prox sensor? ProximitySensor is just so basic. rest of menu Thanks and Best, Joe huds3d XR -----Original Message----- From: Andreas Plesch Sent: Feb 18, 2025 11:45 AM To: John Carlson Cc: Extensible 3D (X3D) Graphics public discussion , Holger Seelig , Joseph D Williams , Brutzman, Donald (Don) (CIV) , Carol McDonald Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point Please do not wait for x3dom. Both ProximitySensor and the Layering component are lower priority. HTML/SVG is better suited for 2D HUDs and layering can be approximated by stacking multiple X3D canvases/scenes. You may also consider XR where immersion typically strongly favors in-world 3d HUDs. Best, -Andreas On Tue, Feb 18, 2025 at 2:25?PM John Carlson wrote: Don, we’re currently working on a HUD for Joe, I don’t currently have an online example of that. Otherwise, I’m waiting on someone deciding which meshes to merge. I could take the lead on this. I could use a tutorial on the Layering and Layout components, examples don’t seem to help. I may try to adopt a 3D HUD based on examples. Something with the 2D overlay in WORLD space would help tremendously, or some conversion from WORLD space. We already have 3D menus, so a 3D HUD might be easiest. Thanks, John On Mon, Feb 17, 2025 at 11:18?PM Brutzman, Donald (Don) (CIV) via x3d-public wrote: Wondering, do we have a simple excerpted example that we can look at yet? That will help guide these discussions. Don't need a full human body animation in all its displaceable glory... all the best, Don -- Don Brutzman Naval Postgraduate School, Code USW/Br brutzman at nps.edu (mailto:brutzman at nps.edu) Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149 X3D graphics, virtual worlds, navy robotics https://faculty.nps.edu/brutzman From: x3d-public on behalf of Joe D Williams via x3d-public Sent: Saturday, February 15, 2025 6:55 PM To: Holger Seelig ; Andreas Plesch Cc: joedwil at earthlink.net (mailto:joedwil at earthlink.net) ; X3D ; Carol McDonald Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point > coord.point changes are very very expensive quickly, Right, the processing time gets expensive as the number of points moved. If level 1 segment geometry where the mesh is driven directly by a joint, then it easier since weight is always 1. For level 2 skin, the the weight (radial movement) applied by maybe multiple joints needs to be computed for each point. Finally, for both levels, the displacements for selected set of points needs to be applied. This implies multiple passes on the subject coordinates? Whatever, these operations are common where the applications deal with a complete mesh and with sparse points of a mesh for blending. . > with reference to CoordinateInterpolator, These are useful when controlling all points of a target mesh. All points of a mesh must be included and same number of points at each keyframe. This style was used in first step of the current example x3d FACS because face geometry is made from multiple shapes. CoordinateInterpolater sets for each shape for each elemental action moved the points. This was simplified to using the same face for each action example and then replaced the CIs with sets of Displacers. Now have developed further to combine individual actions to make a specific expression which consists of multiple elemental movements. However, I think we want to evolve towards a basic single mesh face with some individual shapes for like teeth, hair, eyeballs, eyelids, tongue, maybe ears? and using joint nodes to control, where appropriate. Regardless of how the points are moved for the next frame, it has to be considered that geometry points will be moved directly by joint rotations, by a weighting algorithm using multiple joint rotation inputs, and by one or more scalar-driven Displacer inputs. Thanks for HAnim, Joe -----Message----- From: Holger Seelig Sent: Feb 9, 2025 11:23 AM To: Andreas Plesch Cc: X3D , Joseph D Williams , Carol McDonald Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point I don't think so, coord.point changes are very very expensive quickly, and as Michalis said earlier, with reference to CoordinateInterpolator, we should get rid of them. Holger-- Holger Seelig Leipzig, Germany holger.seelig at yahoo.de (mailto:holger.seelig at yahoo.de) https://create3000.github.io/x_ite/ Am 09.02.2025 um 19:44 schrieb Andreas Plesch : Yes, that is an option. However,coord.point changes are very very expensive quickly, and as Michalis said earlier, with reference to CoordinateInterpolator, we should get rid of them. Andreas On Sun, Feb 9, 2025, 1:40?PM Holger Seelig wrote: X_ITE applies the HAnimDisplacers in the shader, thus no coord.point field has to be changed.Maybe that helps. Best regards, Holger -- Holger Seelig Leipzig, Germany holger.seelig at yahoo.de (mailto:holger.seelig at yahoo.de) https://create3000.github.io/x_ite/ Am 09.02.2025 um 19:33 schrieb Andreas Plesch via x3d-public : That would be the point field of a Coordinate node https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/rendering.html#Coordinate which is used by the coord field of https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimSegment Andreas On Sun, Feb 9, 2025, 12:36?PM Joe D Williams wrote: > coord node emit a point_changed event sorry,I don't see a field anywhere with that event. Displacer is likely to change several points when new weight is sent. All part of the cascade to produce the changed mesh? Thanks, Joe -----Original Message----- From: Andreas Plesch Sent: Feb 9, 2025 4:25 AM To: Brutzman, Donald (Don) (CIV) Cc: Extensible 3D (X3D) Graphics public discussion , Carol McDonald , Joe D Williams , John Carlson Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point Don, Joe and John Thanks for collecting these references. But I am not sure if there is an answer to my original question. Let me rephrase a bit the question: After a Displacer contained in a Segment node receives a set_weight input, should then the coord node emit a point_changed event ? I do not think HAnim is concerned about that, so it is really a X3D question. Thanks, Andreas On Sun, Feb 9, 2025, 12:49?AM Brutzman, Donald (Don) (CIV) wrote: Thanks for pointing in the right direction John. Direct links to functional requirements for Displacer in HAnim 2.0 specification: * HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, Clause 4 Concepts, 4.7 Displacer object * https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#DisplacerObject * HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, Clause 6 Object interfaces, 6.6 Displacer * https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer and * X3D 4.0 Architecture, Clause 26 Humanoid Animation (HAnim) component, 26.3.1 HAnimDisplacer * https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimDisplacer and informative * X3D Tooltips, HAnimDisplacer * https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimDisplacer Thanks for implementation efforts and careful scrutiny. Questions and potential issues/clarifications/corrections are always welcome. all the best, Don -- Don Brutzman Naval Postgraduate School, Code USW/Br brutzman at nps.edu (mailto:brutzman at nps.edu) Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149 X3D graphics, virtual worlds, navy robotics https://faculty.nps.edu/brutzman From: x3d-public on behalf of John Carlson via x3d-public Sent: Saturday, February 8, 2025 3:43 AM To: Extensible 3D (X3D) Graphics public discussion ; Carol McDonald ; Joe D Williams Cc: John Carlson ; Andreas Plesch Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point Here’s what HAnim spec says under Displacer: https://www.web3d.org/documents/specifications/19774/V2.0/index.html “For the Displacer objects that are contained in the displacers field of the Segment objects, the displacements are defined and applied in the Segment coordinate system. The base mesh for the morphed Segment is the original mesh defined in the Segment.” And here’s what it says under Segment: “ The coord field is used for Segment objects that have deformable meshes and shall contain coordinates referenced from the indexed mesh for the Segment object. The coordinates are given the same name as the Segment object, but with a "_coords" appended (e.g.,"skull_coords").” displacements are an offset from the mesh, with weight from 0 to 1. So weight times displacement is total offset from base mesh. 0 weight = no offset, 1 weight = full displacements offset The Coordinate point is maintained to handle weight = 0. Weight ranges from 0 to 1, but double check. Joe or Carol might know where to find it in the HAnim spec. I believe the answer is, “during rendering,”. Since weight can vary with animation, and so can displacements, AFAIK. More than one displacer can be applied to the mesh. I have not read the spec. John On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public wrote: https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer does not directly explain what the effect of the displacer on the coord.point field of the containing HAnimSegment is. But it mentions the coord.point field and seems to imply that the coord.point field is involved. So the question is if the Displacer should alter the coord.point field in order to achieve a graphical displacement, or if the Browser should only apply the displacements during rendering without a change in the coord.point field ? This is relevant if the coord.point field is accessed by routes or scripts, in addition to displacers. Thanks for any feedback or ideas, Andreas -- Andreas Plesch Waltham, MA 02453 _______________________________________________ x3d-public mailing list x3d-public at web3d.org (mailto:x3d-public at web3d.org) http://web3d.org/mailman/listinfo/x3d-public_web3d.org _______________________________________________ x3d-public mailing list x3d-public at web3d.org (mailto:x3d-public at web3d.org) http://web3d.org/mailman/listinfo/x3d-public_web3d.org _______________________________________________ x3d-public mailing list x3d-public at web3d.org (mailto:x3d-public at web3d.org) http://web3d.org/mailman/listinfo/x3d-public_web3d.org -- Andreas Plesch Waltham, MA 02453 _______________________________________________ x3d-public mailing list x3d-public at web3d.org (mailto:x3d-public at web3d.org) http://web3d.org/mailman/listinfo/x3d-public_web3d.org _______________________________________________ x3d-public mailing list x3d-public at web3d.org (mailto:x3d-public at web3d.org) http://web3d.org/mailman/listinfo/x3d-public_web3d.org _______________________________________________ x3d-public mailing list x3d-public at web3d.org (mailto:x3d-public at web3d.org) http://web3d.org/mailman/listinfo/x3d-public_web3d.org _______________________________________________ x3d-public mailing list x3d-public at web3d.org (mailto:x3d-public at web3d.org) http://web3d.org/mailman/listinfo/x3d-public_web3d.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From michalis.kambi at gmail.com Fri Feb 21 14:41:17 2025 From: michalis.kambi at gmail.com (Michalis Kamburelis) Date: Fri, 21 Feb 2025 23:41:17 +0100 Subject: [x3d-public] unmatched xxxTextureMapping In-Reply-To: References: Message-ID: This case is clarified in the text you link to: """ If the xxxTextureMapping field is not empty, it should refer to a corresponding X3DSingleTextureCoordinateNode node on a list of texture coordinates. [...] If no corresponding X3DSingleTextureCoordinateNode is found on this list, the X3D browser should determine texture coordinates as if xxxTextureMapping would be empty (see below). [...] If the xxxTextureMapping field is empty, then the first item on a list of texture coordinates is used (regardless of the mapping value). Only if no such texture coordinate exists (the list is empty), then then default texture coordinates for the specific geometry node are used. """ IOW, in simple terms: if xxxTextureMapping does not match any TextureCoordinate, then use the first TextureCoordinate. With the "first TextureCoordinate" meaning, in the order of preference, 1. the first in MultiTextureCoordinate list, 2. or just literally the only TextureCoordinate if no MultiTextureCoordinate was used, 3. or it can mean a fallback to default texture coord. Regards, Michalis pt., 21 lut 2025 o 19:31 Andreas Plesch via x3d-public napisa?(a): > > As https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/shape.html#TextureMappingCoordinate > > and co. explains the xxxTextureMapping field can be used to have multiple sets/channels of TextureCoordinates for the same Shape, for different types of Textures. > > There is one case which is not covered, presumably because it typically would indicate a mistake or oversight by the author. What should a browser implementation do if a material has a (non-default) xxxTextureMapping which does not match any of the provided TextureCoordinates for the Shape ? > > Possibilities are fall-back to default texture coordinates, fall-back to the first provided mapping, fall-back to constant uv 0,0 to indicate visually a problem, or undefined behaviour. > > Undefined behaviour might be ok but it is then worth pointing out in the spec. > > Thanks, -Andreas > > -- > Andreas Plesch > Waltham, MA 02453 > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org From brutzman at nps.edu Fri Feb 21 15:47:26 2025 From: brutzman at nps.edu (Brutzman, Donald (Don) (CIV)) Date: Fri, 21 Feb 2025 23:47:26 +0000 Subject: [x3d-public] unmatched xxxTextureMapping In-Reply-To: References: Message-ID: Thanks for noticing this. Yes, X3D does not get directive about how to handle problem cases because that can lead to unintended requirements or inefficient performance reactions trying to handle a trouble case in content. Thus browsers have latitude in how to respond (or ignore). Prose inputs welcome for an specification addition, e.g. perhaps something like * "Rendering response is undefined when provided texture coordinates do not correspond to other defined texture-mapping parameters." 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 https://faculty.nps.edu/brutzman ________________________________ From: x3d-public on behalf of Andreas Plesch via x3d-public Sent: Friday, February 21, 2025 10:31 AM To: X3D Graphics public mailing list Cc: Andreas Plesch Subject: [x3d-public] unmatched xxxTextureMapping As https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/shape.html#TextureMappingCoordinate and co. explains the xxxTextureMapping field can be used to have multiple sets/channels of TextureCoordinates for the same Shape, for different types of Textures. There is one case which is not covered, presumably because it typically would indicate a mistake or oversight by the author. What should a browser implementation do if a material has a (non-default) xxxTextureMapping which does not match any of the provided TextureCoordinates for the Shape ? Possibilities are fall-back to default texture coordinates, fall-back to the first provided mapping, fall-back to constant uv 0,0 to indicate visually a problem, or undefined behaviour. Undefined behaviour might be ok but it is then worth pointing out in the spec. Thanks, -Andreas -- Andreas Plesch Waltham, MA 02453 -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreasplesch at gmail.com Fri Feb 21 16:14:49 2025 From: andreasplesch at gmail.com (Andreas Plesch) Date: Fri, 21 Feb 2025 19:14:49 -0500 Subject: [x3d-public] unmatched xxxTextureMapping In-Reply-To: References: Message-ID: Thanks, very clear and makes sense. I read it multiple times and still missed that. Andreas On Fri, Feb 21, 2025, 5:41?PM Michalis Kamburelis wrote: > This case is clarified in the text you link to: > > """ > If the xxxTextureMapping field is not empty, it should refer to a > corresponding X3DSingleTextureCoordinateNode node on a list of texture > coordinates. [...] If no corresponding X3DSingleTextureCoordinateNode > is found on this list, the X3D browser should determine texture > coordinates as if xxxTextureMapping would be empty (see below). [...] > > If the xxxTextureMapping field is empty, then the first item on a list > of texture coordinates is used (regardless of the mapping value). Only > if no such texture coordinate exists (the list is empty), then then > default texture coordinates for the specific geometry node are used. > """ > > IOW, in simple terms: if xxxTextureMapping does not match any > TextureCoordinate, then use the first TextureCoordinate. With the > "first TextureCoordinate" meaning, in the order of preference, > 1. the first in MultiTextureCoordinate list, > 2. or just literally the only TextureCoordinate if no > MultiTextureCoordinate was used, > 3. or it can mean a fallback to default texture coord. > > Regards, > Michalis > > pt., 21 lut 2025 o 19:31 Andreas Plesch via x3d-public > napisa?(a): > > > > As > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/shape.html#TextureMappingCoordinate > > > > and co. explains the xxxTextureMapping field can be used to have > multiple sets/channels of TextureCoordinates for the same Shape, for > different types of Textures. > > > > There is one case which is not covered, presumably because it typically > would indicate a mistake or oversight by the author. What should a browser > implementation do if a material has a (non-default) xxxTextureMapping which > does not match any of the provided TextureCoordinates for the Shape ? > > > > Possibilities are fall-back to default texture coordinates, fall-back to > the first provided mapping, fall-back to constant uv 0,0 to indicate > visually a problem, or undefined behaviour. > > > > Undefined behaviour might be ok but it is then worth pointing out in the > spec. > > > > Thanks, -Andreas > > > > -- > > Andreas Plesch > > Waltham, MA 02453 > > _______________________________________________ > > x3d-public mailing list > > x3d-public at web3d.org > > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Fri Feb 21 22:47:55 2025 From: yottzumm at gmail.com (John Carlson) Date: Sat, 22 Feb 2025 00:47:55 -0600 Subject: [x3d-public] Facial Animation (HUD accomplished). Reset next. Message-ID: Here's the HUD that Holger mostly did, I just figured out how to do it in Python, and adjusted some parameters. I'm still thinking about how to accomplish calling set_fraction = 0 on the IntegerSequencers. Probably the easiest will be to send a set_fraction event into the ProtoInstances and do appropriate things with it, in ROUTEs. I'll also have to figure out how to get the event out of the Reset Menu Item. I'll move the Reset button below all the other MenuItems in the .x3d files, and pass set_fraction to the ProtoInstances, which will send a set_fraction event to whatever needs to receive it. I think I can just send the Reset_Clock fraction_changed event to all ProtoInstances as set_fraction. I'm going to rest my legs now -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Clocks7.zip Type: application/x-zip-compressed Size: 251747 bytes Desc: not available URL: From vmarchetti at kshell.com Sat Feb 22 05:27:13 2025 From: vmarchetti at kshell.com (vmarchetti at kshell.com) Date: Sat, 22 Feb 2025 08:27:13 -0500 Subject: [x3d-public] Facial Animation (HUD accomplished). Reset next. In-Reply-To: References: Message-ID: <41750F4D-4B2E-4053-9884-B3B0919FCE33@kshell.com> This is a really good set of examples. Few notes: The first Layer node has fields activeLayer and order defined as XML attributes, these are fields in LayerSet but not in Layer. X-ITE Is tolerant of this, castle viewer is not. The text of either x3d example can be loaded into the X-ITE playground at https://create3000.github.io/x_ite/playground/ and it works, because the url for the ImageTexture includes both a local file system reference and a publicly accessible URL at web.org Vince Marchetti > On Feb 22, 2025, at 1:47?AM, John Carlson via x3d-public wrote: > > Here's the HUD that Holger mostly did, I just figured out how to do it in Python, and adjusted some parameters. > > I'm still thinking about how to accomplish calling set_fraction = 0 on the IntegerSequencers. Probably the easiest will be to send a set_fraction event into the ProtoInstances and do appropriate things with it, in ROUTEs. I'll also have to figure out how to get the event out of the Reset Menu Item. > > I'll move the Reset button below all the other MenuItems in the .x3d files, and pass set_fraction to the ProtoInstances, which will send a set_fraction event to whatever needs to receive it. > > I think I can just send the Reset_Clock fraction_changed event to all ProtoInstances as set_fraction. > > I'm going to rest my legs now > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Sat Feb 22 09:14:17 2025 From: yottzumm at gmail.com (John Carlson) Date: Sat, 22 Feb 2025 11:14:17 -0600 Subject: [x3d-public] Facial Animation (HUD accomplished). Reset next. In-Reply-To: <41750F4D-4B2E-4053-9884-B3B0919FCE33@kshell.com> References: <41750F4D-4B2E-4053-9884-B3B0919FCE33@kshell.com> Message-ID: I guess I saw that, and didn?t do anything about it. Oops! Maybe that will fix freewrl. Lax copy/paste! John On Sat, Feb 22, 2025 at 7:45?AM vmarchetti--- via x3d-public < x3d-public at web3d.org> wrote: > This is a really good set of examples. > > Few notes: > The first Layer node has fields activeLayer and order defined as XML > attributes, these are fields in LayerSet but not in Layer. X-ITE Is > tolerant of this, castle viewer is not. > > The text of either x3d example can be loaded into the X-ITE playground at > https://create3000.github.io/x_ite/playground/ and it works, because the > url for the ImageTexture includes both a local file system reference and a > publicly accessible URL at web.org > > Vince Marchetti > > > On Feb 22, 2025, at 1:47?AM, John Carlson via x3d-public < > x3d-public at web3d.org> wrote: > > Here's the HUD that Holger mostly did, I just figured out how to do it in > Python, and adjusted some parameters. > > I'm still thinking about how to accomplish calling set_fraction = 0 on the > IntegerSequencers. Probably the easiest will be to send a set_fraction > event into the ProtoInstances and do appropriate things with it, > in ROUTEs. I'll also have to figure out how to get the event out of the > Reset Menu Item. > > I'll move the Reset button below all the other MenuItems in the .x3d > files, and pass set_fraction to the ProtoInstances, which will send a > set_fraction event to whatever needs to receive it. > > I think I can just send the Reset_Clock fraction_changed event to all > ProtoInstances as set_fraction. > > I'm going to rest my legs now > > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > > > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Sat Feb 22 09:23:53 2025 From: yottzumm at gmail.com (John Carlson) Date: Sat, 22 Feb 2025 11:23:53 -0600 Subject: [x3d-public] Facial Animation (HUD accomplished). Reset next. In-Reply-To: References: Message-ID: Note that the ProximitySensor is available, but it?s not currently tied to anything. Ideas for including the sensor with the rest of the scene are welcome. John On Sat, Feb 22, 2025 at 12:47?AM John Carlson wrote: > Here's the HUD that Holger mostly did, I just figured out how to do it in > Python, and adjusted some parameters. > > I'm still thinking about how to accomplish calling set_fraction = 0 on the > IntegerSequencers. Probably the easiest will be to send a set_fraction > event into the ProtoInstances and do appropriate things with it, > in ROUTEs. I'll also have to figure out how to get the event out of the > Reset Menu Item. > > I'll move the Reset button below all the other MenuItems in the .x3d > files, and pass set_fraction to the ProtoInstances, which will send a > set_fraction event to whatever needs to receive it. > > I think I can just send the Reset_Clock fraction_changed event to all > ProtoInstances as set_fraction. > > I'm going to rest my legs now > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joedwil at earthlink.net Sat Feb 22 13:32:50 2025 From: joedwil at earthlink.net (joedwil at earthlink.net) Date: Sat, 22 Feb 2025 21:32:50 +0000 Subject: [x3d-public] MetaVerse Conveniences Message-ID: <189a33e7-7e69-9f0a-864a-51396b56728f@earthlink.net> As the MetaVerse evolves it begins to take into considerations of the existing WWW with considerable interest taken with the idea of Accessibility. The idea is how can the standards-track web handle users with the sort of handicaps that prevent the transfer of information, for example hearing or vision or the ability to navigate. That is all good,but the MetaVerse concept moves that consideration into an area that includes an Avatar as well as a User. In order for the user to be immersed, the Avatar must be immersed. If the User is inconvenienced by lack of an interface with the Avatar, or if the Avatar is inconvenienced by lack of interface with the environment then the experience cannot be truly immersive. So, I wish to introduce the idea of Convenience. Human and Avatar and Host Union MetaVerse Data and Logic Interfaces INTERNET ACCESSABILITY = METAVERSE CONVENIENCES = Augmentations and Extensions to Avatar and User and Environment to make the standards-track MetaVerse Fully Inclusive. Objective: Fully Inclusive MetaVerse. I am just thinking that any problem the Avatar has experiencing the environment, or any issues the User has controlling or experiencing the avatar's interactions with the environment is an inconvenience. So, some sort of Convenience interface is required bridge the gap(s). https://metaverse-standards.org/domain-groups/accessibility-in-the-metaverse/ So, I want to work with the idea that there are Conveniences that allow (1) the Avatar to take full advantage of the environmental interfaces offered to the Avatar, as well as (2) Conveniences that will allow the User to take full advantage of certain capabilities of the Avatar and the Environment to sense and transport information the User. Thanks and All Best, Joe From yottzumm at gmail.com Sat Feb 22 17:26:50 2025 From: yottzumm at gmail.com (John Carlson) Date: Sat, 22 Feb 2025 19:26:50 -0600 Subject: [x3d-public] MetaVerse Conveniences In-Reply-To: <189a33e7-7e69-9f0a-864a-51396b56728f@earthlink.net> References: <189a33e7-7e69-9f0a-864a-51396b56728f@earthlink.net> Message-ID: I?m on board with this Joe, while I have not participated much in MSF, there a a couple of key technologies: The Tatum Robotics artificial signing arm: https://tatumrobotics.com CMU?s robot sweaters: https://www.cs.cmu.edu/news/2023/robot-sweater My apologies for not sharing sooner. I recently restarted research in the area. Recently, I discovered SignLLM: https://signllm.github.io They are collecting sign language data for incorporation into an LLM. John On Sat, Feb 22, 2025 at 3:33?PM Joe D Williams via x3d-public < x3d-public at web3d.org> wrote: > As the MetaVerse evolves it begins to take into considerations of the > existing WWW > with considerable interest taken with the idea of Accessibility. The idea > is how can > the standards-track web handle users with the sort of handicaps that > prevent > the transfer of information, for example hearing or vision or the ability > to navigate. > > That is all good,but the MetaVerse concept moves that consideration into > an area > that includes an Avatar as well as a User. In order for the user to be > immersed, > the Avatar must be immersed. If the User is inconvenienced by lack of an > interface > with the Avatar, or if the Avatar is inconvenienced by lack of interface > with the > environment then the experience cannot be truly immersive. > > So, I wish to introduce the idea of Convenience. > > Human and Avatar and Host Union > > MetaVerse Data and Logic Interfaces > > INTERNET ACCESSABILITY = > METAVERSE CONVENIENCES = > > Augmentations and Extensions to > Avatar and User and Environment > to make the standards-track > MetaVerse Fully Inclusive. > > Objective: Fully Inclusive MetaVerse. > > I am just thinking that any problem the Avatar has experiencing > the environment, or any issues the User has controlling or > experiencing the avatar's interactions with the environment is > an inconvenience. > So, some sort of Convenience interface is required bridge the gap(s). > > > https://metaverse-standards.org/domain-groups/accessibility-in-the-metaverse/ > > So, I want to work with the idea that there are Conveniences that allow > (1) the Avatar to take full advantage of the environmental interfaces > offered to the Avatar, as well as > (2) Conveniences that will allow the User to take full advantage of > certain capabilities of the Avatar and the Environment to sense > and transport information the User. > > Thanks and All Best, > Joe > > > > > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Sat Feb 22 18:41:44 2025 From: yottzumm at gmail.com (John Carlson) Date: Sat, 22 Feb 2025 20:41:44 -0600 Subject: [x3d-public] HAnimDisplacer effect on coord.point In-Reply-To: <7854b9ea-7486-1e3b-ce6f-1cdaad7f0d6a@earthlink.net> References: <7854b9ea-7486-1e3b-ce6f-1cdaad7f0d6a@earthlink.net> Message-ID: I believe we can swap between active layers, using a ROUTE, and one should be able to change the active layer in LayerSet. So an active Layer could also be an animation??? Can I group ROUTEs in layers to activate only one set? I will work on DEFing layers for accessibility. If we decide on 3 or more layers, I can work on appropriate USEs in each layer. Another thing which may increase accessibility is turning the ProtoInstance tags into MenuItem tags. I have not tried this before, so I don?t know if it works in all browsers. I think Andreas worked on this for X3DOM. If you have any ideas for adding a viewpoint to Clocks6.zip, great! So we need to decide to go with Clocks6.zip or Clocks7.zip, or both. If there is better ways of selecting from a menu, perhaps by removing Protos or doing keyboard navigation, I?m all ears. Currently, one should be able jump between TimeSensors? John On Fri, Feb 21, 2025 at 4:15?PM Joe D Williams wrote: > > test case... > > > > fine idea, maybe add a layer maybe a sphere and switch between cube and > sphere.leavingmenu asis. > > Thamks, > > Joe > > > > > > > > -----Original Message----- > From: John Carlson > Sent: Feb 21, 2025 2:12 PM > To: Extensible 3D (X3D) Graphics public discussion , > Michalis Kamburelis , Holger Seelig < > holger.seelig at yahoo.de> > Cc: Joe D Williams > Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point > > > I agree. I had missed the required viewpoint to achieve what was > necessary. I?ll try to get a FACS version out tonight, but no promises. I > did try a simple approach, but without viewpoint, it failed. > > Maybe we can use Holger?s example as a test case for a Castle issue? > > Can we mix a ProximitySensor with layering? Ideas welcome. > > John > > On Fri, Feb 21, 2025 at 3:38?PM Joe D Williams via x3d-public < > x3d-public at web3d.org> wrote: > >> That is real nice and readable. Not working in Castle, fine in freewrl. >> >> Does not decrease my simple need for ProximitySensor, especially when >> that basic tech is getting more important. >> >> Thanks and Very Best, >> >> Joe. >> >> >> >> >> >> -----Original Message----- >> From: Extensible 3D (X3D) Graphics public discussion < >> x3d-public at web3d.org> >> Sent: Feb 21, 2025 12:23 PM >> To: X3D >> Cc: Holger Seelig >> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >> >> >> Think easy. Don?t make things more difficult than they are. >> >> Here a link ready to try out for the lazy ones: >> >> https://create3000.github.io/x_ite/playground/?url=https://gist.githubusercontent.com/create3000/7c9b576f8b3b52d1b51e3fb98b2e93dc/raw/23d76cfb19f7719af4c942f7d9553f386005238d/Layers.x3d >> >> Best regards, >> Holger >> >> -- >> Holger Seelig >> Leipzig, Germany >> >> holger.seelig at yahoo.de >> https://create3000.github.io/x_ite/ >> >> Am 21.02.2025 um 21:02 schrieb Holger Seelig via x3d-public < >> x3d-public at web3d.org>: >> Using layer is more easy as using a ProximitySensor. Each Layer node has >> its own X3DBindableNode stack, thus own viewpoints, background, fog, >> navigation info. There can only be one active layer where navigation takes >> place, to be specified with LayerSet.activeLayer. Example attached. >> >> Best regards, >> Holger >> >> >> >> >> -- >> Holger Seelig >> Leipzig, Germany >> >> holger.seelig at yahoo.de >> https://create3000.github.io/x_ite/ >> >> Am 21.02.2025 um 20:37 schrieb John Carlson via x3d-public < >> x3d-public at web3d.org>: >> Hmm. I took out the layering code in the latest zip, Clocks6.zip. Check >> out Andreas? version if you?re having trouble unpacking it. >> >> Layering/Layout is like a 2D layer on top of a 3D layer. Holger?s point >> was that it might be useful for a HUD. >> >> Please view current zip, around the ProximitySensor, and Hud ROUTEs. >> >> I don?t know how to make the menu rotate opposite the mouse, or how to >> keep the menu in the HUD. >> >> I will look into Viewpoints. >> >> John >> >> On Fri, Feb 21, 2025 at 12:56?PM Joe D Williams >> wrote: >> >>> > take out layering code ... >>> >>> >>> I still don't see how layering will help in making a HUD. >>> Can you have one viewpoint in one layer and navigate but have a second >>> viewpoint in another layer that keeps the menu up front? >>> Ithinktheprox sensor works everywhere bu x3dom? >>> >>> >>> Thanks, >>> Joe >>> >>> >>> >>> -----Original Message----- >>> From: Extensible 3D (X3D) Graphics public discussion < >>> x3d-public at web3d.org> >>> Sent: Feb 20, 2025 12:18 PM >>> To: Extensible 3D (X3D) Graphics public discussion >> > >>> Cc: John Carlson >>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>> >>> >>> I guess there could be some weird encoding or formatting issue. I use >>> GitHub Bash inside Windows Terminal, I don?t know if I am encoding with >>> Cp1252 or something Windows specific. I?ll do more research. >>> >>> On Thu, Feb 20, 2025 at 7:19?AM Holger Seelig via x3d-public < >>> x3d-public at web3d.org> wrote: >>> >>>> For some reason I cannot open those *.zip files from you John. My >>>> system say ?Unknown file format?. >>>> >>>> Best regards, >>>> Holger >>>> >>>> -- >>>> Holger Seelig >>>> Leipzig, Germany >>>> >>>> holger.seelig at yahoo.de >>>> https://create3000.github.io/x_ite/ >>>> >>>> >>> Am 20.02.2025 um 00:24 schrieb John Carlson : >>>> >>>> >>>> >>>> Attached is an example with a Hud. I can't get the menu (with the Hud >>>> ProximitySensor and Transforms) to move differently than Jin, so I'm kind >>>> of stuck. >>>> >>>> There's probably some silly problem that I missed. The menus move >>>> with the mouse. >>>> >>>> Thanks for looking, >>>> >>>> John >>>> >>>> On Tue, Feb 18, 2025 at 6:49?PM John Carlson >>>> wrote: >>>> >>>>> Thanks for code samples, Joe. It looks like I can take out my >>>>> Layering/Layout code and just focus on the menu. Sorry I am so slow on >>>>> this, I think I might be hibernating. >>>>> >>>>> I?m looking at my GitHub commits and they have dropped drastically. >>>>> This might be because I am spending more time helping others with recovery >>>>> or just using social media too much. >>>>> >>>>> I will try to get to the HUD in the next two days. It was so cold, we >>>>> didn?t even go to the dentist 45 miles away. We got out today though. >>>>> >>>>> John >>>>> >>>>> On Tue, Feb 18, 2025 at 6:38?PM Joe D Williams >>>>> wrote: >>>>> >>>>>> > a HUD for Joe >>>>>> >>>>>> >>>>>> A hud for the FACS example is needed because any navigation causes >>>>>> the menu to disappear. The menu can be just like used on the Jin scaled >>>>>> with animation example. However that uses a ProximitySensor which x3dom >>>>>> does not support, for some reason. We use that a lot for start timers, >>>>>> timers, etc.as well as being the typical way to keep a menu or scene >>>>>> data in view. >>>>>> If HTML/SVG is better, I have not seen it. I don't think Stacking >>>>>> canvas is appropriate. Fine to think of XR for in-world 2d or3d HUDS but >>>>>> does that sort ofdisplay really work any different than using prox sensor? >>>>>> ProximitySensor is just so basic. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> translation='-0.38 0.05 -0.75'> >>>>>> rest of menu >>>>>> >>>>> toField='set_translation' toNode='HudXform'/> >>>>>> >>>>> toField='set_rotation' toNode='HudXform'/> >>>>>> >>>>>> >>>>>> Thanks and Best, >>>>>> Joe >>>>>> >>>>>> >>>>>> huds3d >>>>>> XR >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Andreas Plesch >>>>>> Sent: Feb 18, 2025 11:45 AM >>>>>> To: John Carlson >>>>>> Cc: Extensible 3D (X3D) Graphics public discussion < >>>>>> x3d-public at web3d.org>, Holger Seelig , >>>>>> Joseph D Williams , Brutzman, Donald (Don) >>>>>> (CIV) , Carol McDonald >>>>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>>> >>>>>> >>>>>> Please do not wait for x3dom. Both ProximitySensor and the Layering >>>>>> component are lower priority. HTML/SVG is better suited for 2D HUDs and >>>>>> layering can be approximated by stacking multiple X3D canvases/scenes. You >>>>>> may also consider XR where immersion typically strongly favors in-world 3d >>>>>> HUDs. >>>>>> >>>>>> Best, -Andreas >>>>>> >>>>>> On Tue, Feb 18, 2025 at 2:25?PM John Carlson >>>>>> wrote: >>>>>> >>>>>>> Don, we?re currently working on a HUD for Joe, I don?t currently >>>>>>> have an online example of that. >>>>>>> >>>>>>> Otherwise, I?m waiting on someone deciding which meshes to merge. I >>>>>>> could take the lead on this. >>>>>>> >>>>>>> I could use a tutorial on the Layering and Layout components, >>>>>>> examples don?t seem to help. I may try to adopt a 3D HUD based on >>>>>>> examples. Something with the 2D overlay in WORLD space would help >>>>>>> tremendously, or some conversion from WORLD space. >>>>>>> >>>>>>> We already have 3D menus, so a 3D HUD might be easiest. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> John >>>>>>> On Mon, Feb 17, 2025 at 11:18?PM Brutzman, Donald (Don) (CIV) via >>>>>>> x3d-public wrote: >>>>>>> >>>>>>>> Wondering, do we have a simple excerpted example that we can look >>>>>>>> at yet? That will help guide these discussions. >>>>>>>> >>>>>>>> Don't need a full human body animation in all its displaceable >>>>>>>> glory... >>>>>>>> >>>>>>>> >>>>>>>> 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 >>>>>>>> https://faculty.nps.edu/brutzman >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ------------------------------ >>>>>>>> *From:* x3d-public on behalf of Joe >>>>>>>> D Williams via x3d-public >>>>>>>> *Sent:* Saturday, February 15, 2025 6:55 PM >>>>>>>> *To:* Holger Seelig ; Andreas Plesch < >>>>>>>> andreasplesch at gmail.com> >>>>>>>> *Cc:* joedwil at earthlink.net ; X3D < >>>>>>>> x3d-public at web3d.org>; Carol McDonald >>>>>>>> >>>>>>>> *Subject:* Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>>>>> >>>>>>>> > coord.point changes are very very expensive quickly, >>>>>>>> >>>>>>>> >>>>>>>> Right, the processing time gets expensive as the number of points >>>>>>>> moved. >>>>>>>> If level 1 segment geometry where the mesh is driven directly by a >>>>>>>> joint, then it easier since weight is always 1. >>>>>>>> For level 2 skin, the the weight (radial movement) applied by maybe >>>>>>>> multiple joints needs to be computed for each point. >>>>>>>> Finally, for both levels, the displacements for selected set of >>>>>>>> points needs to be applied. >>>>>>>> This implies multiple passes on the subject coordinates? >>>>>>>> Whatever, these operations are common where the applications deal >>>>>>>> with >>>>>>>> a complete mesh and with sparse points of a mesh for blending. . >>>>>>>> >>>>>>>> >>>>>>>> > with reference to CoordinateInterpolator, >>>>>>>> >>>>>>>> >>>>>>>> These are useful when controlling all points of a target mesh. >>>>>>>> All points of a mesh must be included and same number of points at >>>>>>>> each keyframe. >>>>>>>> This style was used in first step of the current example x3d FACS >>>>>>>> because >>>>>>>> face geometry is made from multiple shapes. CoordinateInterpolater >>>>>>>> sets >>>>>>>> for each shape for each elemental action moved the points. >>>>>>>> This was simplified to using the same face for each action example >>>>>>>> and then replaced the CIs with sets of Displacers. >>>>>>>> Now have developed further to combine individual actions to make a >>>>>>>> specific expression which consists of multiple elemental movements. >>>>>>>> However, I think we want to evolve towards a basic single mesh face >>>>>>>> with some individual shapes for like teeth, hair, eyeballs, >>>>>>>> eyelids, tongue, maybe ears? >>>>>>>> and using joint nodes to control, where appropriate. >>>>>>>> >>>>>>>> >>>>>>>> Regardless of how the points are moved for the next frame, it has >>>>>>>> to be >>>>>>>> considered that geometry points will be moved directly by joint >>>>>>>> rotations, >>>>>>>> by a weighting algorithm using multiple joint rotation inputs, >>>>>>>> and by one or more scalar-driven Displacer inputs. >>>>>>>> >>>>>>>> >>>>>>>> Thanks for HAnim, >>>>>>>> Joe >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -----Message----- >>>>>>>> From: Holger Seelig >>>>>>>> Sent: Feb 9, 2025 11:23 AM >>>>>>>> To: Andreas Plesch >>>>>>>> Cc: X3D , Joseph D Williams < >>>>>>>> joedwil at earthlink.net>, Carol McDonald >>>>>>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>>>>> >>>>>>>> >>>>>>>> I don't think so, coord.point changes are very very expensive >>>>>>>> quickly, and as Michalis said earlier, with reference to >>>>>>>> CoordinateInterpolator, we should get rid of them. >>>>>>>> >>>>>>>> Holger >>>>>>>> -- >>>>>>>> Holger Seelig >>>>>>>> Leipzig, Germany >>>>>>>> >>>>>>>> holger.seelig at yahoo.de >>>>>>>> https://create3000.github.io/x_ite/ >>>>>>>> >>>>>>>> Am 09.02.2025 um 19:44 schrieb Andreas Plesch < >>>>>>>> andreasplesch at gmail.com>: >>>>>>>> Yes, that is an option. However,coord.point changes are very very >>>>>>>> expensive quickly, and as Michalis said earlier, with reference to >>>>>>>> CoordinateInterpolator, we should get rid of them. >>>>>>>> >>>>>>>> Andreas >>>>>>>> >>>>>>>> On Sun, Feb 9, 2025, 1:40?PM Holger Seelig >>>>>>>> wrote: >>>>>>>> >>>>>>>> X_ITE applies the HAnimDisplacers in the shader, thus no >>>>>>>> coord.point field has to be changed. >>>>>>>> Maybe that helps. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Holger >>>>>>>> >>>>>>>> -- >>>>>>>> Holger Seelig >>>>>>>> Leipzig, Germany >>>>>>>> >>>>>>>> holger.seelig at yahoo.de >>>>>>>> https://create3000.github.io/x_ite/ >>>>>>>> >>>>>>>> Am 09.02.2025 um 19:33 schrieb Andreas Plesch via x3d-public < >>>>>>>> x3d-public at web3d.org>: >>>>>>>> >>>>>>>> That would be the point field of a Coordinate node >>>>>>>> >>>>>>>> >>>>>>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/rendering.html#Coordinate >>>>>>>> >>>>>>>> which is used by the coord field of >>>>>>>> >>>>>>>> >>>>>>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimSegment >>>>>>>> >>>>>>>> Andreas >>>>>>>> >>>>>>>> On Sun, Feb 9, 2025, 12:36?PM Joe D Williams >>>>>>>> wrote: >>>>>>>> >>>>>>>> > coord node emit a point_changed event >>>>>>>> >>>>>>>> >>>>>>>> sorry,I don't see a field anywhere with that event. Displacer is >>>>>>>> likely to change several points when new weight is sent. All part of the >>>>>>>> cascade to produce the changed mesh? >>>>>>>> Thanks, >>>>>>>> Joe >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Andreas Plesch >>>>>>>> Sent: Feb 9, 2025 4:25 AM >>>>>>>> To: Brutzman, Donald (Don) (CIV) >>>>>>>> Cc: Extensible 3D (X3D) Graphics public discussion < >>>>>>>> x3d-public at web3d.org>, Carol McDonald , Joe D >>>>>>>> Williams , John Carlson >>>>>>>> Subject: Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>>>>> >>>>>>>> >>>>>>>> Don, Joe and John >>>>>>>> >>>>>>>> Thanks for collecting these references. >>>>>>>> >>>>>>>> But I am not sure if there is an answer to my original question. >>>>>>>> Let me rephrase a bit the question: >>>>>>>> >>>>>>>> After a Displacer contained in a Segment node receives a set_weight >>>>>>>> input, should then the coord node emit a point_changed event ? >>>>>>>> >>>>>>>> I do not think HAnim is concerned about that, so it is really a X3D >>>>>>>> question. >>>>>>>> >>>>>>>> Thanks, Andreas >>>>>>>> >>>>>>>> On Sun, Feb 9, 2025, 12:49?AM Brutzman, Donald (Don) (CIV) < >>>>>>>> brutzman at nps.edu> wrote: >>>>>>>> >>>>>>>> Thanks for pointing in the right direction John. >>>>>>>> >>>>>>>> Direct links to functional requirements for Displacer in HAnim 2.0 >>>>>>>> specification: >>>>>>>> >>>>>>>> - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, >>>>>>>> Clause 4 Concepts, 4.7 Displacer object >>>>>>>> - >>>>>>>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/concepts.html#DisplacerObject >>>>>>>> >>>>>>>> - HAnim 2.0. Part 1: Humanoid animation (HAnim) architecture, >>>>>>>> Clause 6 Object interfaces, 6.6 Displacer >>>>>>>> - >>>>>>>> https://www.web3d.org/documents/specifications/19774/V2.0/Architecture/ObjectInterfaces.html#Displacer >>>>>>>> >>>>>>>> and >>>>>>>> >>>>>>>> - X3D 4.0 Architecture, Clause 26 Humanoid Animation (HAnim) >>>>>>>> component, 26.3.1 HAnimDisplacer >>>>>>>> - >>>>>>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/hanim.html#HAnimDisplacer >>>>>>>> >>>>>>>> and informative >>>>>>>> >>>>>>>> - X3D Tooltips, HAnimDisplacer >>>>>>>> - >>>>>>>> https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimDisplacer >>>>>>>> >>>>>>>> Thanks for implementation efforts and careful scrutiny. >>>>>>>> >>>>>>>> Questions and potential issues/clarifications/corrections are >>>>>>>> always welcome. >>>>>>>> >>>>>>>> >>>>>>>> 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 >>>>>>>> https://faculty.nps.edu/brutzman >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ------------------------------ >>>>>>>> *From:* x3d-public on behalf of >>>>>>>> John Carlson via x3d-public >>>>>>>> *Sent:* Saturday, February 8, 2025 3:43 AM >>>>>>>> *To:* Extensible 3D (X3D) Graphics public discussion < >>>>>>>> x3d-public at web3d.org>; Carol McDonald ; Joe D >>>>>>>> Williams >>>>>>>> *Cc:* John Carlson ; Andreas Plesch < >>>>>>>> andreasplesch at gmail.com> >>>>>>>> *Subject:* Re: [x3d-public] HAnimDisplacer effect on coord.point >>>>>>>> >>>>>>>> Here?s what HAnim spec says under Displacer: >>>>>>>> >>>>>>>> https://www.web3d.org/documents/specifications/19774/V2.0/index.html >>>>>>>> >>>>>>>> ?For the *Displacer* objects that are contained in the *displacers* field >>>>>>>> of the *Segment* objects, the *displacements* are defined and >>>>>>>> applied in the *Segment* coordinate system. The base mesh for the >>>>>>>> morphed *Segment* is the original mesh defined in the *Segment*.? >>>>>>>> >>>>>>>> And here?s what it says under Segment: >>>>>>>> >>>>>>>> ? >>>>>>>> >>>>>>>> The *coord* field is used for *Segment* objects that have >>>>>>>> deformable meshes and shall contain coordinates referenced from the indexed >>>>>>>> mesh for the *Segment* object. The coordinates are given the same >>>>>>>> name as the *Segment* object, but with a "_coords" appended (e.g., >>>>>>>> "skull_coords").? >>>>>>>> displacements are an offset from the mesh, with weight from 0 to >>>>>>>> 1. So weight times displacement is total offset from base mesh. 0 weight >>>>>>>> = no offset, 1 weight = full displacements offset >>>>>>>> >>>>>>>> The Coordinate point is maintained to handle weight = 0. Weight >>>>>>>> ranges from 0 to 1, but double check. >>>>>>>> >>>>>>>> Joe or Carol might know where to find it in the HAnim spec. >>>>>>>> >>>>>>>> I believe the answer is, ?during rendering,?. Since weight can vary >>>>>>>> with animation, and so can displacements, AFAIK. More than one displacer >>>>>>>> can be applied to the mesh. >>>>>>>> >>>>>>>> I have not read the spec. >>>>>>>> >>>>>>>> John >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Sat, Feb 8, 2025 at 5:13?AM Andreas Plesch via x3d-public < >>>>>>>> x3d-public at web3d.org> wrote: >>>>>>>> >>>>>>>> >>>>>>>> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/hanim.html#HAnimDisplacer >>>>>>>> >>>>>>>> does not directly explain what the effect of the displacer on the >>>>>>>> coord.point field of the containing HAnimSegment is. But it mentions the >>>>>>>> coord.point field and seems to imply that the coord.point field is involved. >>>>>>>> >>>>>>>> So the question is if the Displacer should alter the coord.point >>>>>>>> field in order to achieve a graphical displacement, or if the Browser >>>>>>>> should only apply the displacements during rendering without a change in >>>>>>>> the coord.point field ? >>>>>>>> >>>>>>>> This is relevant if the coord.point field is accessed by routes or >>>>>>>> scripts, in addition to displacers. >>>>>>>> >>>>>>>> Thanks for any feedback or ideas, >>>>>>>> >>>>>>>> Andreas >>>>>>>> >>>>>>>> -- >>>>>>>> Andreas Plesch >>>>>>>> Waltham, MA 02453 >>>>>>>> _______________________________________________ >>>>>>>> x3d-public mailing list >>>>>>>> x3d-public at web3d.org >>>>>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> x3d-public mailing list >>>>>>>> x3d-public at web3d.org >>>>>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> x3d-public mailing list >>>>>>>> x3d-public at web3d.org >>>>>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Andreas Plesch >>>>>> Waltham, MA 02453 >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> x3d-public mailing list >>>> x3d-public at web3d.org >>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>> >>> >>> >> _______________________________________________ >> x3d-public mailing list >> x3d-public at web3d.org >> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >> >> _______________________________________________ >> x3d-public mailing list >> x3d-public at web3d.org >> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >> >> >> _______________________________________________ >> x3d-public mailing list >> x3d-public at web3d.org >> http://web3d.org/mailman/listinfo/x3d-public_web3d.org > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Sat Feb 22 22:05:40 2025 From: yottzumm at gmail.com (John Carlson) Date: Sun, 23 Feb 2025 00:05:40 -0600 Subject: [x3d-public] MetaVerse Conveniences In-Reply-To: References: <189a33e7-7e69-9f0a-864a-51396b56728f@earthlink.net> Message-ID: Here?s more tentative information for a data source for several sign languages data sets. Unfortunately, Protactile is not yet included. https://signllm.github.io/Prompt2Sign/ If one is building a simulated signer or mannequin/robotic signer, especially for describing 3D graphics scenes, please let me know. I know Don sent information on one company. I?ll look for more information on Protactile data sources. John On Sat, Feb 22, 2025 at 7:26?PM John Carlson wrote: > I?m on board with this Joe, while I have not participated much in MSF, > there a a couple of key technologies: > > The Tatum Robotics artificial signing arm: > > https://tatumrobotics.com > > CMU?s robot sweaters: > > https://www.cs.cmu.edu/news/2023/robot-sweater > > > My apologies for not sharing sooner. I recently restarted research in the > area. > > Recently, I discovered SignLLM: > https://signllm.github.io > > They are collecting sign language data for incorporation into an LLM. > > John > > > On Sat, Feb 22, 2025 at 3:33?PM Joe D Williams via x3d-public < > x3d-public at web3d.org> wrote: > >> As the MetaVerse evolves it begins to take into considerations of the >> existing WWW >> with considerable interest taken with the idea of Accessibility. The idea >> is how can >> the standards-track web handle users with the sort of handicaps that >> prevent >> the transfer of information, for example hearing or vision or the ability >> to navigate. >> >> That is all good,but the MetaVerse concept moves that consideration into >> an area >> that includes an Avatar as well as a User. In order for the user to be >> immersed, >> the Avatar must be immersed. If the User is inconvenienced by lack of an >> interface >> with the Avatar, or if the Avatar is inconvenienced by lack of interface >> with the >> environment then the experience cannot be truly immersive. >> >> So, I wish to introduce the idea of Convenience. >> >> Human and Avatar and Host Union >> >> MetaVerse Data and Logic Interfaces >> >> INTERNET ACCESSABILITY = >> METAVERSE CONVENIENCES = >> >> Augmentations and Extensions to >> Avatar and User and Environment >> to make the standards-track >> MetaVerse Fully Inclusive. >> >> Objective: Fully Inclusive MetaVerse. >> >> I am just thinking that any problem the Avatar has experiencing >> the environment, or any issues the User has controlling or >> experiencing the avatar's interactions with the environment is >> an inconvenience. >> So, some sort of Convenience interface is required bridge the gap(s). >> >> >> https://metaverse-standards.org/domain-groups/accessibility-in-the-metaverse/ >> >> So, I want to work with the idea that there are Conveniences that allow >> (1) the Avatar to take full advantage of the environmental interfaces >> offered to the Avatar, as well as >> (2) Conveniences that will allow the User to take full advantage of >> certain capabilities of the Avatar and the Environment to sense >> and transport information the User. >> >> Thanks and All Best, >> Joe >> >> >> >> >> _______________________________________________ >> x3d-public mailing list >> x3d-public at web3d.org >> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Mon Feb 24 02:09:45 2025 From: yottzumm at gmail.com (John Carlson) Date: Mon, 24 Feb 2025 04:09:45 -0600 Subject: [x3d-public] Open dyslexic and/or (unfortunately) comicsans fonts Message-ID: If someone knows how change the fonts of the standards to OpenDyslexic or ComicSans, that might be a great accessibility experiment. -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger.seelig at yahoo.de Mon Feb 24 02:48:47 2025 From: holger.seelig at yahoo.de (Holger Seelig) Date: Mon, 24 Feb 2025 11:48:47 +0100 Subject: [x3d-public] Open dyslexic and/or (unfortunately) comicsans fonts In-Reply-To: References: Message-ID: With X_ITE you can use a URL in the family field of a FontStyle node to specify a path to a custom font file. Provided you have one of these fonts, it should be very easy: Supported File Formats: https://create3000.github.io/x_ite/components/text/fontstyle/#supported-file-formats Best regards, Holger -- Holger Seelig Leipzig, Germany holger.seelig at yahoo.de https://create3000.github.io/x_ite/ > Am 24.02.2025 um 11:09 schrieb John Carlson via x3d-public : > > If someone knows how change the fonts of the standards to OpenDyslexic or ComicSans, that might be a great accessibility experiment. _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From brutzman at nps.edu Mon Feb 24 09:32:28 2025 From: brutzman at nps.edu (Brutzman, Donald (Don) (CIV)) Date: Mon, 24 Feb 2025 17:32:28 +0000 Subject: [x3d-public] Open dyslexic and/or (unfortunately) comicsans fonts; draft X3D 4.1 prose for font files and libraries In-Reply-To: References: Message-ID: Wow, really super Holger! ? There was a conversation about this on x3d-public a few years back... We committed to adding it in X3D 4.1 and (if I recall correctly) also noted that adding a url field might enable usage of larger font files. I've attempted to capture this candidate specification change in a Mantis issue. All review, feedback, and improvements are always welcome. * Mantis 1490 FontStyle handling of font files and font libraries * https://mantis.web3d.org/view.php?id=1490 Description. A goal for X3D 4.1 is use of font files in FontStyle (see Mantis 0001464). Addition of individual-font files might be accomplished by listing the font file name in the FontStyle 'family' field. Referencing different fonts in a single combined font library file may require an additional field, for example 'url'. In general the use of a font library may be preferred, but repeatedly run-time retrieval of a font library is not desirable, since the file might be quite large and rarely changing. This might be noted in the specification prose, e.g. - "MFString [in,out] url [] [URI]" - "The family field may list a specific font file. A font listed in the family field may be provided by a corresponding font library." - "The url field may refer to a font library. Font libraries can be used by multiple FontStyle nodes in a scene and need only be loaded once per session." Support levels: add "Level 2, FontStyle, support for font files in family field and support for font libraries via url field ." Security, licensing, and copyright/usage issues are handled via the exposure of the font file itself. If retrievable (locally or online) then proper access is presumably handled separately. Additional information. - X3D 4.1 (draft) Architecture, 15 Text component, 15.4.1 FontStyle - https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/text.html#FontStyle - X3D 4.1 (draft) Architecture, 15 Text component, 15.4.2 Text - https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/text.html#Text - X3D 4.1 (draft) Architecture, 15 Text component, 15.5 Support levels - https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/text.html#SupportlLevels Have fun with X3D Text! :) 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 https://faculty.nps.edu/brutzman ________________________________ From: x3d-public on behalf of Holger Seelig via x3d-public Sent: Monday, February 24, 2025 2:48 AM To: X3D Cc: Holger Seelig Subject: Re: [x3d-public] Open dyslexic and/or (unfortunately) comicsans fonts With X_ITE you can use a URL in the family field of a FontStyle node to specify a path to a custom font file. Provided you have one of these fonts, it should be very easy: Supported File Formats: https://create3000.github.io/x_ite/components/text/fontstyle/#supported-file-formats Best regards, Holger -- Holger Seelig Leipzig, Germany holger.seelig at yahoo.de https://create3000.github.io/x_ite/ Am 24.02.2025 um 11:09 schrieb John Carlson via x3d-public : If someone knows how change the fonts of the standards to OpenDyslexic or ComicSans, that might be a great accessibility experiment. _______________________________________________ x3d-public mailing list x3d-public at web3d.org http://web3d.org/mailman/listinfo/x3d-public_web3d.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Mon Feb 24 12:05:37 2025 From: yottzumm at gmail.com (John Carlson) Date: Mon, 24 Feb 2025 14:05:37 -0600 Subject: [x3d-public] Open dyslexic and/or (unfortunately) comicsans fonts In-Reply-To: References: Message-ID: I?m actually speaking of the HTML documents for X3D4 standard and HAnim standard. Sorry for the confusion. John On Mon, Feb 24, 2025 at 4:09?AM John Carlson wrote: > If someone knows how change the fonts of the standards to OpenDyslexic or > ComicSans, that might be a great accessibility experiment. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brutzman at nps.edu Wed Feb 26 17:39:41 2025 From: brutzman at nps.edu (Brutzman, Donald (Don) (CIV)) Date: Thu, 27 Feb 2025 01:39:41 +0000 Subject: [x3d-public] draft X3D 4.1 prose for font files and libraries In-Reply-To: References: Message-ID: Dick and I worked on suggested prose for X3D 4.1 with details continuing in Mantis 1490 below. Review request: * X3D 4.1 Architecture (draft), 15 Text component, 15.4.1 FontStyle * https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/text.html#FontStyle Improvements: * Include all X3DURLObject fields, SFTime [in,out] autoRefresh 0.0 [0,?) SFTime [in,out] autoRefreshTimeLimit 3600.0 [0,?) SFString [in,out] description "" SFBool [in,out] load TRUE MFString [in,out] url [] [URI] * Decided to NOT overload functionality of family field by adding file names (sorry Holger! adjusting your implementation will likely be simple in comparison) * New prose: The url field is optional and can refer to a relative or online address for a font library that contains one or more font definitions. An empty url list indicates that the default set of fonts provided by the browser are used. If present, only the first active font library retrieved from the url list shall be used. Individual font library files can be used by multiple FontStyle nodes in a scene. Each font file only needs to be loaded once per session. X3D browsers shall support WOFF (MIME type application/x-font-woff) (see W3C WOFF File Format). Support for the OpenType file format (MIME type application/x-font-opentype) (see OpenType Specification) and TrueType file format (MIME type application/x-font-truetype) (see ISO/IEC 14496-22 Open Font Format) is also recommended. Security, licensing, and copyright/usage permissions are handled via the exposure of a font file itself. Support for the autoRefresh, autoRefreshTimeLimit, and load fields is optional. More details on the autoRefresh, autoRefreshTimeLimit, description, load, and url fields are contained in 9.2.1 URLs, URNs and URIs. Looking it over, adding more functionality to FontStyle node seems to be unwise. Dick has an excellent proposal: TODO alternative approach: move all new functionality into a separate FontLibrary node to avoid complicating FontStyle further. This also offers the ability to succinctly load multiple font libraries in a given scene. The expense of defining a new node for X3D is offset by clearer distinction between X3D 4.0 and 4.1, also simplifying model content significantly. Feedback is welcome. Leaving existing FontStyle implementations alone probably avoids many unintended side effects. First law of engineering: "If it ain't broke, don't fix it." Thanks for all review. It feels like we are finally converging on a straightforward approach to valuable future capabilities. Have fun with X3D fonts! ? 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 https://faculty.nps.edu/brutzman ________________________________ From: Brutzman, Donald (Don) (CIV) Sent: Monday, February 24, 2025 9:32 AM To: X3D Cc: Holger Seelig Subject: Re: [x3d-public] Open dyslexic and/or (unfortunately) comicsans fonts; draft X3D 4.1 prose for font files and libraries Wow, really super Holger! ? There was a conversation about this on x3d-public a few years back... We committed to adding it in X3D 4.1 and (if I recall correctly) also noted that adding a url field might enable usage of larger font files. I've attempted to capture this candidate specification change in a Mantis issue. All review, feedback, and improvements are always welcome. * Mantis 1490 FontStyle handling of font files and font libraries * https://mantis.web3d.org/view.php?id=1490 Description. A goal for X3D 4.1 is use of font files in FontStyle (see Mantis 0001464). Addition of individual-font files might be accomplished by listing the font file name in the FontStyle 'family' field. Referencing different fonts in a single combined font library file may require an additional field, for example 'url'. In general the use of a font library may be preferred, but repeatedly run-time retrieval of a font library is not desirable, since the file might be quite large and rarely changing. This might be noted in the specification prose, e.g. - "MFString [in,out] url [] [URI]" - "The family field may list a specific font file. A font listed in the family field may be provided by a corresponding font library." - "The url field may refer to a font library. Font libraries can be used by multiple FontStyle nodes in a scene and need only be loaded once per session." Support levels: add "Level 2, FontStyle, support for font files in family field and support for font libraries via url field ." Security, licensing, and copyright/usage issues are handled via the exposure of the font file itself. If retrievable (locally or online) then proper access is presumably handled separately. Additional information. - X3D 4.1 (draft) Architecture, 15 Text component, 15.4.1 FontStyle - https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/text.html#FontStyle - X3D 4.1 (draft) Architecture, 15 Text component, 15.4.2 Text - https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/text.html#Text - X3D 4.1 (draft) Architecture, 15 Text component, 15.5 Support levels - https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/text.html#SupportlLevels Have fun with X3D Text! :) 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 https://faculty.nps.edu/brutzman ________________________________ From: x3d-public on behalf of Holger Seelig via x3d-public Sent: Monday, February 24, 2025 2:48 AM To: X3D Cc: Holger Seelig Subject: Re: [x3d-public] Open dyslexic and/or (unfortunately) comicsans fonts With X_ITE you can use a URL in the family field of a FontStyle node to specify a path to a custom font file. Provided you have one of these fonts, it should be very easy: Supported File Formats: https://create3000.github.io/x_ite/components/text/fontstyle/#supported-file-formats Best regards, Holger -- Holger Seelig Leipzig, Germany holger.seelig at yahoo.de https://create3000.github.io/x_ite/ Am 24.02.2025 um 11:09 schrieb John Carlson via x3d-public : If someone knows how change the fonts of the standards to OpenDyslexic or ComicSans, that might be a great accessibility experiment. _______________________________________________ x3d-public mailing list x3d-public at web3d.org http://web3d.org/mailman/listinfo/x3d-public_web3d.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From yottzumm at gmail.com Wed Feb 26 18:04:04 2025 From: yottzumm at gmail.com (John Carlson) Date: Wed, 26 Feb 2025 20:04:04 -0600 Subject: [x3d-public] draft X3D 4.1 prose for font files and libraries In-Reply-To: References: Message-ID: Looks great, The yellow will be applied to the cyan. Is the new node an alternative to the old FontStyle, or can both be used together? On Wed, Feb 26, 2025 at 7:40?PM Brutzman, Donald (Don) (CIV) via x3d-public wrote: > Dick and I worked on suggested prose for X3D 4.1 with details continuing > in Mantis 1490 below. > > Review request: > > - X3D 4.1 Architecture (draft), 15 Text component, 15.4.1 FontStyle > - > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/text.html#FontStyle > > Improvements: > > - Include all X3DURLObject fields, > > SFTime [in,out] autoRefresh 0.0 [0,?) > SFTime [in,out] autoRefreshTimeLimit 3600.0 [0,?) > SFString [in,out] description "" > SFBool [in,out] load TRUE > MFString [in,out] url [] [URI] > > - Decided to NOT overload functionality of *family * field by adding > file names (sorry Holger! adjusting your implementation will likely be > simple in comparison) > > - New prose: > > The *url* field is optional and can refer to a relative or online address > for a font library that contains one or more font definitions. An empty > *url* list indicates that the default set of fonts provided by the > browser are used. If present, only the first active font library retrieved > from the *url* list shall be used. Individual font library files can be > used by multiple FontStyle nodes in a scene. Each font file only needs to > be loaded once per session. > X3D browsers shall support WOFF (MIME type application/x-font-woff) (see W3C > WOFF File Format > ). > Support for the OpenType file format (MIME type > application/x-font-opentype) (see OpenType Specification > ) > and TrueType file format (MIME type application/x-font-truetype) (see ISO/IEC > 14496-22 Open Font Format > ) > is also recommended. > Security, licensing, and copyright/usage permissions are handled via the > exposure of a font file itself. > Support for the *autoRefresh*, *autoRefreshTimeLimit*, and *load* fields is > optional. > More details on the *autoRefresh*, *autoRefreshTimeLimit*, *description*, > *load*, and *url* fields are contained in 9.2.1 URLs, URNs and URIs > > . > Looking it over, adding more functionality to FontStyle node seems to be > unwise. Dick has an excellent proposal: > TODO alternative approach: move all new functionality into a separate > *FontLibrary* node to avoid complicating FontStyle further. This also > offers the ability to succinctly load multiple font libraries in a given > scene. The expense of defining a new node for X3D is offset by clearer > distinction between X3D 4.0 and 4.1, also simplifying model content > significantly. > Feedback is welcome. > Leaving existing FontStyle implementations alone probably avoids many > unintended side effects. First law of engineering: "If it ain't broke, > don't fix it." > > Thanks for all review. It feels like we are finally converging on a > straightforward approach to valuable future capabilities. > > Have fun with X3D fonts! ? > > > 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 > https://faculty.nps.edu/brutzman > > > > ------------------------------ > *From:* Brutzman, Donald (Don) (CIV) > *Sent:* Monday, February 24, 2025 9:32 AM > *To:* X3D > *Cc:* Holger Seelig > *Subject:* Re: [x3d-public] Open dyslexic and/or (unfortunately) > comicsans fonts; draft X3D 4.1 prose for font files and libraries > > Wow, really super Holger! ? > > There was a conversation about this on x3d-public a few years back... We > committed to adding it in X3D 4.1 and (if I recall correctly) also noted > that adding a url field might enable usage of larger font files. > > I've attempted to capture this candidate specification change in a Mantis > issue. All review, feedback, and improvements are always welcome. > > - Mantis 1490 FontStyle handling of font files and font libraries > - https://mantis.web3d.org/view.php?id=1490 > > Description. > A goal for X3D 4.1 is use of font files in FontStyle (see Mantis 0001464 > ). > > Addition of individual-font files might be accomplished by listing the > font file name in the FontStyle 'family' field. > > Referencing different fonts in a single combined font library file may > require an additional field, for example 'url'. In general the use of a > font library may be preferred, but repeatedly run-time retrieval of a font > library is not desirable, since the file might be quite large and rarely > changing. This might be noted in the specification prose, e.g. > > - "MFString [in,out] url [] [URI]" > - "The family field may list a specific font file. A font listed in the > family field may be provided by a corresponding font library." > - "The url field may refer to a font library. Font libraries can be used > by multiple FontStyle nodes in a scene and need only be loaded once per > session." > > Support levels: add "Level 2, FontStyle, support for font files in family > field and support for font libraries via url field ." > > Security, licensing, and copyright/usage issues are handled via the > exposure of the font file itself. If retrievable (locally or online) then > proper access is presumably handled separately. > > Additional information. > - X3D 4.1 (draft) Architecture, 15 Text component, 15.4.1 FontStyle > - > https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/text.html#FontStyle > > - X3D 4.1 (draft) Architecture, 15 Text component, 15.4.2 Text > - > https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/text.html#Text > > - X3D 4.1 (draft) Architecture, 15 Text component, 15.5 Support levels > - > https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/text.html#SupportlLevels > > Have fun with X3D Text! :) > > > 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 > https://faculty.nps.edu/brutzman > > > > ------------------------------ > *From:* x3d-public on behalf of Holger > Seelig via x3d-public > *Sent:* Monday, February 24, 2025 2:48 AM > *To:* X3D > *Cc:* Holger Seelig > *Subject:* Re: [x3d-public] Open dyslexic and/or (unfortunately) > comicsans fonts > > With X_ITE you can use a URL in the family field of a FontStyle node to > specify a path to a custom font file. Provided you have one of these fonts, > it should be very easy: > > > https://www.web3d.org/specifications/x3d-4.0.dtd"> > > > > > > > > > > > string='"3D Text"'> > family='"path/to/your/font.otf", "SERIF"'/> > > > > > > > Supported File Formats: > > https://create3000.github.io/x_ite/components/text/fontstyle/#supported-file-formats > > Best regards, > Holger > > -- > Holger Seelig > Leipzig, Germany > > holger.seelig at yahoo.de > https://create3000.github.io/x_ite/ > > Am 24.02.2025 um 11:09 schrieb John Carlson via x3d-public < > x3d-public at web3d.org>: > > If someone knows how change the fonts of the standards to OpenDyslexic or > ComicSans, that might be a great accessibility experiment. > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > > > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreasplesch at gmail.com Wed Feb 26 19:37:52 2025 From: andreasplesch at gmail.com (Andreas Plesch) Date: Wed, 26 Feb 2025 22:37:52 -0500 Subject: [x3d-public] draft X3D 4.1 prose for font files and libraries In-Reply-To: References: Message-ID: x3dom supports all fonts which can be used on a web page. Currently that requires use of css on the html page to actually load a font from a url source. But browser font api improvements now should make it possible to simplify use of font files in x3dom directly from FontStyle.url or a similar node. Some comments: https://www.w3.org/TR/WOFF2/ is a compressed version of WOFF which seems popular on the web due to smaller file sizes. For example, it is used by the Google free Font service. I do not know if there are js/pascal/c etc. loading libraries for woff2 but it should at least be recommended. >From what I can tell WOFF and WOFF2 do not need to include font family name information inside the file. So I think that means if such a file is provided it will take precedence over the family field. Holger's overloading suggestion implicitly did this. A web browser will synthesize bold and italic versions from a normal font version. Should this become a requirement for x3d as well ? Probably not. If authors want to use a bold version for certain, they need to provide corresponding font files. It seems that a FontLibrary node would augment FontStyle rather than replace it. Would it have functionality other than providing a source for the font data ? It might be useful to associate a font family name with a font data file in such a node. The family name could then be referred to in the FontStyle.family field. DEF/USE might be a better mechanism, however. In html, css can provide multiple sources for the same font-face, with the @font-face rule (and sophisticated hints helping to avoid loading when not needed among others.). For example, the likely local name for the font family on the client system can be provided in case it is already locally installed and therefore does not need to be downloaded. Font management, layout and rendering seems very complex. It is a bit of a minefield for X3D to get into if high reproducibility is a goal. Andreas > Date: Thu, 27 Feb 2025 01:39:41 +0000 > From: "Brutzman, Donald (Don) (CIV)" > To: X3D > Subject: Re: [x3d-public] draft X3D 4.1 prose for font files and > libraries > Message-ID: > < > BY3PR13MB48847F72AF30D77F4D71ED95C4CD2 at BY3PR13MB4884.namprd13.prod.outlook.com > > > > Content-Type: text/plain; charset="utf-8" > > Dick and I worked on suggested prose for X3D 4.1 with details continuing > in Mantis 1490 below. > > Review request: > > * > X3D 4.1 Architecture (draft), 15 Text component, 15.4.1 FontStyle > * > > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/text.html#FontStyle > > Improvements: > > * > Include all X3DURLObject fields, > > SFTime [in,out] autoRefresh 0.0 [0,?) > SFTime [in,out] autoRefreshTimeLimit 3600.0 [0,?) > SFString [in,out] description "" > SFBool [in,out] load TRUE > MFString [in,out] url [] [URI] > > * > Decided to NOT overload functionality of family field by adding file names > (sorry Holger! adjusting your implementation will likely be simple in > comparison) > > * > New prose: > > The url field is optional and can refer to a relative or online address > for a font library that contains one or more font definitions. An empty url > list indicates that the default set of fonts provided by the browser are > used. If present, only the first active font library retrieved from the url > list shall be used. Individual font library files can be used by multiple > FontStyle nodes in a scene. Each font file only needs to be loaded once per > session. > X3D browsers shall support WOFF (MIME type application/x-font-woff) (see > W3C WOFF File Format< > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/references.html#W3C_WOFF>). > Support for the OpenType file format (MIME type > application/x-font-opentype) (see OpenType Specification< > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/bibliography.html#OPENTYPE>) > and TrueType file format (MIME type application/x-font-truetype) (see > ISO/IEC 14496-22 Open Font Format< > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/references.html#I14496_22>) > is also recommended. > Security, licensing, and copyright/usage permissions are handled via the > exposure of a font file itself. > Support for the autoRefresh, autoRefreshTimeLimit, and load fields is > optional. > More details on the autoRefresh, autoRefreshTimeLimit, description, load, > and url fields are contained in 9.2.1 URLs, URNs and URIs< > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/networking.html#URLs > >. > Looking it over, adding more functionality to FontStyle node seems to be > unwise. Dick has an excellent proposal: > TODO alternative approach: move all new functionality into a separate > FontLibrary node to avoid complicating FontStyle further. This also offers > the ability to succinctly load multiple font libraries in a given scene. > The expense of defining a new node for X3D is offset by clearer distinction > between X3D 4.0 and 4.1, also simplifying model content significantly. > Feedback is welcome. > Leaving existing FontStyle implementations alone probably avoids many > unintended side effects. First law of engineering: "If it ain't broke, > don't fix it." > > Thanks for all review. It feels like we are finally converging on a > straightforward approach to valuable future capabilities. > > Have fun with X3D fonts! ? > > > 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 > https://faculty.nps.edu/brutzman > > > > ________________________________ > From: Brutzman, Donald (Don) (CIV) > Sent: Monday, February 24, 2025 9:32 AM > To: X3D > Cc: Holger Seelig > Subject: Re: [x3d-public] Open dyslexic and/or (unfortunately) comicsans > fonts; draft X3D 4.1 prose for font files and libraries > > Wow, really super Holger! ? > > There was a conversation about this on x3d-public a few years back... We > committed to adding it in X3D 4.1 and (if I recall correctly) also noted > that adding a url field might enable usage of larger font files. > > I've attempted to capture this candidate specification change in a Mantis > issue. All review, feedback, and improvements are always welcome. > > * > Mantis 1490 FontStyle handling of font files and font libraries > * > https://mantis.web3d.org/view.php?id=1490 > > Description. > A goal for X3D 4.1 is use of font files in FontStyle (see Mantis 0001464< > https://mantis.web3d.org/view.php?id=1464>). > > Addition of individual-font files might be accomplished by listing the > font file name in the FontStyle 'family' field. > > Referencing different fonts in a single combined font library file may > require an additional field, for example 'url'. In general the use of a > font library may be preferred, but repeatedly run-time retrieval of a font > library is not desirable, since the file might be quite large and rarely > changing. This might be noted in the specification prose, e.g. > > - "MFString [in,out] url [] [URI]" > - "The family field may list a specific font file. A font listed in the > family field may be provided by a corresponding font library." > - "The url field may refer to a font library. Font libraries can be used > by multiple FontStyle nodes in a scene and need only be loaded once per > session." > > Support levels: add "Level 2, FontStyle, support for font files in family > field and support for font libraries via url field ." > > Security, licensing, and copyright/usage issues are handled via the > exposure of the font file itself. If retrievable (locally or online) then > proper access is presumably handled separately. > > Additional information. > - X3D 4.1 (draft) Architecture, 15 Text component, 15.4.1 FontStyle > - > https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/text.html#FontStyle > > - X3D 4.1 (draft) Architecture, 15 Text component, 15.4.2 Text > - > https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/text.html#Text > > - X3D 4.1 (draft) Architecture, 15 Text component, 15.5 Support levels > - > https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/text.html#SupportlLevels > > Have fun with X3D Text! :) > > > 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 > https://faculty.nps.edu/brutzman > > > > ________________________________ > From: x3d-public on behalf of Holger > Seelig via x3d-public > Sent: Monday, February 24, 2025 2:48 AM > To: X3D > Cc: Holger Seelig > Subject: Re: [x3d-public] Open dyslexic and/or (unfortunately) comicsans > fonts > > With X_ITE you can use a URL in the family field of a FontStyle node to > specify a path to a custom font file. Provided you have one of these fonts, > it should be very easy: > > > https://www.web3d.org/specifications/x3d-4.0.dtd"> > > > > > > > > > > > string='"3D Text"'> > family='"path/to/your/font.otf", "SERIF"'/> > > > > > > > Supported File Formats: > > https://create3000.github.io/x_ite/components/text/fontstyle/#supported-file-formats > > Best regards, > Holger > > -- > Holger Seelig > Leipzig, Germany > > holger.seelig at yahoo.de > https://create3000.github.io/x_ite/ > > Am 24.02.2025 um 11:09 schrieb John Carlson via x3d-public < > x3d-public at web3d.org>: > > If someone knows how change the fonts of the standards to OpenDyslexic or > ComicSans, that might be a great accessibility experiment. > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20250227/60f4e72d/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > > > ------------------------------ > > End of x3d-public Digest, Vol 191, Issue 123 > ******************************************** > -- Andreas Plesch Waltham, MA 02453 -------------- next part -------------- An HTML attachment was scrubbed... URL: From michalis.kambi at gmail.com Wed Feb 26 19:41:31 2025 From: michalis.kambi at gmail.com (Michalis Kamburelis) Date: Thu, 27 Feb 2025 04:41:31 +0100 Subject: [x3d-public] draft X3D 4.1 prose for font files and libraries In-Reply-To: References: Message-ID: Nice, I see the core addition here is adding "url" to the "FontStyle", which can point to a font file (like WOFF, TTF, OTF). This makes perfect sense and should be easy to implement and useful for authors. The prose makes it clear that only *one* item from the "FontStyle.url" list is used, which is standard in X3D usage of "MFString url", good. Some feedback: 1. The text uses new terms: "font definition", "font library". I would advise to clearly define (and give examples) what is meant by each term (and maybe you don't really need all of them?). As always, testcase files would be great :) Admittedly, I don't fully understand myself what do you mean by "font definition", "font library". The terms I know, when working with fonts, are : A. "font file" (this is a single WOFF, TTF, OTF file). B. And "font family" (this is usually using 4 files, regular / italic / bold+italic / bold). In CGE, this is TCastleFontFamily component, corresponds to https://castle-engine.io/apidoc/html/CastleFonts.TCastleFontFamily.html . In CSS, this is called font-family. See e.g. https://stackoverflow.com/questions/12812441/how-do-i-use-woff-fonts-for-my-website how to use 4 WOFF files to define a CSS font-family. In X3D itself, the "FontStyle.family" also allows to choose from (system-level or browser-level) font families. So it's all good and consistent so far. Admittedly, I'm unsure how/if do my above terms map to "font library" and "font definition" terms that the spec on https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/text.html#FontStyle uses. The spec mentions "a font library that contains one or more font definitions". Can you show me (point to concrete testcases) what do you mean? What is a simple file that is "a font library with one font definition"? What is a simple file that is "a font library with multiple font definitions"? 2. It may be worth saying explicitly in the prose that: - When some font file indicated by "url" is successfully loaded, then the "FontStyle.family" no longer maters. The font is defined by the given URL. - When some font file indicated by "url" is successfully loaded (and it only contains a single font definition?) then the "FontStyle.style" (bold, italic..) also doesn't matter. That is, consider this: FontStyle { url "DejaVuSerif-Italic.ttf" } DejaVu is an open-source font, distributed also by Debian, and used by CGE, you can experiment with files on https://github.com/castle-engine/castle-engine/tree/master/src/fonts/data . ... then the "style" doesn't matter. That is, in this example: FontStyle { url "DejaVuSerif-Italic.ttf" style "BOLD" } ... the style "BOLD" value is ignored. Because you use "DejaVuSerif-Italic.ttf", so this is italic (and not bold) version of DejaVu. If someone wants bold, they should have used "DejaVuSerif-Bold.ttf". 3. In CGE, it is possible to use a collection of .ttf / .otf to define a font. Speculating, something like this (matching https://castle-engine.io/apidoc/html/CastleFonts.TCastleFontFamily.html ) could be available to express this in X3D: """ Shape { geometry Text { fontStyle FontStyle { familyComposed DEF DejaVu FontFamily { regularUrl "DejaVuSerif.ttf" italicUrl "DejaVuSerif-Italic.ttf" boldUrl "DejaVuSerif-Bold.ttf" boldItalicUrl "DejaVuSerif-BoldItalic.ttf" } } string "this has regular style" } } Shape { geometry Text { fontStyle FontStyle { composedFontFamily USE DejaVu style "ITALIC" } string "this has italic style" } } Shape { geometry Text { fontStyle FontStyle { composedFontFamily USE DejaVu style "BOLDITALIC" } string "this has italic+bold style" } } """ 4. I wonder whether the FontLibrary that you mentioned will fulfill some of the use-cases I mentioned above and answer some of my questions :) No rush, I understand this is in the design phase, I'll want and see what you propose, maybe when I see FontLibrary -> the above points will no longer matter because everything will be obvious. Regards, Michalis czw., 27 lut 2025 o 02:40 Brutzman, Donald (Don) (CIV) via x3d-public < x3d-public at web3d.org> napisa?(a): > Dick and I worked on suggested prose for X3D 4.1 with details continuing > in Mantis 1490 below. > > Review request: > > - X3D 4.1 Architecture (draft), 15 Text component, 15.4.1 FontStyle > - > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/text.html#FontStyle > > Improvements: > > - Include all X3DURLObject fields, > > SFTime [in,out] autoRefresh 0.0 [0,?) > SFTime [in,out] autoRefreshTimeLimit 3600.0 [0,?) > SFString [in,out] description "" > SFBool [in,out] load TRUE > MFString [in,out] url [] [URI] > > - Decided to NOT overload functionality of *family * field by adding > file names (sorry Holger! adjusting your implementation will likely be > simple in comparison) > > - New prose: > > The *url* field is optional and can refer to a relative or online address > for a font library that contains one or more font definitions. An empty > *url* list indicates that the default set of fonts provided by the > browser are used. If present, only the first active font library retrieved > from the *url* list shall be used. Individual font library files can be > used by multiple FontStyle nodes in a scene. Each font file only needs to > be loaded once per session. > X3D browsers shall support WOFF (MIME type application/x-font-woff) (see W3C > WOFF File Format > ). > Support for the OpenType file format (MIME type > application/x-font-opentype) (see OpenType Specification > ) > and TrueType file format (MIME type application/x-font-truetype) (see ISO/IEC > 14496-22 Open Font Format > ) > is also recommended. > Security, licensing, and copyright/usage permissions are handled via the > exposure of a font file itself. > Support for the *autoRefresh*, *autoRefreshTimeLimit*, and *load* fields is > optional. > More details on the *autoRefresh*, *autoRefreshTimeLimit*, *description*, > *load*, and *url* fields are contained in 9.2.1 URLs, URNs and URIs > > . > Looking it over, adding more functionality to FontStyle node seems to be > unwise. Dick has an excellent proposal: > TODO alternative approach: move all new functionality into a separate > *FontLibrary* node to avoid complicating FontStyle further. This also > offers the ability to succinctly load multiple font libraries in a given > scene. The expense of defining a new node for X3D is offset by clearer > distinction between X3D 4.0 and 4.1, also simplifying model content > significantly. > Feedback is welcome. > Leaving existing FontStyle implementations alone probably avoids many > unintended side effects. First law of engineering: "If it ain't broke, > don't fix it." > > Thanks for all review. It feels like we are finally converging on a > straightforward approach to valuable future capabilities. > > Have fun with X3D fonts! ? > > > 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 > https://faculty.nps.edu/brutzman > > > > ------------------------------ > *From:* Brutzman, Donald (Don) (CIV) > *Sent:* Monday, February 24, 2025 9:32 AM > *To:* X3D > *Cc:* Holger Seelig > *Subject:* Re: [x3d-public] Open dyslexic and/or (unfortunately) > comicsans fonts; draft X3D 4.1 prose for font files and libraries > > Wow, really super Holger! ? > > There was a conversation about this on x3d-public a few years back... We > committed to adding it in X3D 4.1 and (if I recall correctly) also noted > that adding a url field might enable usage of larger font files. > > I've attempted to capture this candidate specification change in a Mantis > issue. All review, feedback, and improvements are always welcome. > > - Mantis 1490 FontStyle handling of font files and font libraries > - https://mantis.web3d.org/view.php?id=1490 > > Description. > A goal for X3D 4.1 is use of font files in FontStyle (see Mantis 0001464 > ). > > Addition of individual-font files might be accomplished by listing the > font file name in the FontStyle 'family' field. > > Referencing different fonts in a single combined font library file may > require an additional field, for example 'url'. In general the use of a > font library may be preferred, but repeatedly run-time retrieval of a font > library is not desirable, since the file might be quite large and rarely > changing. This might be noted in the specification prose, e.g. > > - "MFString [in,out] url [] [URI]" > - "The family field may list a specific font file. A font listed in the > family field may be provided by a corresponding font library." > - "The url field may refer to a font library. Font libraries can be used > by multiple FontStyle nodes in a scene and need only be loaded once per > session." > > Support levels: add "Level 2, FontStyle, support for font files in family > field and support for font libraries via url field ." > > Security, licensing, and copyright/usage issues are handled via the > exposure of the font file itself. If retrievable (locally or online) then > proper access is presumably handled separately. > > Additional information. > - X3D 4.1 (draft) Architecture, 15 Text component, 15.4.1 FontStyle > - > https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/text.html#FontStyle > > - X3D 4.1 (draft) Architecture, 15 Text component, 15.4.2 Text > - > https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/text.html#Text > > - X3D 4.1 (draft) Architecture, 15 Text component, 15.5 Support levels > - > https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/text.html#SupportlLevels > > Have fun with X3D Text! :) > > > 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 > https://faculty.nps.edu/brutzman > > > > ------------------------------ > *From:* x3d-public on behalf of Holger > Seelig via x3d-public > *Sent:* Monday, February 24, 2025 2:48 AM > *To:* X3D > *Cc:* Holger Seelig > *Subject:* Re: [x3d-public] Open dyslexic and/or (unfortunately) > comicsans fonts > > With X_ITE you can use a URL in the family field of a FontStyle node to > specify a path to a custom font file. Provided you have one of these fonts, > it should be very easy: > > > https://www.web3d.org/specifications/x3d-4.0.dtd"> > > > > > > > > > > > string='"3D Text"'> > family='"path/to/your/font.otf", "SERIF"'/> > > > > > > > Supported File Formats: > > https://create3000.github.io/x_ite/components/text/fontstyle/#supported-file-formats > > Best regards, > Holger > > -- > Holger Seelig > Leipzig, Germany > > holger.seelig at yahoo.de > https://create3000.github.io/x_ite/ > > Am 24.02.2025 um 11:09 schrieb John Carlson via x3d-public < > x3d-public at web3d.org>: > > If someone knows how change the fonts of the standards to OpenDyslexic or > ComicSans, that might be a great accessibility experiment. > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > > > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michalis.kambi at gmail.com Wed Feb 26 19:51:03 2025 From: michalis.kambi at gmail.com (Michalis Kamburelis) Date: Thu, 27 Feb 2025 04:51:03 +0100 Subject: [x3d-public] draft X3D 4.1 prose for font files and libraries In-Reply-To: References: Message-ID: Andreas Plesch wrote: > https://www.w3.org/TR/WOFF2/ is a compressed version of WOFF which seems popular on the web due to smaller file sizes. For example, it is used by the Google free Font service. I do not know if there are js/pascal/c etc. loading libraries for woff2 but it should at least be recommended. CGE (Pascal) just uses FreeType for font reading, so we should support everything that FreeType handles :) And it does support WOFF 2 according to https://www.phoronix.com/news/FreeType-2.10.2-Released . > > From what I can tell WOFF and WOFF2 do not need to include font family name information inside the file. So I think that means if such a file is provided it will take precedence over the family field. Holger's overloading suggestion implicitly did this. > > A web browser will synthesize bold and italic versions from a normal font version. Should this become a requirement for x3d as well ? Probably not. If authors want to use a bold version for certain, they need to provide corresponding font files. I see Andres comments align nicely with mine, posted 5 mins ago :) I also don't think X3D browsers should have the requirement to synthesize bold and italic versions from a normal font version. If FreeType doesn't do this (and I don't think it can) then it's not something I would ever implement, frankly. I'm not even sure how good are WWW browsers at doing this "synthesizing". The recommendation for using fonts, that I always seen followed, is that you need 4 font files (regular, bold, italic, bold+italic) if you want to provide all the options. The font authors seems to generally agree -- most fonts come with 4 such files. And as Andreas said, the spec should say that "url" overrides "family". Regards, Michalis From holger.seelig at yahoo.de Thu Feb 27 02:13:34 2025 From: holger.seelig at yahoo.de (Holger Seelig) Date: Thu, 27 Feb 2025 11:13:34 +0100 Subject: [x3d-public] draft X3D 4.1 prose for font files and libraries In-Reply-To: References: Message-ID: <3C001CF9-1B6D-4BF3-8958-6A7CDD020F9E@yahoo.de> Synthezising font styles is usually not an option for people interested in typography. A font usually comes in different styles, which are finely worked out and usually contain special features that cannot be achieved by synthesising, i.e. they usually look bad, but often are perfectly suitable for manually creating a new style from them. FontStyle node with url is a good idea and also easy to implement. I think it is enough to load one font: FontStyle { url "DejaVuSerif-Italic.ttf" style "BOLD" } that's simple and is actually enough, otherwise it gets more complicated, and as Michalis already said the style doesn't matter in this case. Best regards, Holger -- Holger Seelig Leipzig, Germany holger.seelig at yahoo.de https://create3000.github.io/x_ite/ > Am 27.02.2025 um 04:41 schrieb Michalis Kamburelis via x3d-public : > > Nice, I see the core addition here is adding "url" to the "FontStyle", which can point to a font file (like WOFF, TTF, OTF). This makes perfect sense and should be easy to implement and useful for authors. The prose makes it clear that only *one* item from the "FontStyle.url" list is used, which is standard in X3D usage of "MFString url", good. > > Some feedback: > > 1. The text uses new terms: "font definition", "font library". I would advise to clearly define (and give examples) what is meant by each term (and maybe you don't really need all of them?). As always, testcase files would be great :) > > Admittedly, I don't fully understand myself what do you mean by "font definition", "font library". The terms I know, when working with fonts, are : > > A. "font file" (this is a single WOFF, TTF, OTF file). > > B. And "font family" (this is usually using 4 files, regular / italic / bold+italic / bold). > > In CGE, this is TCastleFontFamily component, corresponds to https://castle-engine.io/apidoc/html/CastleFonts.TCastleFontFamily.html . > > In CSS, this is called font-family. See e.g. https://stackoverflow.com/questions/12812441/how-do-i-use-woff-fonts-for-my-website how to use 4 WOFF files to define a CSS font-family. > > In X3D itself, the "FontStyle.family" also allows to choose from (system-level or browser-level) font families. So it's all good and consistent so far. > > Admittedly, I'm unsure how/if do my above terms map to "font library" and "font definition" terms that the spec on https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/text.html#FontStyle uses. The spec mentions "a font library that contains one or more font definitions". Can you show me (point to concrete testcases) what do you mean? What is a simple file that is "a font library with one font definition"? What is a simple file that is "a font library with multiple font definitions"? > > 2. It may be worth saying explicitly in the prose that: > > - When some font file indicated by "url" is successfully loaded, then the "FontStyle.family" no longer maters. The font is defined by the given URL. > > - When some font file indicated by "url" is successfully loaded (and it only contains a single font definition?) then the "FontStyle.style" (bold, italic..) also doesn't matter. > > That is, consider this: > > FontStyle { url "DejaVuSerif-Italic.ttf" } > > DejaVu is an open-source font, distributed also by Debian, and used by CGE, you can experiment with files on https://github.com/castle-engine/castle-engine/tree/master/src/fonts/data . > > ... then the "style" doesn't matter. That is, in this example: > > FontStyle { > url "DejaVuSerif-Italic.ttf" > style "BOLD" > } > > ... the style "BOLD" value is ignored. Because you use "DejaVuSerif-Italic.ttf", so this is italic (and not bold) version of DejaVu. If someone wants bold, they should have used "DejaVuSerif-Bold.ttf". > > 3. In CGE, it is possible to use a collection of .ttf / .otf to define a font. Speculating, something like this (matching https://castle-engine.io/apidoc/html/CastleFonts.TCastleFontFamily.html ) could be available to express this in X3D: > > """ > Shape { > geometry Text { > fontStyle FontStyle { > familyComposed DEF DejaVu FontFamily { > regularUrl "DejaVuSerif.ttf" > italicUrl "DejaVuSerif-Italic.ttf" > boldUrl "DejaVuSerif-Bold.ttf" > boldItalicUrl "DejaVuSerif-BoldItalic.ttf" > } > } > string "this has regular style" > } > } > > Shape { > geometry Text { > fontStyle FontStyle { > composedFontFamily USE DejaVu > style "ITALIC" > } > string "this has italic style" > } > } > > Shape { > geometry Text { > fontStyle FontStyle { > composedFontFamily USE DejaVu > style "BOLDITALIC" > } > string "this has italic+bold style" > } > } > """ > > 4. I wonder whether the FontLibrary that you mentioned will fulfill some of the use-cases I mentioned above and answer some of my questions :) No rush, I understand this is in the design phase, I'll want and see what you propose, maybe when I see FontLibrary -> the above points will no longer matter because everything will be obvious. > > Regards, > Michalis > > czw., 27 lut 2025 o 02:40 Brutzman, Donald (Don) (CIV) via x3d-public > napisa?(a): >> Dick and I worked on suggested prose for X3D 4.1 with details continuing in Mantis 1490 below. >> >> Review request: >> X3D 4.1 Architecture (draft), 15 Text component, 15.4.1 FontStyle >> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/text.html#FontStyle >> Improvements: >> Include all X3DURLObject fields, >> SFTime [in,out] autoRefresh 0.0 [0,?) >> SFTime [in,out] autoRefreshTimeLimit 3600.0 [0,?) >> SFString [in,out] description "" >> SFBool [in,out] load TRUE >> MFString [in,out] url [] [URI] >> Decided to NOT overload functionality of family field by adding file names (sorry Holger! adjusting your implementation will likely be simple in comparison) >> >> New prose: >> The url field is optional and can refer to a relative or online address for a font library that contains one or more font definitions. An empty url list indicates that the default set of fonts provided by the browser are used. If present, only the first active font library retrieved from the url list shall be used. Individual font library files can be used by multiple FontStyle nodes in a scene. Each font file only needs to be loaded once per session. >> X3D browsers shall support WOFF (MIME type application/x-font-woff) (see W3C WOFF File Format ). Support for the OpenType file format (MIME type application/x-font-opentype) (see OpenType Specification ) and TrueType file format (MIME type application/x-font-truetype) (see ISO/IEC 14496-22 Open Font Format ) is also recommended. >> Security, licensing, and copyright/usage permissions are handled via the exposure of a font file itself. >> Support for the autoRefresh, autoRefreshTimeLimit, and load fields is optional. >> More details on the autoRefresh, autoRefreshTimeLimit, description, load, and url fields are contained in 9.2.1 URLs, URNs and URIs . >> Looking it over, adding more functionality to FontStyle node seems to be unwise. Dick has an excellent proposal: >> TODO alternative approach: move all new functionality into a separate FontLibrary node to avoid complicating FontStyle further. This also offers the ability to succinctly load multiple font libraries in a given scene. The expense of defining a new node for X3D is offset by clearer distinction between X3D 4.0 and 4.1, also simplifying model content significantly. >> Feedback is welcome. >> Leaving existing FontStyle implementations alone probably avoids many unintended side effects. First law of engineering: "If it ain't broke, don't fix it." >> >> Thanks for all review. It feels like we are finally converging on a straightforward approach to valuable future capabilities. >> >> Have fun with X3D fonts! ? >> >> 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 https://faculty.nps.edu/brutzman >> >> >> From: Brutzman, Donald (Don) (CIV) > >> Sent: Monday, February 24, 2025 9:32 AM >> To: X3D > >> Cc: Holger Seelig > >> Subject: Re: [x3d-public] Open dyslexic and/or (unfortunately) comicsans fonts; draft X3D 4.1 prose for font files and libraries >> >> Wow, really super Holger! ? >> >> There was a conversation about this on x3d-public a few years back... We committed to adding it in X3D 4.1 and (if I recall correctly) also noted that adding a url field might enable usage of larger font files. >> >> I've attempted to capture this candidate specification change in a Mantis issue. All review, feedback, and improvements are always welcome. >> Mantis 1490 FontStyle handling of font files and font libraries >> https://mantis.web3d.org/view.php?id=1490 >> Description. >> A goal for X3D 4.1 is use of font files in FontStyle (see Mantis 0001464 ). >> >> Addition of individual-font files might be accomplished by listing the font file name in the FontStyle 'family' field. >> >> Referencing different fonts in a single combined font library file may require an additional field, for example 'url'. In general the use of a font library may be preferred, but repeatedly run-time retrieval of a font library is not desirable, since the file might be quite large and rarely changing. This might be noted in the specification prose, e.g. >> >> - "MFString [in,out] url [] [URI]" >> - "The family field may list a specific font file. A font listed in the family field may be provided by a corresponding font library." >> - "The url field may refer to a font library. Font libraries can be used by multiple FontStyle nodes in a scene and need only be loaded once per session." >> >> Support levels: add "Level 2, FontStyle, support for font files in family field and support for font libraries via url field ." >> >> Security, licensing, and copyright/usage issues are handled via the exposure of the font file itself. If retrievable (locally or online) then proper access is presumably handled separately. >> >> Additional information. >> - X3D 4.1 (draft) Architecture, 15 Text component, 15.4.1 FontStyle >> - https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/text.html#FontStyle >> >> - X3D 4.1 (draft) Architecture, 15 Text component, 15.4.2 Text >> - https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/text.html#Text >> >> - X3D 4.1 (draft) Architecture, 15 Text component, 15.5 Support levels >> - https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/text.html#SupportlLevels >> >> Have fun with X3D Text! :) >> >> 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 https://faculty.nps.edu/brutzman >> >> >> From: x3d-public > on behalf of Holger Seelig via x3d-public > >> Sent: Monday, February 24, 2025 2:48 AM >> To: X3D > >> Cc: Holger Seelig > >> Subject: Re: [x3d-public] Open dyslexic and/or (unfortunately) comicsans fonts >> >> With X_ITE you can use a URL in the family field of a FontStyle node to specify a path to a custom font file. Provided you have one of these fonts, it should be very easy: >> >> >> >> >> >> >> >> >> >> >> >> >> >> > string='"3D Text"'> >> > family='"path/to/your/font.otf", "SERIF"'/> >> >> >> >> >> >> >> Supported File Formats: >> https://create3000.github.io/x_ite/components/text/fontstyle/#supported-file-formats >> >> Best regards, >> Holger >> >> -- >> Holger Seelig >> Leipzig, Germany >> >> holger.seelig at yahoo.de >> https://create3000.github.io/x_ite/ >> >> Am 24.02.2025 um 11:09 schrieb John Carlson via x3d-public >: >> >> If someone knows how change the fonts of the standards to OpenDyslexic or ComicSans, that might be a great accessibility experiment. _______________________________________________ >> x3d-public mailing list >> x3d-public at web3d.org >> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >> >> _______________________________________________ >> x3d-public mailing list >> x3d-public at web3d.org >> http://web3d.org/mailman/listinfo/x3d-public_web3d.org > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger.seelig at yahoo.de Thu Feb 27 02:50:56 2025 From: holger.seelig at yahoo.de (Holger Seelig) Date: Thu, 27 Feb 2025 11:50:56 +0100 Subject: [x3d-public] draft X3D 4.1 prose for font files and libraries In-Reply-To: <3C001CF9-1B6D-4BF3-8958-6A7CDD020F9E@yahoo.de> References: <3C001CF9-1B6D-4BF3-8958-6A7CDD020F9E@yahoo.de> Message-ID: <53C38717-DF47-468C-A7C8-9B53002E294B@yahoo.de> Don?t forget ScreenFontStyle, it is also derived from X3DFontStyleNode. https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/layout.html#ScreenFontStyle Best regards, Holger -- Holger Seelig Leipzig, Germany holger.seelig at yahoo.de https://create3000.github.io/x_ite/ > Am 27.02.2025 um 11:13 schrieb Holger Seelig via x3d-public : > > Synthezising font styles is usually not an option for people interested in typography. A font usually comes in different styles, which are finely worked out and usually contain special features that cannot be achieved by synthesising, i.e. they usually look bad, but often are perfectly suitable for manually creating a new style from them. > > FontStyle node with url is a good idea and also easy to implement. I think it is enough to load one font: > > FontStyle { > url "DejaVuSerif-Italic.ttf" > style "BOLD" > } > > that's simple and is actually enough, otherwise it gets more complicated, and as Michalis already said the style doesn't matter in this case. > > Best regards, > Holger > > -- > Holger Seelig > Leipzig, Germany > > holger.seelig at yahoo.de > https://create3000.github.io/x_ite/ > >> Am 27.02.2025 um 04:41 schrieb Michalis Kamburelis via x3d-public : >> >> Nice, I see the core addition here is adding "url" to the "FontStyle", which can point to a font file (like WOFF, TTF, OTF). This makes perfect sense and should be easy to implement and useful for authors. The prose makes it clear that only *one* item from the "FontStyle.url" list is used, which is standard in X3D usage of "MFString url", good. >> >> Some feedback: >> >> 1. The text uses new terms: "font definition", "font library". I would advise to clearly define (and give examples) what is meant by each term (and maybe you don't really need all of them?). As always, testcase files would be great :) >> >> Admittedly, I don't fully understand myself what do you mean by "font definition", "font library". The terms I know, when working with fonts, are : >> >> A. "font file" (this is a single WOFF, TTF, OTF file). >> >> B. And "font family" (this is usually using 4 files, regular / italic / bold+italic / bold). >> >> In CGE, this is TCastleFontFamily component, corresponds to https://castle-engine.io/apidoc/html/CastleFonts.TCastleFontFamily.html . >> >> In CSS, this is called font-family. See e.g. https://stackoverflow.com/questions/12812441/how-do-i-use-woff-fonts-for-my-website how to use 4 WOFF files to define a CSS font-family. >> >> In X3D itself, the "FontStyle.family" also allows to choose from (system-level or browser-level) font families. So it's all good and consistent so far. >> >> Admittedly, I'm unsure how/if do my above terms map to "font library" and "font definition" terms that the spec on https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/text.html#FontStyle uses. The spec mentions "a font library that contains one or more font definitions". Can you show me (point to concrete testcases) what do you mean? What is a simple file that is "a font library with one font definition"? What is a simple file that is "a font library with multiple font definitions"? >> >> 2. It may be worth saying explicitly in the prose that: >> >> - When some font file indicated by "url" is successfully loaded, then the "FontStyle.family" no longer maters. The font is defined by the given URL. >> >> - When some font file indicated by "url" is successfully loaded (and it only contains a single font definition?) then the "FontStyle.style" (bold, italic..) also doesn't matter. >> >> That is, consider this: >> >> FontStyle { url "DejaVuSerif-Italic.ttf" } >> >> DejaVu is an open-source font, distributed also by Debian, and used by CGE, you can experiment with files on https://github.com/castle-engine/castle-engine/tree/master/src/fonts/data . >> >> ... then the "style" doesn't matter. That is, in this example: >> >> FontStyle { >> url "DejaVuSerif-Italic.ttf" >> style "BOLD" >> } >> >> ... the style "BOLD" value is ignored. Because you use "DejaVuSerif-Italic.ttf", so this is italic (and not bold) version of DejaVu. If someone wants bold, they should have used "DejaVuSerif-Bold.ttf". >> >> 3. In CGE, it is possible to use a collection of .ttf / .otf to define a font. Speculating, something like this (matching https://castle-engine.io/apidoc/html/CastleFonts.TCastleFontFamily.html ) could be available to express this in X3D: >> >> """ >> Shape { >> geometry Text { >> fontStyle FontStyle { >> familyComposed DEF DejaVu FontFamily { >> regularUrl "DejaVuSerif.ttf" >> italicUrl "DejaVuSerif-Italic.ttf" >> boldUrl "DejaVuSerif-Bold.ttf" >> boldItalicUrl "DejaVuSerif-BoldItalic.ttf" >> } >> } >> string "this has regular style" >> } >> } >> >> Shape { >> geometry Text { >> fontStyle FontStyle { >> composedFontFamily USE DejaVu >> style "ITALIC" >> } >> string "this has italic style" >> } >> } >> >> Shape { >> geometry Text { >> fontStyle FontStyle { >> composedFontFamily USE DejaVu >> style "BOLDITALIC" >> } >> string "this has italic+bold style" >> } >> } >> """ >> >> 4. I wonder whether the FontLibrary that you mentioned will fulfill some of the use-cases I mentioned above and answer some of my questions :) No rush, I understand this is in the design phase, I'll want and see what you propose, maybe when I see FontLibrary -> the above points will no longer matter because everything will be obvious. >> >> Regards, >> Michalis >> >> czw., 27 lut 2025 o 02:40 Brutzman, Donald (Don) (CIV) via x3d-public > napisa?(a): >>> Dick and I worked on suggested prose for X3D 4.1 with details continuing in Mantis 1490 below. >>> >>> Review request: >>> X3D 4.1 Architecture (draft), 15 Text component, 15.4.1 FontStyle >>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/text.html#FontStyle >>> Improvements: >>> Include all X3DURLObject fields, >>> SFTime [in,out] autoRefresh 0.0 [0,?) >>> SFTime [in,out] autoRefreshTimeLimit 3600.0 [0,?) >>> SFString [in,out] description "" >>> SFBool [in,out] load TRUE >>> MFString [in,out] url [] [URI] >>> Decided to NOT overload functionality of family field by adding file names (sorry Holger! adjusting your implementation will likely be simple in comparison) >>> >>> New prose: >>> The url field is optional and can refer to a relative or online address for a font library that contains one or more font definitions. An empty url list indicates that the default set of fonts provided by the browser are used. If present, only the first active font library retrieved from the url list shall be used. Individual font library files can be used by multiple FontStyle nodes in a scene. Each font file only needs to be loaded once per session. >>> X3D browsers shall support WOFF (MIME type application/x-font-woff) (see W3C WOFF File Format ). Support for the OpenType file format (MIME type application/x-font-opentype) (see OpenType Specification ) and TrueType file format (MIME type application/x-font-truetype) (see ISO/IEC 14496-22 Open Font Format ) is also recommended. >>> Security, licensing, and copyright/usage permissions are handled via the exposure of a font file itself. >>> Support for the autoRefresh, autoRefreshTimeLimit, and load fields is optional. >>> More details on the autoRefresh, autoRefreshTimeLimit, description, load, and url fields are contained in 9.2.1 URLs, URNs and URIs . >>> Looking it over, adding more functionality to FontStyle node seems to be unwise. Dick has an excellent proposal: >>> TODO alternative approach: move all new functionality into a separate FontLibrary node to avoid complicating FontStyle further. This also offers the ability to succinctly load multiple font libraries in a given scene. The expense of defining a new node for X3D is offset by clearer distinction between X3D 4.0 and 4.1, also simplifying model content significantly. >>> Feedback is welcome. >>> Leaving existing FontStyle implementations alone probably avoids many unintended side effects. First law of engineering: "If it ain't broke, don't fix it." >>> >>> Thanks for all review. It feels like we are finally converging on a straightforward approach to valuable future capabilities. >>> >>> Have fun with X3D fonts! ? >>> >>> 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 https://faculty.nps.edu/brutzman >>> >>> >>> From: Brutzman, Donald (Don) (CIV) > >>> Sent: Monday, February 24, 2025 9:32 AM >>> To: X3D > >>> Cc: Holger Seelig > >>> Subject: Re: [x3d-public] Open dyslexic and/or (unfortunately) comicsans fonts; draft X3D 4.1 prose for font files and libraries >>> >>> Wow, really super Holger! ? >>> >>> There was a conversation about this on x3d-public a few years back... We committed to adding it in X3D 4.1 and (if I recall correctly) also noted that adding a url field might enable usage of larger font files. >>> >>> I've attempted to capture this candidate specification change in a Mantis issue. All review, feedback, and improvements are always welcome. >>> Mantis 1490 FontStyle handling of font files and font libraries >>> https://mantis.web3d.org/view.php?id=1490 >>> Description. >>> A goal for X3D 4.1 is use of font files in FontStyle (see Mantis 0001464 ). >>> >>> Addition of individual-font files might be accomplished by listing the font file name in the FontStyle 'family' field. >>> >>> Referencing different fonts in a single combined font library file may require an additional field, for example 'url'. In general the use of a font library may be preferred, but repeatedly run-time retrieval of a font library is not desirable, since the file might be quite large and rarely changing. This might be noted in the specification prose, e.g. >>> >>> - "MFString [in,out] url [] [URI]" >>> - "The family field may list a specific font file. A font listed in the family field may be provided by a corresponding font library." >>> - "The url field may refer to a font library. Font libraries can be used by multiple FontStyle nodes in a scene and need only be loaded once per session." >>> >>> Support levels: add "Level 2, FontStyle, support for font files in family field and support for font libraries via url field ." >>> >>> Security, licensing, and copyright/usage issues are handled via the exposure of the font file itself. If retrievable (locally or online) then proper access is presumably handled separately. >>> >>> Additional information. >>> - X3D 4.1 (draft) Architecture, 15 Text component, 15.4.1 FontStyle >>> - https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/text.html#FontStyle >>> >>> - X3D 4.1 (draft) Architecture, 15 Text component, 15.4.2 Text >>> - https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/text.html#Text >>> >>> - X3D 4.1 (draft) Architecture, 15 Text component, 15.5 Support levels >>> - https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/text.html#SupportlLevels >>> >>> Have fun with X3D Text! :) >>> >>> 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 https://faculty.nps.edu/brutzman >>> >>> >>> From: x3d-public > on behalf of Holger Seelig via x3d-public > >>> Sent: Monday, February 24, 2025 2:48 AM >>> To: X3D > >>> Cc: Holger Seelig > >>> Subject: Re: [x3d-public] Open dyslexic and/or (unfortunately) comicsans fonts >>> >>> With X_ITE you can use a URL in the family field of a FontStyle node to specify a path to a custom font file. Provided you have one of these fonts, it should be very easy: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> string='"3D Text"'> >>> >> family='"path/to/your/font.otf", "SERIF"'/> >>> >>> >>> >>> >>> >>> >>> Supported File Formats: >>> https://create3000.github.io/x_ite/components/text/fontstyle/#supported-file-formats >>> >>> Best regards, >>> Holger >>> >>> -- >>> Holger Seelig >>> Leipzig, Germany >>> >>> holger.seelig at yahoo.de >>> https://create3000.github.io/x_ite/ >>> >>> Am 24.02.2025 um 11:09 schrieb John Carlson via x3d-public >: >>> >>> If someone knows how change the fonts of the standards to OpenDyslexic or ComicSans, that might be a great accessibility experiment. _______________________________________________ >>> x3d-public mailing list >>> x3d-public at web3d.org >>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>> >>> _______________________________________________ >>> x3d-public mailing list >>> x3d-public at web3d.org >>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >> _______________________________________________ >> x3d-public mailing list >> x3d-public at web3d.org >> http://web3d.org/mailman/listinfo/x3d-public_web3d.org > > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger.seelig at yahoo.de Thu Feb 27 03:30:23 2025 From: holger.seelig at yahoo.de (Holger Seelig) Date: Thu, 27 Feb 2025 12:30:23 +0100 Subject: [x3d-public] draft X3D 4.1 prose for font files and libraries In-Reply-To: <53C38717-DF47-468C-A7C8-9B53002E294B@yahoo.de> References: <3C001CF9-1B6D-4BF3-8958-6A7CDD020F9E@yahoo.de> <53C38717-DF47-468C-A7C8-9B53002E294B@yahoo.de> Message-ID: <59D8D722-2CBB-4EA2-98D9-8C35F151EF04@yahoo.de> Maybe the style field is still somehow useful, consider this: FontStyle { url "DejaVuSerif-Italic.ttf? family ?SANS" style ?ITALIC" } The url field is not empty, ie. try to load the font, but if the font cannot be loaded for some reasons, fall back to SANS+ITALIC default font and style. Best regards, Holger -- Holger Seelig Leipzig, Germany holger.seelig at yahoo.de https://create3000.github.io/x_ite/ > Am 27.02.2025 um 11:50 schrieb Holger Seelig : > > Don?t forget ScreenFontStyle, it is also derived from X3DFontStyleNode. > > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/layout.html#ScreenFontStyle > > Best regards, > Holger > > -- > Holger Seelig > Leipzig, Germany > > holger.seelig at yahoo.de > https://create3000.github.io/x_ite/ > >> Am 27.02.2025 um 11:13 schrieb Holger Seelig via x3d-public : >> >> Synthezising font styles is usually not an option for people interested in typography. A font usually comes in different styles, which are finely worked out and usually contain special features that cannot be achieved by synthesising, i.e. they usually look bad, but often are perfectly suitable for manually creating a new style from them. >> >> FontStyle node with url is a good idea and also easy to implement. I think it is enough to load one font: >> >> FontStyle { >> url "DejaVuSerif-Italic.ttf" >> style "BOLD" >> } >> >> that's simple and is actually enough, otherwise it gets more complicated, and as Michalis already said the style doesn't matter in this case. >> >> Best regards, >> Holger >> >> -- >> Holger Seelig >> Leipzig, Germany >> >> holger.seelig at yahoo.de >> https://create3000.github.io/x_ite/ >> >>> Am 27.02.2025 um 04:41 schrieb Michalis Kamburelis via x3d-public : >>> >>> Nice, I see the core addition here is adding "url" to the "FontStyle", which can point to a font file (like WOFF, TTF, OTF). This makes perfect sense and should be easy to implement and useful for authors. The prose makes it clear that only *one* item from the "FontStyle.url" list is used, which is standard in X3D usage of "MFString url", good. >>> >>> Some feedback: >>> >>> 1. The text uses new terms: "font definition", "font library". I would advise to clearly define (and give examples) what is meant by each term (and maybe you don't really need all of them?). As always, testcase files would be great :) >>> >>> Admittedly, I don't fully understand myself what do you mean by "font definition", "font library". The terms I know, when working with fonts, are : >>> >>> A. "font file" (this is a single WOFF, TTF, OTF file). >>> >>> B. And "font family" (this is usually using 4 files, regular / italic / bold+italic / bold). >>> >>> In CGE, this is TCastleFontFamily component, corresponds to https://castle-engine.io/apidoc/html/CastleFonts.TCastleFontFamily.html . >>> >>> In CSS, this is called font-family. See e.g. https://stackoverflow.com/questions/12812441/how-do-i-use-woff-fonts-for-my-website how to use 4 WOFF files to define a CSS font-family. >>> >>> In X3D itself, the "FontStyle.family" also allows to choose from (system-level or browser-level) font families. So it's all good and consistent so far. >>> >>> Admittedly, I'm unsure how/if do my above terms map to "font library" and "font definition" terms that the spec on https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/text.html#FontStyle uses. The spec mentions "a font library that contains one or more font definitions". Can you show me (point to concrete testcases) what do you mean? What is a simple file that is "a font library with one font definition"? What is a simple file that is "a font library with multiple font definitions"? >>> >>> 2. It may be worth saying explicitly in the prose that: >>> >>> - When some font file indicated by "url" is successfully loaded, then the "FontStyle.family" no longer maters. The font is defined by the given URL. >>> >>> - When some font file indicated by "url" is successfully loaded (and it only contains a single font definition?) then the "FontStyle.style" (bold, italic..) also doesn't matter. >>> >>> That is, consider this: >>> >>> FontStyle { url "DejaVuSerif-Italic.ttf" } >>> >>> DejaVu is an open-source font, distributed also by Debian, and used by CGE, you can experiment with files on https://github.com/castle-engine/castle-engine/tree/master/src/fonts/data . >>> >>> ... then the "style" doesn't matter. That is, in this example: >>> >>> FontStyle { >>> url "DejaVuSerif-Italic.ttf" >>> style "BOLD" >>> } >>> >>> ... the style "BOLD" value is ignored. Because you use "DejaVuSerif-Italic.ttf", so this is italic (and not bold) version of DejaVu. If someone wants bold, they should have used "DejaVuSerif-Bold.ttf". >>> >>> 3. In CGE, it is possible to use a collection of .ttf / .otf to define a font. Speculating, something like this (matching https://castle-engine.io/apidoc/html/CastleFonts.TCastleFontFamily.html ) could be available to express this in X3D: >>> >>> """ >>> Shape { >>> geometry Text { >>> fontStyle FontStyle { >>> familyComposed DEF DejaVu FontFamily { >>> regularUrl "DejaVuSerif.ttf" >>> italicUrl "DejaVuSerif-Italic.ttf" >>> boldUrl "DejaVuSerif-Bold.ttf" >>> boldItalicUrl "DejaVuSerif-BoldItalic.ttf" >>> } >>> } >>> string "this has regular style" >>> } >>> } >>> >>> Shape { >>> geometry Text { >>> fontStyle FontStyle { >>> composedFontFamily USE DejaVu >>> style "ITALIC" >>> } >>> string "this has italic style" >>> } >>> } >>> >>> Shape { >>> geometry Text { >>> fontStyle FontStyle { >>> composedFontFamily USE DejaVu >>> style "BOLDITALIC" >>> } >>> string "this has italic+bold style" >>> } >>> } >>> """ >>> >>> 4. I wonder whether the FontLibrary that you mentioned will fulfill some of the use-cases I mentioned above and answer some of my questions :) No rush, I understand this is in the design phase, I'll want and see what you propose, maybe when I see FontLibrary -> the above points will no longer matter because everything will be obvious. >>> >>> Regards, >>> Michalis >>> >>> czw., 27 lut 2025 o 02:40 Brutzman, Donald (Don) (CIV) via x3d-public > napisa?(a): >>>> Dick and I worked on suggested prose for X3D 4.1 with details continuing in Mantis 1490 below. >>>> >>>> Review request: >>>> X3D 4.1 Architecture (draft), 15 Text component, 15.4.1 FontStyle >>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/text.html#FontStyle >>>> Improvements: >>>> Include all X3DURLObject fields, >>>> SFTime [in,out] autoRefresh 0.0 [0,?) >>>> SFTime [in,out] autoRefreshTimeLimit 3600.0 [0,?) >>>> SFString [in,out] description "" >>>> SFBool [in,out] load TRUE >>>> MFString [in,out] url [] [URI] >>>> Decided to NOT overload functionality of family field by adding file names (sorry Holger! adjusting your implementation will likely be simple in comparison) >>>> >>>> New prose: >>>> The url field is optional and can refer to a relative or online address for a font library that contains one or more font definitions. An empty url list indicates that the default set of fonts provided by the browser are used. If present, only the first active font library retrieved from the url list shall be used. Individual font library files can be used by multiple FontStyle nodes in a scene. Each font file only needs to be loaded once per session. >>>> X3D browsers shall support WOFF (MIME type application/x-font-woff) (see W3C WOFF File Format ). Support for the OpenType file format (MIME type application/x-font-opentype) (see OpenType Specification ) and TrueType file format (MIME type application/x-font-truetype) (see ISO/IEC 14496-22 Open Font Format ) is also recommended. >>>> Security, licensing, and copyright/usage permissions are handled via the exposure of a font file itself. >>>> Support for the autoRefresh, autoRefreshTimeLimit, and load fields is optional. >>>> More details on the autoRefresh, autoRefreshTimeLimit, description, load, and url fields are contained in 9.2.1 URLs, URNs and URIs . >>>> Looking it over, adding more functionality to FontStyle node seems to be unwise. Dick has an excellent proposal: >>>> TODO alternative approach: move all new functionality into a separate FontLibrary node to avoid complicating FontStyle further. This also offers the ability to succinctly load multiple font libraries in a given scene. The expense of defining a new node for X3D is offset by clearer distinction between X3D 4.0 and 4.1, also simplifying model content significantly. >>>> Feedback is welcome. >>>> Leaving existing FontStyle implementations alone probably avoids many unintended side effects. First law of engineering: "If it ain't broke, don't fix it." >>>> >>>> Thanks for all review. It feels like we are finally converging on a straightforward approach to valuable future capabilities. >>>> >>>> Have fun with X3D fonts! ? >>>> >>>> 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 https://faculty.nps.edu/brutzman >>>> >>>> >>>> From: Brutzman, Donald (Don) (CIV) > >>>> Sent: Monday, February 24, 2025 9:32 AM >>>> To: X3D > >>>> Cc: Holger Seelig > >>>> Subject: Re: [x3d-public] Open dyslexic and/or (unfortunately) comicsans fonts; draft X3D 4.1 prose for font files and libraries >>>> >>>> Wow, really super Holger! ? >>>> >>>> There was a conversation about this on x3d-public a few years back... We committed to adding it in X3D 4.1 and (if I recall correctly) also noted that adding a url field might enable usage of larger font files. >>>> >>>> I've attempted to capture this candidate specification change in a Mantis issue. All review, feedback, and improvements are always welcome. >>>> Mantis 1490 FontStyle handling of font files and font libraries >>>> https://mantis.web3d.org/view.php?id=1490 >>>> Description. >>>> A goal for X3D 4.1 is use of font files in FontStyle (see Mantis 0001464 ). >>>> >>>> Addition of individual-font files might be accomplished by listing the font file name in the FontStyle 'family' field. >>>> >>>> Referencing different fonts in a single combined font library file may require an additional field, for example 'url'. In general the use of a font library may be preferred, but repeatedly run-time retrieval of a font library is not desirable, since the file might be quite large and rarely changing. This might be noted in the specification prose, e.g. >>>> >>>> - "MFString [in,out] url [] [URI]" >>>> - "The family field may list a specific font file. A font listed in the family field may be provided by a corresponding font library." >>>> - "The url field may refer to a font library. Font libraries can be used by multiple FontStyle nodes in a scene and need only be loaded once per session." >>>> >>>> Support levels: add "Level 2, FontStyle, support for font files in family field and support for font libraries via url field ." >>>> >>>> Security, licensing, and copyright/usage issues are handled via the exposure of the font file itself. If retrievable (locally or online) then proper access is presumably handled separately. >>>> >>>> Additional information. >>>> - X3D 4.1 (draft) Architecture, 15 Text component, 15.4.1 FontStyle >>>> - https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/text.html#FontStyle >>>> >>>> - X3D 4.1 (draft) Architecture, 15 Text component, 15.4.2 Text >>>> - https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/text.html#Text >>>> >>>> - X3D 4.1 (draft) Architecture, 15 Text component, 15.5 Support levels >>>> - https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/text.html#SupportlLevels >>>> >>>> Have fun with X3D Text! :) >>>> >>>> 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 https://faculty.nps.edu/brutzman >>>> >>>> >>>> From: x3d-public > on behalf of Holger Seelig via x3d-public > >>>> Sent: Monday, February 24, 2025 2:48 AM >>>> To: X3D > >>>> Cc: Holger Seelig > >>>> Subject: Re: [x3d-public] Open dyslexic and/or (unfortunately) comicsans fonts >>>> >>>> With X_ITE you can use a URL in the family field of a FontStyle node to specify a path to a custom font file. Provided you have one of these fonts, it should be very easy: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> string='"3D Text"'> >>>> >>> family='"path/to/your/font.otf", "SERIF"'/> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Supported File Formats: >>>> https://create3000.github.io/x_ite/components/text/fontstyle/#supported-file-formats >>>> >>>> Best regards, >>>> Holger >>>> >>>> -- >>>> Holger Seelig >>>> Leipzig, Germany >>>> >>>> holger.seelig at yahoo.de >>>> https://create3000.github.io/x_ite/ >>>> >>>> Am 24.02.2025 um 11:09 schrieb John Carlson via x3d-public >: >>>> >>>> If someone knows how change the fonts of the standards to OpenDyslexic or ComicSans, that might be a great accessibility experiment. _______________________________________________ >>>> x3d-public mailing list >>>> x3d-public at web3d.org >>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>>> >>>> _______________________________________________ >>>> x3d-public mailing list >>>> x3d-public at web3d.org >>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >>> _______________________________________________ >>> x3d-public mailing list >>> x3d-public at web3d.org >>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org >> >> _______________________________________________ >> x3d-public mailing list >> x3d-public at web3d.org >> http://web3d.org/mailman/listinfo/x3d-public_web3d.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreasplesch at gmail.com Thu Feb 27 04:26:13 2025 From: andreasplesch at gmail.com (Andreas Plesch) Date: Thu, 27 Feb 2025 07:26:13 -0500 Subject: [x3d-public] draft X3D 4.1 prose for font files and libraries In-Reply-To: References: Message-ID: Since I wanted to do this for some time as it really makes webfonts much more usable with x3dom, I came up with a first implementation of the url field: https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/dc9111dcd106f1a69d567ceca8f52701/raw/8cdf9764f11e08b5f541dee487fc0811bb0cf927/FontHaveFunWithX3D.x3d This is experimental and only for the viewer. All loading can be done now by x3dom. Both the style and family fields are essentially ignored if a url MFString is available. Multiple urls can be provided as fallbacks. The url field accepts input and can be changed dynamically. Here are other examples which show how css in the html can be used for webfont loading. https://andreasplesch.github.io/x3dom/test/functional/text_fonts.html That can have advantages as this then provides all of the very many css options to x3d. For example, it is straightforward to copy and paste the css provided by google fonts. The link between css and x3d becomes the font-family name plus style plus weight. No changes to the spec. are needed. The simplest solution other than a url field I can think of is a new Font node which can only represent one font file with a single font and overrides family and style fields. That node can then be DEF/USEd between Text nodes. Perhaps there could be an additional FontLibray node which can hold multiple Font nodes but I am not sure if this is necessary. In theory, it would be possible to add style (normal, italic) and weight (quite a few classes, and numeric) fields to such a Font node. These would define what the font provides. Then the FontStyle fields could be used to either select the closest match for rendering, or do synthesis which can be useful as some fonts do not have bold or italic versions. But all this is really the responsibility of the author anyways, and not necessary. Andreas On Wed, Feb 26, 2025 at 10:51?PM Michalis Kamburelis < michalis.kambi at gmail.com> wrote: > Andreas Plesch wrote: > > https://www.w3.org/TR/WOFF2/ is a compressed version of WOFF which > seems popular on the web due to smaller file sizes. For example, it is used > by the Google free Font service. I do not know if there are js/pascal/c > etc. loading libraries for woff2 but it should at least be recommended. > > CGE (Pascal) just uses FreeType for font reading, so we should support > everything that FreeType handles :) And it does support WOFF 2 > according to https://www.phoronix.com/news/FreeType-2.10.2-Released . > > > > > From what I can tell WOFF and WOFF2 do not need to include font family > name information inside the file. So I think that means if such a file is > provided it will take precedence over the family field. Holger's > overloading suggestion implicitly did this. > > > > A web browser will synthesize bold and italic versions from a normal > font version. Should this become a requirement for x3d as well ? Probably > not. If authors want to use a bold version for certain, they need to > provide corresponding font files. > > I see Andres comments align nicely with mine, posted 5 mins ago :) > > I also don't think X3D browsers should have the requirement to > synthesize bold and italic versions from a normal font version. If > FreeType doesn't do this (and I don't think it can) then it's not > something I would ever implement, frankly. I'm not even sure how good > are WWW browsers at doing this "synthesizing". The recommendation for > using fonts, that I always seen followed, is that you need 4 font > files (regular, bold, italic, bold+italic) if you want to provide all > the options. The font authors seems to generally agree -- most fonts > come with 4 such files. > > And as Andreas said, the spec should say that "url" overrides "family". > > Regards, > Michalis > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brutzman at nps.edu Fri Feb 28 10:55:53 2025 From: brutzman at nps.edu (Brutzman, Donald (Don) (CIV)) Date: Fri, 28 Feb 2025 18:55:53 +0000 Subject: [x3d-public] draft X3D 4.1 prose for font files and libraries In-Reply-To: References: Message-ID: Thanks everyone for responses, implementation improvements, technical details, and many insights. First positive takeaway: WOFF File Format 2.0 is the clear preference to WOFF 1.0. WOFF File Format 2.0, W3C Recommendation, 08 August 2024 * "Abstract. Based on experience with WOFF 1.0, which is widely deployed, this specification was developed to provide improved compression and thus lower use of network bandwidth, while still allowing fast decompression even on mobile devices. This is achieved by combining a content-aware preprocessing step and improved entropy coding, compared to the Flate compression used in WOFF 1.0." * https://www.w3.org/TR/WOFF2 Clearly, from recent excellent emails, there are many implementer-specific issues and interactions when adding font files that are good to know about, but don't necessarily need to be expressed in an X3D model (or the X3D Architecture specification). Dick and I worked further today to assess whether separation of font files from FontStyle node into a FontLibrary node was the preferred to represent this information in an X3D model. We also repeated WOFF Recommendation's use of term "collection" as part of a FontLibrary definition. * The FontLibrary node specifies a collection of one or more font family definitions. A font family may include one or more related font style definitions. FontLibrary provides the ability to selectively load font files for use by FontStyle and ScreenFontStyle nodes. FontLibrary node pros (meaning separation of font files from FontStyle node): * Keeps existing (and fairly complex) FontStyle implementations unchanged * Separation of loading and presentation functionality between two nodes * FontLibrary simply adds to the selection of fonts available, and retains emphasis of family and style fields within a given FontStyle node. * If separate font files redefine a given family (with the same name), then addition of enabled field might allow authors to determine which of them is relevant. However enabled field can be considered redundant (since changing url has same effect). * Alternative approach to use of an enabled field, we might also need to add a sentence such as * "If a font family is redefined by multiple FontLibrary nodes, then the first defined family is used." * (or we can remain silent and let browser implementations sort that out) FontLibrary node cons (meaning bundle all url functionality in FontStyle): * Closer coupling of family field and font files themselves, recent email dialog indicates that sometimes the font file simply overrides the family field... * We do not want to change any defined functionality for family and style fields, they still seem correct in X3D Architecture and no suitable changes yet seen. * No need for enabled field. Our current opinion is that FontLibrary provides a superior approach to continued growth of FontStyle node. To facilitate comparison and review, current draft has proposed FontLibrary prose in yellow, and alternate (not accepted) FontStyle alternative in cyan. * X3D 4.1 (draft) Architecture, clause 15 Text component, 15.4.1 FontLibrary * https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/text.html#FontLibrary X3D Architecture 4.1 draft ? ISO/IEC 19775-1:202x ? 15 Text component 15.2.2.4 Language. The language field specifies the context of the language for the text string in the form of a language and a country in which that language is used. Both the language and the country are specified using the language tags defined in which may specify only a country (using the three-character codes defined in ISO 3166) or both a language (using the two-character codes ... www.web3d.org Additional questions to ponder, further insights welcome: * Our impression of the term 'webfont' is that it is simply a generic term, not a standard or specification per se, and often employed to reference WOFF. Is that correct? * Font files tend to be large. Might there ever be a use case where an author chooses to define a font as source text in the url field? We have some precedent for this in Script url and (sorta) PixelTexture. Nevertheless font definitions are also convoluted and (perhaps notoriously) difficult to parse. Of note is that WOFF2 specifically is designed for effective binary compression. Our inclination so far is to not describe (or encourage) definition of the font within an X3D model. YMMV (though we doubt it). Much better authoring approach is to use any of many conversion tools that might credibly update a legacy font into WOFF2. Thanks everyone for leaning forward on this, looking ahead to continuing discussion. Have fun with font library collections for X3D models! ? 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 https://faculty.nps.edu/brutzman ________________________________ From: x3d-public on behalf of Brutzman, Donald (Don) (CIV) via x3d-public Sent: Wednesday, February 26, 2025 5:39 PM To: X3D Cc: Brutzman, Donald (Don) (CIV) Subject: Re: [x3d-public] draft X3D 4.1 prose for font files and libraries Dick and I worked on suggested prose for X3D 4.1 with details continuing in Mantis 1490 below. Review request: * X3D 4.1 Architecture (draft), 15 Text component, 15.4.1 FontStyle * https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/text.html#FontStyle Improvements: * Include all X3DURLObject fields, SFTime [in,out] autoRefresh 0.0 [0,?) SFTime [in,out] autoRefreshTimeLimit 3600.0 [0,?) SFString [in,out] description "" SFBool [in,out] load TRUE MFString [in,out] url [] [URI] * Decided to NOT overload functionality of family field by adding file names (sorry Holger! adjusting your implementation will likely be simple in comparison) * New prose: The url field is optional and can refer to a relative or online address for a font library that contains one or more font definitions. An empty url list indicates that the default set of fonts provided by the browser are used. If present, only the first active font library retrieved from the url list shall be used. Individual font library files can be used by multiple FontStyle nodes in a scene. Each font file only needs to be loaded once per session. X3D browsers shall support WOFF (MIME type application/x-font-woff) (see W3C WOFF File Format). Support for the OpenType file format (MIME type application/x-font-opentype) (see OpenType Specification) and TrueType file format (MIME type application/x-font-truetype) (see ISO/IEC 14496-22 Open Font Format) is also recommended. Security, licensing, and copyright/usage permissions are handled via the exposure of a font file itself. Support for the autoRefresh, autoRefreshTimeLimit, and load fields is optional. More details on the autoRefresh, autoRefreshTimeLimit, description, load, and url fields are contained in 9.2.1 URLs, URNs and URIs. Looking it over, adding more functionality to FontStyle node seems to be unwise. Dick has an excellent proposal: TODO alternative approach: move all new functionality into a separate FontLibrary node to avoid complicating FontStyle further. This also offers the ability to succinctly load multiple font libraries in a given scene. The expense of defining a new node for X3D is offset by clearer distinction between X3D 4.0 and 4.1, also simplifying model content significantly. Feedback is welcome. Leaving existing FontStyle implementations alone probably avoids many unintended side effects. First law of engineering: "If it ain't broke, don't fix it." Thanks for all review. It feels like we are finally converging on a straightforward approach to valuable future capabilities. Have fun with X3D fonts! ? 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 https://faculty.nps.edu/brutzman ________________________________ From: Brutzman, Donald (Don) (CIV) Sent: Monday, February 24, 2025 9:32 AM To: X3D Cc: Holger Seelig Subject: Re: [x3d-public] Open dyslexic and/or (unfortunately) comicsans fonts; draft X3D 4.1 prose for font files and libraries Wow, really super Holger! ? There was a conversation about this on x3d-public a few years back... We committed to adding it in X3D 4.1 and (if I recall correctly) also noted that adding a url field might enable usage of larger font files. I've attempted to capture this candidate specification change in a Mantis issue. All review, feedback, and improvements are always welcome. * Mantis 1490 FontStyle handling of font files and font libraries * https://mantis.web3d.org/view.php?id=1490 Description. A goal for X3D 4.1 is use of font files in FontStyle (see Mantis 0001464). Addition of individual-font files might be accomplished by listing the font file name in the FontStyle 'family' field. Referencing different fonts in a single combined font library file may require an additional field, for example 'url'. In general the use of a font library may be preferred, but repeatedly run-time retrieval of a font library is not desirable, since the file might be quite large and rarely changing. This might be noted in the specification prose, e.g. - "MFString [in,out] url [] [URI]" - "The family field may list a specific font file. A font listed in the family field may be provided by a corresponding font library." - "The url field may refer to a font library. Font libraries can be used by multiple FontStyle nodes in a scene and need only be loaded once per session." Support levels: add "Level 2, FontStyle, support for font files in family field and support for font libraries via url field ." Security, licensing, and copyright/usage issues are handled via the exposure of the font file itself. If retrievable (locally or online) then proper access is presumably handled separately. Additional information. - X3D 4.1 (draft) Architecture, 15 Text component, 15.4.1 FontStyle - https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/text.html#FontStyle - X3D 4.1 (draft) Architecture, 15 Text component, 15.4.2 Text - https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/text.html#Text - X3D 4.1 (draft) Architecture, 15 Text component, 15.5 Support levels - https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/text.html#SupportlLevels Have fun with X3D Text! :) 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 https://faculty.nps.edu/brutzman ________________________________ From: x3d-public on behalf of Holger Seelig via x3d-public Sent: Monday, February 24, 2025 2:48 AM To: X3D Cc: Holger Seelig Subject: Re: [x3d-public] Open dyslexic and/or (unfortunately) comicsans fonts With X_ITE you can use a URL in the family field of a FontStyle node to specify a path to a custom font file. Provided you have one of these fonts, it should be very easy: Supported File Formats: https://create3000.github.io/x_ite/components/text/fontstyle/#supported-file-formats Best regards, Holger -- Holger Seelig Leipzig, Germany holger.seelig at yahoo.de https://create3000.github.io/x_ite/ Am 24.02.2025 um 11:09 schrieb John Carlson via x3d-public : If someone knows how change the fonts of the standards to OpenDyslexic or ComicSans, that might be a great accessibility experiment. _______________________________________________ x3d-public mailing list x3d-public at web3d.org http://web3d.org/mailman/listinfo/x3d-public_web3d.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreasplesch at gmail.com Fri Feb 28 13:35:18 2025 From: andreasplesch at gmail.com (Andreas Plesch) Date: Fri, 28 Feb 2025 16:35:18 -0500 Subject: [x3d-public] draft X3D 4.1 prose for font files and libraries In-Reply-To: References: Message-ID: I think many of the recent comments were actually applicable across implementations and rather generic. Opentype and Truetype support font collections: https://learn.microsoft.com/en-us/typography/opentype/spec/otff#filenames, https://docs.fileformat.com/font/ttc/ TTC and OTC collections appear to be used mostly for Asian glyph sets. Most font files, in contrast, contain data for only one family. "Variable fonts" are more common now. The files contain information on multiple weights (light, normal, plan, numerical) and styles (normal, italic, oblique), and potentially other "axes" (outlines, shadows). In effect, they are also font collections, for a single family. In summary, font files may contain: 1) a collection of different font families (Asian) 2) a single font family with multiple variants (quite a few web fonts) 3) a single font family with a single weight and style, no variants (probably most) X3D may choose to consider only the simplest option (3). As written, the "FontLibrary" node does not appear to be a possible value of a field. It seems that SFNode [FontLibrary] fontLibrary field for FontStyle would be an option to consider but perhaps a Scene wide scope would also make sense. The font file data do not necessarily contain a family name. It may be necessary to have the capability to explicitly assign a family name to a font file, say in a SFString FontLibrary.family field. This is also the reason why a font sourced from a font file would take precedence over a font specified in the FontStyle.family field, if the url sourced font data is not associated with a family name. I have seen large WOFF files which are split up into multiple files with limited character coverage. The web browser then can be told which unicode character range is covered by a given font file and use that to choose to download only this file after determining what range is needed for rendering a text. That seems too complex to support (unless the web browser itself renders the text for use with x3d). Another strategy is to provide separate font files per weight or style, or language. It would be beneficial to separate resource information (source of data, data descriptors) from presentation (targeted design, fallbacks). There will need to be a link (family name, field - field value). Some feedback, -Andreas On Fri, Feb 28, 2025 at 1:57?PM wrote: > Send x3d-public mailing list submissions to > x3d-public at web3d.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > or, via email, send a message with subject or body 'help' to > x3d-public-request at web3d.org > > You can reach the person managing the list at > x3d-public-owner at web3d.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of x3d-public digest..." > > > Today's Topics: > > 1. Re: draft X3D 4.1 prose for font files and libraries > (Brutzman, Donald (Don) (CIV)) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 28 Feb 2025 18:55:53 +0000 > From: "Brutzman, Donald (Don) (CIV)" > To: X3D > Subject: Re: [x3d-public] draft X3D 4.1 prose for font files and > libraries > Message-ID: > < > BY3PR13MB48845D9AAA63A5F0A0015588C4CC2 at BY3PR13MB4884.namprd13.prod.outlook.com > > > > Content-Type: text/plain; charset="utf-8" > > Thanks everyone for responses, implementation improvements, technical > details, and many insights. > > First positive takeaway: WOFF File Format 2.0 is the clear preference to > WOFF 1.0. > > WOFF File Format 2.0, W3C Recommendation, 08 August 2024 > > * > "Abstract. Based on experience with WOFF 1.0, which is widely deployed, > this specification was developed to provide improved compression and thus > lower use of network bandwidth, while still allowing fast decompression > even on mobile devices. This is achieved by combining a content-aware > preprocessing step and improved entropy coding, compared to the Flate > compression used in WOFF 1.0." > * > https://www.w3.org/TR/WOFF2 > > Clearly, from recent excellent emails, there are many implementer-specific > issues and interactions when adding font files that are good to know about, > but don't necessarily need to be expressed in an X3D model (or the X3D > Architecture specification). > > Dick and I worked further today to assess whether separation of font files > from FontStyle node into a FontLibrary node was the preferred to represent > this information in an X3D model. We also repeated WOFF Recommendation's > use of term "collection" as part of a FontLibrary definition. > > * The FontLibrary node specifies a collection of one or more font > family definitions. A font family may include one or more related font > style definitions. FontLibrary provides the ability to selectively load > font files for use by FontStyle< > https://outlook.office.com/mail/id/AAkALgAAAAAAHYQDEapmEc2byACqAC%2FEWg0AN5ikByHYYkeveIfklhUi1gAG%2Blh21AAA?nativeVersion=1.2025.219.400#FontStyle> > and ScreenFontStyle< > https://outlook.office.com/mail/id/layout.html#ScreenFontStyle> nodes. > > FontLibrary node pros (meaning separation of font files from FontStyle > node): > > * > Keeps existing (and fairly complex) FontStyle implementations unchanged > * > Separation of loading and presentation functionality between two nodes > * > FontLibrary simply adds to the selection of fonts available, and retains > emphasis of family and style fields within a given FontStyle node. > * > If separate font files redefine a given family (with the same name), then > addition of enabled field might allow authors to determine which of them is > relevant. However enabled field can be considered redundant (since > changing url has same effect). > * > Alternative approach to use of an enabled field, we might also need to add > a sentence such as > * > "If a font family is redefined by multiple FontLibrary nodes, then the > first defined family is used." > * > (or we can remain silent and let browser implementations sort that out) > > FontLibrary node cons (meaning bundle all url functionality in FontStyle): > > * > Closer coupling of family field and font files themselves, recent email > dialog indicates that sometimes the font file simply overrides the family > field... > * > We do not want to change any defined functionality for family and style > fields, they still seem correct in X3D Architecture and no suitable changes > yet seen. > * > No need for enabled field. > > Our current opinion is that FontLibrary provides a superior approach to > continued growth of FontStyle node. To facilitate comparison and review, > current draft has proposed FontLibrary prose in yellow, and alternate (not > accepted) FontStyle alternative in cyan. > > * > X3D 4.1 (draft) Architecture, clause 15 Text component, 15.4.1 FontLibrary > * > > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/text.html#FontLibrary > X3D > > Architecture 4.1 draft ? ISO/IEC 19775-1:202x ? 15 Text component< > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/text.html#FontLibrary > > > 15.2.2.4 Language. The language field specifies the context of the > language for the text string in the form of a language and a country in > which that language is used. Both the language and the country are > specified using the language tags defined in which may specify only a > country (using the three-character codes defined in ISO 3166) or both a > language (using the two-character codes ... > www.web3d.org > > > Additional questions to ponder, further insights welcome: > > * > Our impression of the term 'webfont' is that it is simply a generic term, > not a standard or specification per se, and often employed to reference > WOFF. Is that correct? > > * > Font files tend to be large. Might there ever be a use case where an > author chooses to define a font as source text in the url field? We have > some precedent for this in Script url and (sorta) PixelTexture. > Nevertheless font definitions are also convoluted and (perhaps notoriously) > difficult to parse. Of note is that WOFF2 specifically is designed for > effective binary compression. Our inclination so far is to not describe > (or encourage) definition of the font within an X3D model. YMMV (though we > doubt it). Much better authoring approach is to use any of many conversion > tools that might credibly update a legacy font into WOFF2. > > Thanks everyone for leaning forward on this, looking ahead to continuing > discussion. > > Have fun with font library collections for X3D models! ? > > > 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 > https://faculty.nps.edu/brutzman > > > > ________________________________ > From: x3d-public on behalf of Brutzman, > Donald (Don) (CIV) via x3d-public > Sent: Wednesday, February 26, 2025 5:39 PM > To: X3D > Cc: Brutzman, Donald (Don) (CIV) > Subject: Re: [x3d-public] draft X3D 4.1 prose for font files and libraries > > Dick and I worked on suggested prose for X3D 4.1 with details continuing > in Mantis 1490 below. > > Review request: > > * > X3D 4.1 Architecture (draft), 15 Text component, 15.4.1 FontStyle > * > > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/text.html#FontStyle > > Improvements: > > * > Include all X3DURLObject fields, > > SFTime [in,out] autoRefresh 0.0 [0,?) > SFTime [in,out] autoRefreshTimeLimit 3600.0 [0,?) > SFString [in,out] description "" > SFBool [in,out] load TRUE > MFString [in,out] url [] [URI] > > * > Decided to NOT overload functionality of family field by adding file names > (sorry Holger! adjusting your implementation will likely be simple in > comparison) > > * > New prose: > > The url field is optional and can refer to a relative or online address > for a font library that contains one or more font definitions. An empty url > list indicates that the default set of fonts provided by the browser are > used. If present, only the first active font library retrieved from the url > list shall be used. Individual font library files can be used by multiple > FontStyle nodes in a scene. Each font file only needs to be loaded once per > session. > X3D browsers shall support WOFF (MIME type application/x-font-woff) (see > W3C WOFF File Format< > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/references.html#W3C_WOFF>). > Support for the OpenType file format (MIME type > application/x-font-opentype) (see OpenType Specification< > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/bibliography.html#OPENTYPE>) > and TrueType file format (MIME type application/x-font-truetype) (see > ISO/IEC 14496-22 Open Font Format< > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/references.html#I14496_22>) > is also recommended. > Security, licensing, and copyright/usage permissions are handled via the > exposure of a font file itself. > Support for the autoRefresh, autoRefreshTimeLimit, and load fields is > optional. > More details on the autoRefresh, autoRefreshTimeLimit, description, load, > and url fields are contained in 9.2.1 URLs, URNs and URIs< > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/networking.html#URLs > >. > Looking it over, adding more functionality to FontStyle node seems to be > unwise. Dick has an excellent proposal: > TODO alternative approach: move all new functionality into a separate > FontLibrary node to avoid complicating FontStyle further. This also offers > the ability to succinctly load multiple font libraries in a given scene. > The expense of defining a new node for X3D is offset by clearer distinction > between X3D 4.0 and 4.1, also simplifying model content significantly. > Feedback is welcome. > Leaving existing FontStyle implementations alone probably avoids many > unintended side effects. First law of engineering: "If it ain't broke, > don't fix it." > > Thanks for all review. It feels like we are finally converging on a > straightforward approach to valuable future capabilities. > > Have fun with X3D fonts! ? > > > 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 > https://faculty.nps.edu/brutzman > > > > ________________________________ > From: Brutzman, Donald (Don) (CIV) > Sent: Monday, February 24, 2025 9:32 AM > To: X3D > Cc: Holger Seelig > Subject: Re: [x3d-public] Open dyslexic and/or (unfortunately) comicsans > fonts; draft X3D 4.1 prose for font files and libraries > > Wow, really super Holger! ? > > There was a conversation about this on x3d-public a few years back... We > committed to adding it in X3D 4.1 and (if I recall correctly) also noted > that adding a url field might enable usage of larger font files. > > I've attempted to capture this candidate specification change in a Mantis > issue. All review, feedback, and improvements are always welcome. > > * > Mantis 1490 FontStyle handling of font files and font libraries > * > https://mantis.web3d.org/view.php?id=1490 > > Description. > A goal for X3D 4.1 is use of font files in FontStyle (see Mantis 0001464< > https://mantis.web3d.org/view.php?id=1464>). > > Addition of individual-font files might be accomplished by listing the > font file name in the FontStyle 'family' field. > > Referencing different fonts in a single combined font library file may > require an additional field, for example 'url'. In general the use of a > font library may be preferred, but repeatedly run-time retrieval of a font > library is not desirable, since the file might be quite large and rarely > changing. This might be noted in the specification prose, e.g. > > - "MFString [in,out] url [] [URI]" > - "The family field may list a specific font file. A font listed in the > family field may be provided by a corresponding font library." > - "The url field may refer to a font library. Font libraries can be used > by multiple FontStyle nodes in a scene and need only be loaded once per > session." > > Support levels: add "Level 2, FontStyle, support for font files in family > field and support for font libraries via url field ." > > Security, licensing, and copyright/usage issues are handled via the > exposure of the font file itself. If retrievable (locally or online) then > proper access is presumably handled separately. > > Additional information. > - X3D 4.1 (draft) Architecture, 15 Text component, 15.4.1 FontStyle > - > https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/text.html#FontStyle > > - X3D 4.1 (draft) Architecture, 15 Text component, 15.4.2 Text > - > https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/text.html#Text > > - X3D 4.1 (draft) Architecture, 15 Text component, 15.5 Support levels > - > https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/text.html#SupportlLevels > > Have fun with X3D Text! :) > > > 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 > https://faculty.nps.edu/brutzman > > > > ________________________________ > From: x3d-public on behalf of Holger > Seelig via x3d-public > Sent: Monday, February 24, 2025 2:48 AM > To: X3D > Cc: Holger Seelig > Subject: Re: [x3d-public] Open dyslexic and/or (unfortunately) comicsans > fonts > > With X_ITE you can use a URL in the family field of a FontStyle node to > specify a path to a custom font file. Provided you have one of these fonts, > it should be very easy: > > > https://www.web3d.org/specifications/x3d-4.0.dtd"> > > > > > > > > > > > string='"3D Text"'> > family='"path/to/your/font.otf", "SERIF"'/> > > > > > > > Supported File Formats: > > https://create3000.github.io/x_ite/components/text/fontstyle/#supported-file-formats > > Best regards, > Holger > > -- > Holger Seelig > Leipzig, Germany > > holger.seelig at yahoo.de > https://create3000.github.io/x_ite/ > > Am 24.02.2025 um 11:09 schrieb John Carlson via x3d-public < > x3d-public at web3d.org>: > > If someone knows how change the fonts of the standards to OpenDyslexic or > ComicSans, that might be a great accessibility experiment. > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20250228/17b1bfe8/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > > > ------------------------------ > > End of x3d-public Digest, Vol 191, Issue 131 > ******************************************** > -- Andreas Plesch Waltham, MA 02453 -------------- next part -------------- An HTML attachment was scrubbed... URL: From michalis.kambi at gmail.com Fri Feb 28 20:52:24 2025 From: michalis.kambi at gmail.com (Michalis Kamburelis) Date: Sat, 1 Mar 2025 05:52:24 +0100 Subject: [x3d-public] draft X3D 4.1 prose for font files and libraries In-Reply-To: References: Message-ID: As for FontLibrary, https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/text.html#FontLibrary : I admit I don't understand this proposal (yet). 1. Where is the FontLibrary actually used? It doesn't seem you can refer to a FontLibrary node in any way. It's also not X3DChildNode, so you cannot just place it in groups. 2. The sentence """If present, only the first active font library retrieved from the url list shall be used."""" --- What is the meaning of word "used" in this sentence? Used for what? 3. """Individual font library files can be used by multiple FontStyle nodes in a scene.""" -- How? FontStyle does not refer to FontLibrary. And I understand in this version, FontStyle would not have its own FontStyle.url field. Did you maybe want to add a field like "SFNode FontLibrary fontLibrary" to FontStyle or Text? Or make FontLibrary a X3DChildNode? 4. A testcase, preferably many testcase(s), explaining the FontLibrary usage (X3D files + intended rendering) would very helpful. (Same goes for the previous proposal actually.) Please provide testcases along with spec prose -- they make the intention more obvious. Overall, so far, I admit FontLibrary is confusing to me, I don't know what it means. The previous proposal (extending FontStyle) seems more straightforward -- a few people (including me) had feedback, but it seems that we all "got the intention" of FontStyle.url correctly, we just pointed some things to improve in wording. Regards, Michalis pt., 28 lut 2025 o 19:56 Brutzman, Donald (Don) (CIV) via x3d-public < x3d-public at web3d.org> napisa?(a): > Thanks everyone for responses, implementation improvements, technical > details, and many insights. > > First positive takeaway: WOFF File Format 2.0 is the clear preference to > WOFF 1.0. > > WOFF File Format 2.0, W3C Recommendation, 08 August 2024 > > - "Abstract. Based on experience with WOFF 1.0, which is widely > deployed, this specification was developed to provide improved compression > and thus lower use of network bandwidth, while still allowing fast > decompression even on mobile devices. This is achieved by combining a > content-aware preprocessing step and improved entropy coding, compared to > the Flate compression used in WOFF 1.0." > - https://www.w3.org/TR/WOFF2 > > Clearly, from recent excellent emails, there are many implementer-specific > issues and interactions when adding font files that are good to know about, > but don't necessarily need to be expressed in an X3D model (or the X3D > Architecture specification). > > Dick and I worked further today to assess whether separation of font files > from FontStyle node into a FontLibrary node was the preferred to represent > this information in an X3D model. We also repeated WOFF Recommendation's > use of term "collection" as part of a *FontLibrary *definition. > > - The FontLibrary node specifies a collection of one or more font > family definitions. A font family may include one or more related font > style definitions. FontLibrary provides the ability to selectively load > font files for use by FontStyle > and > ScreenFontStyle > nodes. > > FontLibrary node pros (meaning separation of font files from FontStyle > node): > > - Keeps existing (and fairly complex) FontStyle implementations > unchanged > - Separation of loading and presentation functionality between two > nodes > - FontLibrary simply adds to the selection of fonts available, and > retains emphasis of *family *and *style *fields within a given > FontStyle node. > - If separate font files redefine a given family (with the same name), > then addition of *enabled *field might allow authors to determine > which of them is relevant. However *enabled *field can be considered > redundant (since changing url has same effect). > - Alternative approach to use of an *enabled *field, we might also > need to add a sentence such as > - "If a font family is redefined by multiple FontLibrary nodes, then > the first defined family is used." > - (or we can remain silent and let browser implementations sort > that out) > > FontLibrary node cons (meaning bundle all url functionality in FontStyle): > > - Closer coupling of *family *field and font files themselves, recent > email dialog indicates that sometimes the font file simply overrides the > family field... > - We do not want to change any defined functionality for *family* and *style > *fields, they still seem correct in X3D Architecture and no suitable > changes yet seen. > - No need for *enabled *field. > > Our current opinion is that FontLibrary provides a superior approach to > continued growth of FontStyle node. To facilitate comparison and review, > current draft has proposed FontLibrary prose in yellow, and alternate > (not accepted) FontStyle alternative in cyan. > > - X3D 4.1 (draft) Architecture, clause 15 Text component, 15.4.1 > FontLibrary > - > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/text.html#FontLibrary > X3D Architecture 4.1 draft ? ISO/IEC 19775-1:202x ? 15 Text component > > 15.2.2.4 Language. The language field specifies the context of the > language for the text string in the form of a language and a country in > which that language is used. Both the language and the country are > specified using the language tags defined in which may specify only a > country (using the three-character codes defined in ISO 3166) or both a > language (using the two-character codes ... > www.web3d.org > > > Additional questions to ponder, further insights welcome: > > - Our impression of the term 'webfont' is that it is simply a generic > term, not a standard or specification per se, and often employed to > reference WOFF. Is that correct? > > - Font files tend to be large. Might there ever be a use case where > an author chooses to define a font as source text in the url field? We > have some precedent for this in Script url and (sorta) PixelTexture. > Nevertheless font definitions are also convoluted and (perhaps notoriously) > difficult to parse. Of note is that WOFF2 specifically is designed for > effective binary compression. Our inclination so far is to not describe > (or encourage) definition of the font within an X3D model. YMMV (though we > doubt it). Much better authoring approach is to use any of many conversion > tools that might credibly update a legacy font into WOFF2. > > Thanks everyone for leaning forward on this, looking ahead to continuing > discussion. > > Have fun with font library collections for X3D models! ? > > > 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 > https://faculty.nps.edu/brutzman > > > > ------------------------------ > *From:* x3d-public on behalf of Brutzman, > Donald (Don) (CIV) via x3d-public > *Sent:* Wednesday, February 26, 2025 5:39 PM > *To:* X3D > *Cc:* Brutzman, Donald (Don) (CIV) > *Subject:* Re: [x3d-public] draft X3D 4.1 prose for font files and > libraries > > Dick and I worked on suggested prose for X3D 4.1 with details continuing > in Mantis 1490 below. > > Review request: > > - X3D 4.1 Architecture (draft), 15 Text component, 15.4.1 FontStyle > - > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/text.html#FontStyle > > Improvements: > > - Include all X3DURLObject fields, > > SFTime [in,out] autoRefresh 0.0 [0,?) > SFTime [in,out] autoRefreshTimeLimit 3600.0 [0,?) > SFString [in,out] description "" > SFBool [in,out] load TRUE > MFString [in,out] url [] [URI] > > - Decided to NOT overload functionality of *family * field by adding > file names (sorry Holger! adjusting your implementation will likely be > simple in comparison) > > - New prose: > > The *url* field is optional and can refer to a relative or online address > for a font library that contains one or more font definitions. An empty > *url* list indicates that the default set of fonts provided by the > browser are used. If present, only the first active font library retrieved > from the *url* list shall be used. Individual font library files can be > used by multiple FontStyle nodes in a scene. Each font file only needs to > be loaded once per session. > X3D browsers shall support WOFF (MIME type application/x-font-woff) (see W3C > WOFF File Format > ). > Support for the OpenType file format (MIME type > application/x-font-opentype) (see OpenType Specification > ) > and TrueType file format (MIME type application/x-font-truetype) (see ISO/IEC > 14496-22 Open Font Format > ) > is also recommended. > Security, licensing, and copyright/usage permissions are handled via the > exposure of a font file itself. > Support for the *autoRefresh*, *autoRefreshTimeLimit*, and *load* fields is > optional. > More details on the *autoRefresh*, *autoRefreshTimeLimit*, *description*, > *load*, and *url* fields are contained in 9.2.1 URLs, URNs and URIs > > . > Looking it over, adding more functionality to FontStyle node seems to be > unwise. Dick has an excellent proposal: > TODO alternative approach: move all new functionality into a separate > *FontLibrary* node to avoid complicating FontStyle further. This also > offers the ability to succinctly load multiple font libraries in a given > scene. The expense of defining a new node for X3D is offset by clearer > distinction between X3D 4.0 and 4.1, also simplifying model content > significantly. > Feedback is welcome. > Leaving existing FontStyle implementations alone probably avoids many > unintended side effects. First law of engineering: "If it ain't broke, > don't fix it." > > Thanks for all review. It feels like we are finally converging on a > straightforward approach to valuable future capabilities. > > Have fun with X3D fonts! ? > > > 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 > https://faculty.nps.edu/brutzman > > > > ------------------------------ > *From:* Brutzman, Donald (Don) (CIV) > *Sent:* Monday, February 24, 2025 9:32 AM > *To:* X3D > *Cc:* Holger Seelig > *Subject:* Re: [x3d-public] Open dyslexic and/or (unfortunately) > comicsans fonts; draft X3D 4.1 prose for font files and libraries > > Wow, really super Holger! ? > > There was a conversation about this on x3d-public a few years back... We > committed to adding it in X3D 4.1 and (if I recall correctly) also noted > that adding a url field might enable usage of larger font files. > > I've attempted to capture this candidate specification change in a Mantis > issue. All review, feedback, and improvements are always welcome. > > - Mantis 1490 FontStyle handling of font files and font libraries > - https://mantis.web3d.org/view.php?id=1490 > > Description. > A goal for X3D 4.1 is use of font files in FontStyle (see Mantis 0001464 > ). > > Addition of individual-font files might be accomplished by listing the > font file name in the FontStyle 'family' field. > > Referencing different fonts in a single combined font library file may > require an additional field, for example 'url'. In general the use of a > font library may be preferred, but repeatedly run-time retrieval of a font > library is not desirable, since the file might be quite large and rarely > changing. This might be noted in the specification prose, e.g. > > - "MFString [in,out] url [] [URI]" > - "The family field may list a specific font file. A font listed in the > family field may be provided by a corresponding font library." > - "The url field may refer to a font library. Font libraries can be used > by multiple FontStyle nodes in a scene and need only be loaded once per > session." > > Support levels: add "Level 2, FontStyle, support for font files in family > field and support for font libraries via url field ." > > Security, licensing, and copyright/usage issues are handled via the > exposure of the font file itself. If retrievable (locally or online) then > proper access is presumably handled separately. > > Additional information. > - X3D 4.1 (draft) Architecture, 15 Text component, 15.4.1 FontStyle > - > https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/text.html#FontStyle > > - X3D 4.1 (draft) Architecture, 15 Text component, 15.4.2 Text > - > https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/text.html#Text > > - X3D 4.1 (draft) Architecture, 15 Text component, 15.5 Support levels > - > https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/text.html#SupportlLevels > > Have fun with X3D Text! :) > > > 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 > https://faculty.nps.edu/brutzman > > > > ------------------------------ > *From:* x3d-public on behalf of Holger > Seelig via x3d-public > *Sent:* Monday, February 24, 2025 2:48 AM > *To:* X3D > *Cc:* Holger Seelig > *Subject:* Re: [x3d-public] Open dyslexic and/or (unfortunately) > comicsans fonts > > With X_ITE you can use a URL in the family field of a FontStyle node to > specify a path to a custom font file. Provided you have one of these fonts, > it should be very easy: > > > https://www.web3d.org/specifications/x3d-4.0.dtd"> > > > > > > > > > > > string='"3D Text"'> > family='"path/to/your/font.otf", "SERIF"'/> > > > > > > > Supported File Formats: > > https://create3000.github.io/x_ite/components/text/fontstyle/#supported-file-formats > > Best regards, > Holger > > -- > Holger Seelig > Leipzig, Germany > > holger.seelig at yahoo.de > https://create3000.github.io/x_ite/ > > Am 24.02.2025 um 11:09 schrieb John Carlson via x3d-public < > x3d-public at web3d.org>: > > If someone knows how change the fonts of the standards to OpenDyslexic or > ComicSans, that might be a great accessibility experiment. > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > > > _______________________________________________ > x3d-public mailing list > x3d-public at web3d.org > http://web3d.org/mailman/listinfo/x3d-public_web3d.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: