[X3D-Public] Announcement: view3dscene 3.8.0

[Joe D Williams]

resent with smaller attachment

OK, Michelis, Thanks for the response.
I think I understand what you said.
I have depended upon default texture mapping and also depended that
the texture pixel stayed stuck to the same vertex when the mesh is
moved under control of the joint or parent(s). I didn't think the
mapping would be recomputed each frame, and that the initial mapping
would stick until I actually changed it.

This is the behavior I got from BSContact and Flux, so I didn't think
any more about it. I thought about how, for instance, if I had used a
shape attached to a segment then of course the texture would stay
stuck as the segment is moved, so yeah to me it seemed like the
texture applied to the deformable mesh skin would do the same thing -
stay stuck to the initial vertex with animation.

Of course I have seen enough of this to think that of course competent
authors will do very careful texture mapping and may even use the fact
that the initial mapping and other appearance can be changed at any
time. But, I also liked the way the default mapping stuck just because
it was easy to get something up there that seemed to work.

Overall, I like the way BSContact works because I really don't need to
know much about texture mapping to get something up there that showed
how stuff could work with the hanim deformable mesh skin when animated
by joint rotation and displacement.
Plainly, I did not expect that the texture pixel would be remapped
from the initial vertex each time the mesh vertex positions changed.
Further, I was thinking that once I knew where the texture would land
initially, then I could just create a texture that worked according to
that default mapping. BSContact and Flux backed me up in that by doing
lighting and all every frame and not messing with the original default
texture mapping.

The idea of me attempting a texture transform to try and chase the
mesh around did not even enter my plans, ever, except for more
realistic multitexture/lights/reflections/refractions/raytracing
advanced stuff and even shaders, like for real tears.

> Specification says that automatic texture mapping on IndexedFaceSet
> depends on the local bounding box, so if this box size changes - it
> seems natural that texture mapping may also change.

Well, to me it seemed more natural that it stayed stuck to the initial
binding rather than changing every frame. For instance I would expect
that the skin vertex to joint binding(s) are consistent frame to
frame, and they are. Historically, both BS and Flux did what I
'expected' the first time I actually got something working so they had
converged upon this behavior even before I became interested.

However I also see I took the 'easy' way of making the skin a single
mesh using a single IFS. I am sure more advanced skins can and would
consist of several integrated meshes of various types and possibly
multiple textures even with dynamic mapping. In this part of hanim,
the important connections are mappings between mesh vertex, texute
pixel, and joint rotation/displacement.
However, I can also see that an advanced 'skin' may consist of several
individual shapes that comprise the skin mesh bound to joint(s). As
long as the index is sequential in the user code, that shall work.

> That said, if everyone agrees that IndexedFaceSet specification
> about automatic texture mapping should be interpreted as "automatic
> texture coordinates depend on initial IndexedFaceSet bounding box,
> and do not change later", it's easy to fix view3dscene for it too :)

That gets my vote!
I think BSContact works that way but I may just be looking at one
special case.
To me this is the same answer I would give if asked what happens with
HAnim Displacers.
Like with the initial skin/joint bindings, please use initial
vertex/texture bindings until I make a change.

Thanks Again and Best Regards,
Joe


http://www.hypermultimedia.com/x3d/JoeX3D/JoeH-AnimKick0a.x3dv



----- Original Message ----- 
From: "Michalis Kamburelis" <michalis.kambi at gmail.com>
To: "Joe D Williams" <joedwil at earthlink.net>
Cc: "x3d-public" <x3d-public at web3d.org>
Sent: Thursday, January 06, 2011 7:55 PM
Subject: Re: [X3D-Public] Announcement: view3dscene 3.8.0


> Joe D Williams wrote:
>> The biggest feature question to me for view3dscene is did the
>> texture
>> get attached and actually stay attached to the correct skin vertex
>> as
>> the figure moves? So far only BSContact and Flux (before VIvaty)
>> did
>> that comepletely right for the deformable skin.
>
> Unfortunately, the texture changed, since different axis of the box
> became the largest. It's not difficult to fix it, to match your
> requirements, but I really don't know whether that would be correct.
> Specification says that automatic texture mapping on IndexedFaceSet
> depends on the local bounding box, so if this box size changes -> it
> seems natural that texture mapping may also change.
>
> If you want to map a texture more reliably, use explicit texture
> coordinates, or try appropriate TextureCoordinateGenerator (with
> eventual TextureTransform).
>
> That said, if everyone agrees that IndexedFaceSet specification
> about
> automatic texture mapping should be interpreted as "automatic
> texture
> coordinates depend on initial IndexedFaceSet bounding box, and do
> not
> change later", it's easy to fix view3dscene for it too :)
>
> Michalis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kick.png
Type: image/png
Size: 34759 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20110107/30573d14/attachment-0001.png>