> 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 <yottzumm at gmail.com>
Sent: Feb 5, 2025 10:31 AM
To: Andreas Plesch <andreasplesch at gmail.com>, Holger Seelig <holger.seelig at yahoo.de>, X3D Graphics public mailing list <x3d-public at web3d.org>
Cc: Joe D Williams <joedwil at earthlink.net>
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 <andreasplesch at gmail.com (mailto: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 <yottzumm at gmail.com (mailto:yottzumm at gmail.com)> 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 (mailto: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 (mailto:andreasplesch at gmail.com)> wrote:
Hi John,
On Mon, Feb 3, 2025 at 12:48 AM John Carlson <yottzumm at gmail.com (mailto:yottzumm at gmail.com)> 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: <fieldValue> element references unknown field name "enabled"
castle-model-converter: Warning: X3D: X3D XML: <fieldValue> element references unknown field name "startTime"
castle-model-converter: Warning: X3D: X3D XML: <fieldValue> 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:
<fieldValue name="startTime" />
and others.
On Sun, Feb 2, 2025 at 5:42 AM John Carlson <yottzumm at gmail.com (mailto: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/20250205/8ccf2040/attachment-0001.html>