[x3d-public] Focus on HAnim nodes, not shape geometry.

[John Carlson]

Joe, box is 2x2x2 defaulted, afaik.

I’m thinking of providing a function like

HAnimHumanoid.applyTransform(Transform) to SAI.  I haven’t figured which
SAI yet.   The scale in the Transform will change the scale of the Humanoid
to 1.87, 1.87, 1.87.  The translation in the Humanoid will bring the origin
and centers such that the origin is between the feet.

How i will change the other transforms and shapes, I don’t quite understand
yet.   We tried something that didn’t work.   I understand that you want to
get rid of defaulted transforms, and there are defaulted transforms for
HAnim named nodes found in X3DUOM.

What i think this means is i will have to pull all the HAnim default
measurements from X3DUOM, HAnim 2.0 standard, or some other source, like
x3d.py or X3DJSAIL, which pull from X3DUOM.  While we have a lot of these
measurements in those places, I think we still need someone to pull out
measurements from either the scene in question (I don’t know if all the
measurements are there, we need to check), another scene, or measure them
ourselves in the standard.

That is, either the data should provide the measurements (particularly
hands and feet), or the standards.

I think your goal of taking the hands and feet measurements out of the
scene is good, we will also need to pull measurements out of the standard,
X3DUOM or SAI that are present, so we can do our multiplication properly,
and the higher nodes must influence lower nodes.

I already have a skeleton which pulls most of the measurements for the
skeleton from the standard via scraped files.

So we can continue using a scene to pull out HAnim measurements, as long as
the measurements are there.

May i suggest that we continue by ignoring shape geometry and focusing on
HAnim nodes?  Once we have defaults for HAnim nodes, we transfer to
standard, X3DUOM, etc.  then we can rescrape, and hopefully create an
appropriate Humanoid.

We have verified that JinLOA4.x3d has all nodes in hierarchy.   The
measurements in JinLOA4.x3d do not yet meet the standard, AFAIK.

Thanks!

John

On Sun, Apr 23, 2023 at 6:18 PM Joseph D Williams <joedwil at earthlink.net>
wrote:

>
>    - Understood, Joe!
>
>
>
> Fine. Are you sure you see how we drew that part of a box? The coordinates
> of the points and how to make triangles?
>
>
>
> There is a default 0 0 0 for the root scene. You are not really supposed
> to draw in this space but recommended to have a Group or Transform to hold
> geometry. If I say Transform defaults, Shape Box defaults then I get a box
> 1x1x1 centered at 0 0 0 in ancestor space so the thing should be hanging
> there around the middle of the scene. For other standard shapes, when the
> user asks for a cone, he will expect standard cone, but a cone that is not
> carefully specced out but will probably consist of about what 20 to 50
> points. If the user wants more detail or less points then it is fairly easy
> diyofs in basic IFS user code.
>
>
>
> Thanks,
>
> Joe
>
>
>
>
>
> *From: *John Carlson <yottzumm at gmail.com>
> *Sent: *Saturday, April 22, 2023 6:35 PM
> *To: *Joseph D Williams <joedwil at earthlink.net>
> *Cc: *GPU Group <gpugroup at gmail.com>; X3D Graphics public mailing list
> <x3d-public at web3d.org>
> *Subject: *Re: [x3d-public] Tessellation…convert to IFS?
>
>
>
> Understood, Joe!  My issue is what do we do with sphere coordinates when
> transforms are multiplied out and deleted?   It would seem natural to
> replace non-coordinate shapes with some kind of shape set, whether indexed
> or not (X3D JSON to STL code does this). Especially something where
> triangles must share edges.  So yes, in the case of Sphere, Box and other
> non-coordinate shapes, the user code should change.
>
>
>
> I think the solution may be to retain lowest level transforms in the scene
> in order to maintain shapes like spheres, cones, cylinders, etc.  in user
> code.   Then, do we need to apply the transforms to geometry?
>
>
>
> Joe,  it seems like you’re leaning towards changing the shape user code to
> sets?  This is getting  more and more like X3D JSON to STL, we just need to
> support different output formats and additional shapes.  Should we
> translate to glTF instead of STL?
>
>
>
> Doug, this is primarily to produce a standardized human model.
>
>
>
> John
>
>
>
> On Sat, Apr 22, 2023 at 7:03 PM Joseph D Williams <joedwil at earthlink.net>
> wrote:
>
>
>
>
>
> Also note there are several ways to represent a shape in x3d. If the name
> includes Indexed then the user code includes the coordinates for the points
> and the sets of coordindex numbers that tell the browser how to make the
> triangles.
>
> Some styles of shapes do not require the user to supply coordIndex, then
> the points are default auto-indexed into triangles by a standardized
>  formula depending on name and included user code for points.
>
>
>
> So, when you say shape Sphere then the browser encodes that depending on
> its internal spec sphere.
>
> You can see the result in a browser that can just show the points or
> triangles of the shape sphere otherwise it will appear as a solid but the
> details of the actual coordinates of points and tessellation (indexing) of
> those points will not appear in the user code because what does the user
> care about what the browser uses to create your Sphere? .
>
>
>
> So, for the default shape Box, probably uses two triangles per side.
>
> I think there is x3d Shape user code to present a box in both indexed and
> auto-indexed form.
>
>
>
> Here is classic-style user code with lots of defaults for one side of a
> box.
>
>
>
> DEF boxfront Shape {
>
>   appearance Appearance {
>
>     material Material { }
>
>     texture ImageTexture {
>
>       url [ "textures/boxfront.jpg" ]
>
>     }
>
>   }
>
>   geometry IndexedFaceSet {
>
>     coordIndex [ 0 1 2 3 -1 ]
>
>     coord Coordinate {
>
>       point [ -1 -1 1, 1 -1 1, 1 1 1, -1 1 1 ]
>
>     }
>
>     texCoordIndex [ 0 1 2 3 -1 ]
>
>     texCoord TextureCoordinate {
>
>       point [ 0 0 1 0 1 1 0 1 ]
>
>     }
>
>   }
>
> }
>
>
>
> Joe
>
>
>
>
>
> *From: *GPU Group <gpugroup at gmail.com>
> *Sent: *Saturday, April 22, 2023 2:33 PM
> *To: *John Carlson <yottzumm at gmail.com>
> *Cc: *X3D Graphics public mailing list <x3d-public at web3d.org>
> *Subject: *Re: [x3d-public] Tessellation…convert to IFS?
>
>
>
> Depends what you're doing. Assuming you're starting with a point cloud, if
> you're tessellating something almost flat, and with irregular points, then
> you can use something like Delaunay algorithm to optimize the edges between
> points to give triangles that are more equi-angular.
>
> If you are on a 3D dimensional surface, but know its close to being convex
> -- like a sphere or cube -- then you can move the planar math around a
> spherical center, and crop points in the distance / on the other side of
> center when triangulating.
>
> Or you can remove and add points from a pre-triangulated sphere (I just
> made this up). Looking orthogonally at an existing triangle on your sphere,
> add a point from your point cloud, to the appropriate triangle, based on
> its yaw and pitch, or latitude, longitude, while ignoring its
> radius/height. When you have all your points added, then start removing the
> sphere's points. After each step of adding (or removing sphere points at
> the end), do Delaunay recursive triangle swaps on the local plane.
>
> Or ask ChatGPT - it might know.
>
> -Doug
>
>
>
> On Sat, Apr 22, 2023 at 3:05 PM John Carlson <yottzumm at gmail.com> wrote:
>
> When one is tessellating a shape, like Box, is it typical to convert to
> IFS?
>
>
>
> Thanks!
>
>
>
> John
>
> _______________________________________________
> 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/20230423/592872eb/attachment.html>