[x3d-public] Displacer(s) in FreeWRL
Joseph D Williams
joedwil at earthlink.net
Tue Feb 14 17:17:47 PST 2023
Hey, I am sure happy to find freewrl with HAnimDisplacer(s) working. I thought I had tried that and failed, but I now can control any skin vertex on top of skeleton-driven animations.
So far, using displacer for skin geometry, seems like the Displacer can appear as a child of any Joint anywhere in the skeleton.
Outside the skeleton joint hierarchy it does not operate.
So you can distribute skin displacer(s) around the skeleton or grouped, for instance as child of root Joint. ,
And, any vertex of the skin can be included in any displacer setup and any vertex may be included in more than one displacer. Finally, if multiple operating displacers include the same vertex, then all actions are included in the frame.
<HAnimDisplacer
DEF='Joe_finger_tip_extender_action'
name='finger_tip_extender_action'
coordIndex='173'
displacements='
0 -0.5 0'/>
In this, a single vertex at the tip of the finger is extended -y at up to 0.5 units depending upon the 0 to 1 weight event I send.
Regardless of the current animated position and orientation of the vertex, its coordinate system at default pose is retained. So, since the index finger default pose is pointing straight down, the effect is always to move the vertex along its default pose -y axis. Note that this is exactly what you should expect to happen.
This needs a video because the way it can work is so nice.
Thanks, and now need to see what can happen with Segment and Site geometries.
Joe
From: Joseph D Williams
Sent: Sunday, February 12, 2023 10:45 AM
To: Michalis Kamburelis
Cc: John Carlson; Don Brutzman; GPU Group; X3D Graphics public mailing list
Subject: RE: New description fields and Displacer
First, please get Displacer running. I can’t or haven’t been able to test some others. All I really have is old BS Contact demo
Thank You for fine Hanim, except Displacer:)
Please try to get one working with one segment or site geometry.
The coordIndex is the order of points as appears in the user code.
The Displacer is operating in coordinate space of target geometry of parent Transform.
Humanoid
.Skeleton
..Joint
...Segment
....Geometry
....Displacer
....Site
.....Geometry
.....Displacer
...Joint …
.Skin
..Geometry
..Displacer
(coded as direct child of controlling Joint)
As a simple pattern, since Displacer is not a container and does not carry a reference to the target geometry.
>From that, please insert the Displacer immediately following the target geometry.
If the Displacer is acting upon skin vertices, there is indication that the Displacer should be direct child of Joint with control of all or subset of vertices also controlled by the Joint. That would make the Displacer as allowed child of Joint, an honor otherwise shared only by Segment and Joint.
Somewhere in the past it was set that the Displacer is not a container and does not need a coded reference
to the target geometry. So, each Displacer must be associated with specific vertices
of a particular geometry by its location in the user code.
Thus, it seems reasonable to define that for Segment or Site geometry,
the Displacer should be child in the same coordinate space as the geometry.
Sibling of Segment geometry or Transform holding Segment geometry.
Sibling of Site geometry or Transform holding Site geometry.
Likewise, it seems natural that for skeleton-driven skin animation the
Displacer is used to enhance control of points associated with
a certain Joint, so we want to closely associate a Displacer with a Joint.
Overall, the Displacer is expected to actuate after skeleton-driven animation
for the frame is complete.
HAnimDisplacer : X3DGeometricPropertyNode {
MFInt32 [in,out] coordIndex [] [0,∞) or -1
MFVec3f [in,out] displacements []
SFNode [in,out] metadata NULL [X3DMetadataObject]
SFString [in,out] name ""
SFFloat [in,out] weight 0.0 [0,∞)
}
So, you supply index of the vertex you wish to displace
and the maximum displacement along a 3D vector you wish to move it.
Then when you wish to move it, you send the Displacer a weight event, float 0 to 1.
If the new weight is 0 then nothing is added.
If the weight is 1, then the vertex is moved the full displacement along the 3D vector.
Of course this is eversoslightlycomplicated by the fact that displacements are
3D vectors relative to the specified vertex in default pose coordinate space
of the target geometry.
As an example, here is the JoeKick example simplified to one vertex,
the skull apex point.
<HAnimDisplacer
DEF='Joe_skull_tip_raiser_action'
name='skull_tip_raiser_action'
coordIndex='0'
displacements='0 0.15 0' />
This displacements value says create a 3D vector
from 0 0 0 at the current vertex location to 0 0.15 0.
Move that vertex along that Y-axis vector 0 to 100 percent,
depending upon the 0 to 1 floating point weight event
I will send. The reference coordinate system of the
vertex in the default position is retained even if the
vertex has been moved by other actions.
Of course this is eversoslightly complicated by
the fact that the each displacement is actually a 3D vector.
The 0 0 0 base and 0 0 1 0 orientation is relative to the
default pose and is retained for displacer animation.
Wait, do I need to consider vertex coordinate space and orientation of a vertex?
Well, Yes, but just like Joint nodes, We will best be served when we understand the default, before animation pose and the default orientation of each item we wish to animate. So, for Joint nodes of the skeleton we orient the Joint to transform default, meaning if you are sitting on the Joint, then +Y is Up and left is +x, and you are facing +z. Regardless of how the parent joint is animated, the child joint retains its reference orientation.
So, yes, you navigate 3D space the same for Joint(s) and vertices controlled by Displacer.
Now, when I send 'Joe_skull_tip_raiser_action' the weight event,
the vertex 0 of the geometry will be moved along the 3D vector
defined by the displacements value.
Notice that if, for instance the vertex has been moved due to skeleton animation,
the displacement will be as expected because the vertex remembers its default orientation.
About placement of the ROUTE statement. Expected something got something else.
I thought we agreed that the grammar shows ROUTE can be free and as a field in a node.
So, I still get those errors where you tell me my node markup is wrong.
Thanks, Again,
Joe
From: Michalis Kamburelis
Sent: Thursday, February 9, 2023 2:48 PM
To: Joseph D Williams
Cc: John Carlson; Don Brutzman; GPU Group; X3D Graphics public mailing list
Subject: Re: New description fields
1.
> Just reuse the last set on the list to fill out the list.
> What is so bad about that?
> Do you fail if not enough colors?
Reusing the last value of a per-vertex attribute (like texture
coordinate) would be a bit useless, at least in most cases.
Yes, we also throw a warning when there are not enough colors.
This is also following X3D specification, see e.g. IndexedFaceSet:
https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD/Part01/components/geometry3D.html#IndexedFaceSet
"""
If the greatest index in the coordIndex field is N, the Coordinate
node shall contain N+1 coordinates (indexed as 0 to N).
...
If the greatest index in the colorIndex field is N, then there shall
be N+1 colours in the X3DColorNode node.
...
If the greatest index in the texCoordIndex field is N, then there
shall be N+1 texture coordinates in the X3DTextureCoordinateNode.
...
If the texCoordIndex field is empty, then the coordIndex array is used
to choose texture coordinates from the X3DTextureCoordinateNode node.
If the greatest index in the coordIndex field is N, then there shall
be N+1 texture coordinates in the X3DTextureCoordinateNode node.
"""
All these sentences say a similar thing: if you provide a per-vertex
data, we expect you to provide as much data as you want to index.
Adding a processing on browser side to "reuse the last data" would be
extra work, not necessary in many cases, and it is actually better in
many cases to throw an error in this case. It is better to consider
this "not valid file".
Note that view3dscene still displays the mesh, this is just a warning.
It's not an X3D invention either. glTF, Collada follow this too.
If you want to just reuse the last coordinate, then I guess duplicate
it in TextureCoordinate. But is this really what you want? You want to
have 3 vertexes with texture coordinates like this:
- 0 0
- 0.5 0.5
- 0.5 0
... and then 300+ vertexes with equal texture coordinate 0 0.5 ? This
seems a bit weird texture mapping. If most of vertexes have the same
texture coordinate then most faces will just display a single color
from the texture. This would be valid but rather non-standard use of
textures.
2. HAnimDisplacer is indeed simply not implemented in
view3dscene/Castle Game Engine for now.
3. As for routes, you mention """Also, the item about the route
statements being in a place you don’t like did not get fixed in
4.3.0.""" -- sorry, I do not recall the issue. But I have too many
TODO lists, maybe something slipped my mind. Please refresh my memory,
point me to the thread or bugreport about it.
Regards,
Michalis
czw., 9 lut 2023 o 19:44 Joseph D Williams <joedwil at earthlink.net> napisał(a):
>
> Otherwise X3D browser doesn't know what do you mean --
>
> what texture coordinate is supposed to be associated with vertex with
>
> index 9.
>
>
>
> Yes it does, or it should. Just reuse the last set on the list to fill out the list.
>
> What is so bad about that?
>
> Do you fail if not enough colors?
>
>
>
> Anyway, the Displacer is not working in 4.3.0 with no errors on that.
>
>
>
> https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Skin/JoeKickIndex.html
>
>
>
> Also, the item about the route statements being in a place you don’t like did not get fixed in 4.3.0.
>
>
>
> Can you or someone please help me with <TextureCoordinate point='0 0 0.5 0.5 0.5 0 0 0.5'/> since I an’t seem to get the right number for happiness even when it seems right and works elsewhere.
>
>
>
> X3D: Invalid number of items in a normal or texture coordinate array for shape "Joe_Humanoid:Joe_Kick:Joe_Shape:IndexedFaceSet(Joe_skin_IndexedFaceSet)": Invalid index: 141, but we have 139 items
>
>
>
>
>
> Even when the numbers match at the correct numver ofverts it fails.
>
> Is this finding something in the texture transform?
>
>
>
> Sure would like to see Displacer working.
>
> Thanks,
>
> Joe
>
>
>
>
>
>
>
> From: Michalis Kamburelis
> Sent: Thursday, February 9, 2023 7:30 AM
> To: Joseph D Williams
> Cc: John Carlson; Don Brutzman; GPU Group; X3D Graphics public mailing list
> Subject: Re: New description fields
>
>
>
> Yes :) I know we had a few communications about this already, so maybe
>
> you already fixed it in some version of the file and it is just not
>
> updated on that page.
>
>
>
> I just report that
>
>
>
> http://www.web3d.org/x3d/content/examples/HumanoidAnimation/Skin/JoeKick.x3d
>
>
>
> still has this error. Specifically, it contains geometry like this:
>
>
>
> <IndexedFaceSet DEF='Joe_skin_IndexedFaceSet' coordIndex='0
>
> 9 5 -1 0 7 9 ...' creaseAngle='3.14'>
>
> <Coordinate DEF='Joe_SkinCoord' point='0.0 1.77 ..../>
>
> <TextureCoordinate point='0 0 0.5 0.5 0.5 0 0 0.5'/>
>
> </IndexedFaceSet>
>
>
>
> So you use coordinate index "9" (and larger, later, like 386) ... but
>
> your "TextureCoordinate.point" has only 4 items. So you can only use
>
> indexes 0..3. Otherwise X3D browser doesn't know what do you mean --
>
> what texture coordinate is supposed to be associated with vertex with
>
> index 9.
>
>
>
> Regards,
>
> Michalis
>
>
>
> czw., 9 lut 2023 o 14:48 Joseph D Williams <joedwil at earthlink.net> napisał(a):
>
> >
>
> > > X3D: Invalid number of items in an attribute array for shape
>
> >
>
> > > "Joe_Humanoid/Joe_Kick/Joe_Shape/IndexedFaceSet(Joe_skin_IndexedFaceSet)":
>
> >
>
> > > Invalid index: 9, but we have 4 items in 2D texture coordinates
>
> >
>
> > >
>
> >
>
> > > ... and the error is valid from what I can see. TextureCoordinate has
>
> >
>
> > > too few points.
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > Is this back to telling me I have to have all texcoords for all points?
>
> >
>
> >
>
> >
>
> > Thanks,
>
> >
>
> > Joe
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > From: Michalis Kamburelis
>
> > Sent: Thursday, February 9, 2023 5:23 AM
>
> > To: John Carlson
>
> > Cc: Don Brutzman; GPU Group; Joe D Williams; X3D Graphics public mailing list
>
> > Subject: Re: New description fields
>
> >
>
> >
>
> >
>
> > To other X3D browser implementors adding "description":
>
> >
>
> >
>
> >
>
> > If you also have been implementing RenderedTexture node (not in X3D
>
> >
>
> > spec, but common extension, at least in InstantReality, Xj3d, and
>
> >
>
> > CGE/view3dscene), note that you should remove the
>
> >
>
> > "RenderedTexture.description" field. It can (and should) now inherit
>
> >
>
> > "X3DSingleTextureNode.description".
>
> >
>
> >
>
> >
>
> > Sometimes automatic tests catch real errors :) (This nuance was caught
>
> >
>
> > by CGE automatic tests.)
>
> >
>
> >
>
> >
>
> > Regards,
>
> >
>
> > Michalis
>
> >
>
> >
>
> >
>
> > czw., 9 lut 2023 o 14:04 Michalis Kamburelis
>
> >
>
> > <michalis.kambi at gmail.com> napisał(a):
>
> >
>
> > >
>
> >
>
> > > I added to view3dscene/Castle Game Engine handling of "description" field on
>
> >
>
> > >
>
> >
>
> > > - X3DSingleTextureNode
>
> >
>
> > > - HAnimDisplacer
>
> >
>
> > > - HAnimHumanoid
>
> >
>
> > > - HAnimJoint
>
> >
>
> > > - HAnimSegment
>
> >
>
> > > - HAnimSite
>
> >
>
> > >
>
> >
>
> > > I also added HAnimHumanoid.loa .
>
> >
>
> > >
>
> >
>
> > > As usual, the fix will be available in snapshot view3dscene versions
>
> >
>
> > > on https://castle-engine.io/view3dscene.php (also part of larger CGE
>
> >
>
> > > download, https://castle-engine.io/download ). Please give Jenkins a
>
> >
>
> > > 6-8 hours to process it and run all automated tests.
>
> >
>
> > >
>
> >
>
> > > Note that these "description" fields seem unrelated to
>
> >
>
> > > http://www.web3d.org/x3d/content/examples/HumanoidAnimation/Skin/JoeKick.x3d
>
> >
>
> > > . That file only used "description" on Viewpoint, which we already
>
> >
>
> > > handled.
>
> >
>
> > >
>
> >
>
> > > After adding "HAnimHumanoid.loa", this file reports just this error
>
> >
>
> > > (many times) in view3dscene:
>
> >
>
> > >
>
> >
>
> > > X3D: Invalid number of items in an attribute array for shape
>
> >
>
> > > "Joe_Humanoid/Joe_Kick/Joe_Shape/IndexedFaceSet(Joe_skin_IndexedFaceSet)":
>
> >
>
> > > Invalid index: 9, but we have 4 items in 2D texture coordinates
>
> >
>
> > >
>
> >
>
> > > ... and the error is valid from what I can see. TextureCoordinate has
>
> >
>
> > > too few points.
>
> >
>
> > >
>
> >
>
> > > Regards,
>
> >
>
> > > Michalis
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > śr., 8 lut 2023 o 03:45 John Carlson <yottzumm at gmail.com> napisał(a):
>
> >
>
> > > >
>
> >
>
> > > > I'm trying to collect information into one message. Michalis, please check view3dscene 4.3, I believe ImageTexture and HAnimDisplacer were missing description field in view3dscene 4.2 and 4.3. See links below for X3D4 tooltips specifics. The issue with view3dscene stems from adding a description fields in X3D4 using X3D-Edit (for the most part). There are also schema issues with the file in question (JohnJoint18.x3d).
>
> >
>
> > > >
>
> >
>
> > > >
>
> >
>
> > > > I’ll double check the tooltips while I am at it.
>
> >
>
> > > >
>
> >
>
> > > > https://www.web3d.org/x3d/content/X3dTooltips.html#ImageTexture.description
>
> >
>
> > > >
>
> >
>
> > > > (Yellow)
>
> >
>
> > > >
>
> >
>
> > > > https://www.web3d.org/x3d/content/X3dTooltips.html#HAnimDisplacer.description
>
> >
>
> > > >
>
> >
>
> > > > (Yellow)
>
> >
>
> > > >
>
> >
>
> > > > If there are examples of HAnimDisplacer in the community, consider donating them to our testing effort.
>
> >
>
> > > >
>
> >
>
> > > > The good news is we have one good HAnimDisplacer node from www.web3d.org/x3d/content/examples/HumanoidAnimation/Skin/JoeKick.x3d (in the file system on the x3d project our sourceforge). Michalis, Joe, the issue is that view3dscene throws all kinds of issues with the file.
>
> >
>
> > > >
>
> >
>
> > > > I was able to add the HAnimDisplacer in JoeKick to my JohnJoint18.x3d and not increase the number of errors reported by view3dscene (HAnimDisplacer without description seems to be working).
>
> >
>
> > > >
>
> >
>
> > > > Thanks!
>
> >
>
> > > >
>
> >
>
> > > > John
>
> >
>
> > > >
>
> >
>
> > > >
>
> >
>
> > > > On Tue, Feb 7, 2023 at 2:18 PM GPU Group <gpugroup at gmail.com> wrote:
>
> >
>
> > > >>
>
> >
>
> > > >> No. I'm finished with that project, its somewhere in web3d. I think I referred to tooltips, which has v4 added fields in yellow.
>
> >
>
> > > >> -Doug
>
> >
>
> > > >>
>
> >
>
> > > >>
>
> >
>
> > > >> On Tue, Feb 7, 2023 at 12:40 PM John Carlson <yottzumm at gmail.com> wrote:
>
> >
>
> > > >>>
>
> >
>
> > > >>> Doug,
>
> >
>
> > > >>>
>
> >
>
> > > >>> could you add nodes which have a new description field to your browser builder guide?
>
> >
>
> > > >>>
>
> >
>
> > > >>> Thanks!
>
> >
>
> > > >>>
>
> >
>
> > > >>> John and Don
>
> >
>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20230214/17f5e3c9/attachment.html>
More information about the x3d-public
mailing list