[X3D-Public] Announcement: view3dscene 3.8.0

[Joe D Williams]

Thanks, Yvonne. Those tears are mine if texture mapping to the 
animated deformable skin is difficult or uncertain. Again, I don't 
care whether default mapping is appropriate, just that it seems 
obvious that the texture should move with the skin. I was thinking 
that the default mapping would be handled the same as is I had 
actually defined an initial texture mapping.

Just so I can figure out what to try, Do I have to give a different 
texcorrd set for every frame, or will the initial mapping bind to 
specific vertices and remain bound as the skin is deformed?

Again, my best references for how this should work is BSContact who 
worked long and hard on this and Tony Parisi with Flux and of course 
Keith Victor. I was thinking that just because the texcords were 
default box that was ok and they would be bound and treated the same 
as if I had actually specified them.

So right, this is a simple experiment, but it should give me a good 
clue about how it is supposed to work and now seems like I might be 
confused.

Thanks and Best Regards,
Joe


----- Original Message ----- 
From: "Yvonne Jung" <yvonne.jung at igd.fraunhofer.de>
To: "Michalis Kamburelis" <michalis.kambi at gmail.com>
Cc: "Joe D Williams" <joedwil at earthlink.net>; "x3d-public" 
<x3d-public at web3d.org>
Sent: Friday, January 07, 2011 12:47 PM
Subject: Re: [X3D-Public] Announcement: view3dscene 3.8.0


>
> Am Fr, 7.01.2011, 21:27, schrieb Michalis Kamburelis:
>> Joe D Williams wrote:
>>> 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.
>>
>> Ah, after reading this and seeing the screenshot, I understand the
>> problem. You want the texture mapping to stay stuck. But it's not 
>> how it
>> works, at least in view3dscene and InstantReality (so I'm not the 
>> only
>> one who implemented it this way :) I'd say this looks more like a 
>> bug in
>> BS Contact (possibly they calculate and store the tex coords in 
>> CPU, and
>> do it only once). The spec isn't clear about this, but I would say 
>> that
>> view3dscene and InstantReality behavior is more natural here. For 
>> tex
>> coord generation, you want the shape to "swim" through the texture. 
>> If
>> you want the texture to stay stuck, then assign explicit texture 
>> coords.
>
> I absolutely agree...
> But anyway, even so the spec is unclear here: applying a default 
> boxmapping to
> a deformable and animated (character) mesh might be only useful for 
> debugging
> purposes, if at all.
>
>>
>> In my previous answer, I thought that you're aware that geometry 
>> "swims"
>> through the shape, and you only want the determination which axis 
>> is
>> largest / 2nd largest, for the sake of automatic texture mapping on
>> IndexedFaceSet, to be done only once. Looking at InstantReality, 
>> they
>> seem to do it like that, so I also changed view3dscene to follow 
>> it. You
>
> Yes, that's true.
>
>> can grab view3dscene binary from nightly builds
>> (http://michalis.ii.uni.wroc.pl/vrmlengine-snapshots/ ) and replace 
>> with
>> it the binary inside released view3dscene 3.8.0, to test :)
>>
>> So the texture mapping on your JoeH-AnimKick0a.x3dv in view3dscene
>> behaves exactly like in InstantReality at least.
>>
>>> 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.
>
> For tears, I recommend the great ;-) DropletFlowAppearance:
> http://doc.instantreality.org/documentation/nodetype/DropletFlowAppearance/
>
> Yvonne
>
>>
>> I wasn't suggesting anything too involved. Simply
>>
>>   texCoord TextureCoordinateGenerator { mode "COORD" }
>>
>> inside IndexedFaceSet and
>>
>>     textureTransform TextureTransform { rotation 1.57 }
>>
>> inside Appearance give the similar effect as the default mapping.
>> However, the object "swims" through the texture --- I understand 
>> now
>> that this is not what you want.
>>
>> Hm, so my only advice is: you have to use explicit texture coords 
>> to get
>> the result you desire. At least view3dscene and InstantReality 
>> require
>> it. I tried testing with other browsers: xj3d maps the texture in 
>> some
>> other different way (incompatible with both BS Contact and 
>> view3dscene /
>> InstantReality results) and FreeWRL doesn't animate humanoid at 
>> all.
>>
>> Michalis
>>
>> _______________________________________________
>> X3D-Public mailing list
>> X3D-Public at web3d.org
>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>
>