[x3d-public] JoeSkinTexcoordDisplacerKick example issue

Andreas Plesch andreasplesch at gmail.com
Fri Aug 10 20:03:47 PDT 2018


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/20180810/661cd662/attachment.html>


More information about the x3d-public mailing list