[x3d-public] JoeSkinTexcoordDisplacerKick example issue

Sat Aug 11 03:04:22 PDT 2018

It is all or nothing. TexCoords are only autogenerated if none are
provided. Otherwise, all texCoords shall be provided.

Here is the relevant IFS spec. section:

If the texCoord field is not NULL, it shall contain a node derived
fromX3DTextureCoordinateNode. The texture coordinates in that node are
applied to the vertices of the IndexedFaceSet as follows:

   1. If the texCoordIndex field is not empty, then it is used to choose
   texture coordinates for each vertex of the IndexedFaceSet in exactly the
   same manner that the coordIndex field is used to choose coordinates for
   each vertex from the Coordinate node. ThetexCoordIndex field shall contain
   at least as many indices as the coordIndex field, and shall contain
   end-of-face markers (−1) in exactly the same places as the coordIndexfield.
   If the greatest index in thetexCoordIndex field is N, then there shall be
   N+1 texture coordinates in theX3DTextureCoordinateNode.
   2. If the texCoordIndex field is empty, then thecoordIndex array is used
   to choose texture coordinates from theX3DTextureCoordinateNode node. If the
   greatest index in the coordIndex field is N, then there shall be N+1
   texture coordinates in the X3DTextureCoordinateNode node.

If the texCoord field is NULL, a default texture coordinate mapping is
calculated using the local coordinate system bounding box of the shape.
-- AP on the road

On Sat, Aug 11, 2018, 1:33 AM Joseph D Williams <joedwil at earthlink.net>
wrote:

> >> since the spec. is unambiguous.
>
>
>
> I must check soon, but are you saying that for the IFS,  missing texture
> coordinatete field is not generated auto if not included? I will look, but
> that is what it used to state.
>
>
>
> Thanks,
>
> Joe
>
>
>
>
>
> From: Andreas Plesch <andreasplesch at gmail.com>
> Sent: Friday, August 10, 2018 8:04 PM
> To: Joe D Williams <joedwil at earthlink.net>
> Cc: X3D Graphics public mailing list <x3d-public at web3d.org>
> Subject: Re: [x3d-public] JoeSkinTexcoordDisplacerKick example issue
>
>
>
> Thanks for your nice remarks.
>
>
>
> Unfortunately, currently x3dom chokes on the missing texture coordinates
> and does not gracefully degrade. I agree that it rather should and a small
> modulo operation patch in the right place might suffice.
>
>
>
> But the X3D examples archive is usually strict in only offering fully
> conforming scenes. As such I think the kicker will have to have the full
> set of texture coordinates, redundant as they may seem, in order to avoid
> these kinds of garbage in, garbage out situations.
>
>
>
> As I understand it, validation should fail in this case since the spec. is
> unambiguous. The actual validators probably currently do not cover this
> situation, however.
>
> -- AP on the road
>
>
>
> On Fri, Aug 10, 2018, 9:53 PM Joseph D Williams <joedwil at earthlink.net>
> wrote:
>
> Great, I really like your comments that and will have another look.
>
> The main ideas are that I think automagic generation of empty
> texCoordIndex for all IndexedFaceSet nodes.
>
> I don’t see any reason to disallow this for hanim. Sure, it may be very
> unusual if possible at all to make sense of any humanoid textures from a
> default set of coordinates but it should be allowed as in the rest of x3d.
> Not tried them all now, but I have only found one browser that would not
> accept the input and not provide a consistent autogen. As for the
> TextureCoordinate set, that always seemed to work as a way of limiting use
> of the supplied texture to a certain area, and of course if I only give it
> one set, or just a few, I want them duplicated by default. I will look
> again but I don’t see why I should need more than the supplied number of
> values to use a part of the supplied texture to be used for the thing.
> There are several other fields, like color per vertex, where if you give
> one set, or eve just a few sets, they get recycled in sequence. The
> texturetransform seems to work ok without more detail. It shuld try to use
> what you give it. In this case, an advisory that the single value is being
> reused, as any author might expect to be the default friendly way. In the
> same example, ball_Shape does not need all that extra stuff – it is an ifs,
> so I get the default texturing for free as expected.
>
>
>
> OF course all this is different if I choose another geometry for the skin
> instead of the ifs, then I gotta worry about all that stuff lining up
> because the browser does not figure it for you. I will check the spec again
> for these details.
>
>
>
> Thanks, Andreas, for looking at the kicker - glad you can do the skin.
> That joint-skin binding is hard, but the texture-geometry binding … harder?
>
>
>
> I think x3d should be very accepting, for simple stuff, like I showed.
> Learning the skeleton structure, animating the skeleton, using segment
> geometry, using skin geometry, skeleton-skin bindings and weights,
> texture-geometry bindings, hanim displacers, and all great reasons to say
> that learning x3d hanim will not be a waste of time to anyone who wants to
> see what is actually making the model animation happen. And of course we
> need to get some advanced texturing and animation features onto the mix.
>
>
>
> Thanks again, the x3d xml user code you set up is fine and runs fine where
> I have tested it.
>
>
>
> >> The intention may be that the texture coordinates are recycled as it
>
> is possible with some other fields. However, validation should fail if
>
> it included checking for this requirement.
>
>
>
> Yes, that is the intent. Anyway, please. IFS have special cases for these
> fields. Not like other geometries. Missing this stuff is not failing, but
> since the intent is recycling, if the validator catches that,  then, for
> ifs, it should be warning, not failure, if possible. After all, without the
> stuff, for ifs, it runs everywhere the spec is followed.
>
>
>
> All Best,
>
> Joe
>
>
>
>
>
> From: Andreas Plesch <andreasplesch at gmail.com>
> Sent: Wednesday, August 8, 2018 2:25 PM
> To: X3D Graphics public mailing list <x3d-public at web3d.org>
> Subject: [x3d-public] JoeSkinTexcoordDisplacerKick example issue
>
>
>
>
> http://www.web3d.org/x3d/content/examples/Basic/HumanoidAnimation/JoeSkinTexcoordDisplacerKickIndex.html
>
>
>
> has an excellent example of HAnim animation using many of its features.
>
>
>
> It has a large IndexedFaceSet node which contains the player:
>
>
>
> <IndexedFaceSet DEF='Joe_skin_IndexedFaceSet' ..
>
>
>
> The node has an empty texCoordIndex field and a short texCoord field:
>
>
>
> <TextureCoordinate point='0 0 0.5 0.5 0.5 0 0 0.5'/>
>
>
>
>
> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#IndexedFaceSet
>
>
>
> section g) requires that there are N+1 texture coordinates with N
>
> being the largest index in coordIndex. The largest index in coordIndex
>
> is 389. There are 390-4 texture coordinates missing.
>
>
>
> The intention may be that the texture coordinates are recycled as it
>
> is possible with some other fields. However, validation should fail if
>
> it included checking for this requirement.
>
>
>
> Here is a fixed x3d file:
>
>
>
>
> https://raw.githubusercontent.com/x3dom/x3dom/master/test/functional/hanim/JoeSkinTexcoordDisplacerKickTest.x3d
>
>
>
> -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/20180811/040a717b/attachment-0001.html>