[x3d-public] JoeSkinTexcoordDisplacerKick example issue validation "fix" (oops?) plus resolution requirements for IFS and Sphere

John Carlson yottzumm at gmail.com
Sat Aug 11 00:30:02 PDT 2018


I am not sure, but validation may be “failing” due to: the desire for scripts providing the indices (and coordinates), a request that I made for IFS coord indexes.  The validation “fix” may have spilled over to other indices.  This is not exactly what I call declarative, so perhaps my request should be backed out?

Is there a desire for various standardized IFS, such as a grid, grid of triangles, etc, where the indices may be generated through a script? Does someone have PROTOs like this?   These could be useful for 3D data visualization.

Note: I’ve mostly solved this by using spheres and vertex shaders, but I have a desire to manipulate the sphere generating code to increase “resolution” (yes I know of X3DOM has a way of doing this…how about a standard?).

Yes, I know I can generate a sphere in Blender and export to X3D. I believe I exported a sphere to FBX for PlayCanvas.

Changing resolution of a sphere on the fly through ROUTEs would be a feature I’d like to see in the future.  Perhaps X3DOM already has it?

Now you know why generating a sphere in advance is not the solution I want.

Ideally, I’d like to see that my surface is cut in half due to resolution, and quadruple the resolution to provide the whole surface on the fly. (quadruple the coordinate space).


John

Sent from Mail for Windows 10

From: Joseph D Williams
Sent: Saturday, August 11, 2018 1:33 AM
To: Andreas Plesch; X3D Graphics public mailing list
Subject: Re: [x3d-public] JoeSkinTexcoordDisplacerKick example issue

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
Sent: Wednesday, August 8, 2018 2:25 PM
To: X3D Graphics public mailing list
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/ba1ea85b/attachment-0001.html>


More information about the x3d-public mailing list