[x3d-public] Projective Texture Mapping PTM node definitions
Don Brutzman
brutzman at nps.edu
Wed Oct 7 09:09:48 PDT 2020
Thank you Michalis. Please make and push the change to the specification. Dick and I will be working on those clauses again in about 24 hours.
On 10/6/2020 4:04 PM, Michalis Kamburelis wrote:
>
>
> I will not be able to attend this Friday, but I can next Friday.
>
> PTM should be reflected in the lighting equations on
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/lighting.html
> . Clearly showing how the equation looks (where does PTM "plug" into
> the existing equations) would make it clear how the PTM should be
> implemented. From what you say, PTM would act as an additional light
> source, whose "color" is derived from the projected texture (instead
> of being constant "X3DLightNode.color").
>
> I'm happy to work to encode this in spec :) But I would like a
> confirmation / test that indeed it is implemented like this in X_ITE,
> that (as far as I understand) already implements this part of X3Dv4
> spec.
>
> And I just saw that I made an important omission in my updated
> lighting equations on
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/lighting.html#LightingCommon
> : I forgot to include in the lightContribution_i factor the
> "lightSource.color * ..." factor. That's just my stupid human error :)
> So this should be updated to say
>
> - lightContribution_i is multiplied by X3DLightNode.color in case of
> normal lights (to fix my mistake)
> - lightContribution_i is multiplied by texture color in case of PTM
> (to make PTM spec unambiguous)
>
> Regards,
> Michalis
>
>
> wt., 6 paź 2020 o 19:30 Don Brutzman <brutzman at nps.edu> napisał(a):
>>
>> Dick and I worked on this today. First, we allowed a value of -1 (meaning no effect) similar to X3DViewpointNode nearClippingPlane and farClippingPlane.
>>
>> SFFloat [in,out] farDistance -1 -1 or (0,∞)
>> SFFloat [in,out] nearDistance -1 -1 or (0,∞)
>>
>> The nearDistance and farDistance are the minimum and maximum distance traveled, respectively, for a projected texture that is shown on the screen. A default value of -1 for nearDistance or farDistance means that the field has no effect on currently active projection boundaries.
>>
>> We have a TODO: [convert to ClassicVRML syntax] for the excerpted examples, anyone care to provide those?
>>
>> Perhaps Kwan-Hee Yoo, can we have each example model?
>>
>> Today's changes have been pushed to github.
>>
>> On 10/6/2020 12:39 AM, Michalis Kamburelis wrote:
>>>
>>> I recall we talked that the PTM specification needs to address how the
>>> projected texture affects the existing textures.
>>>
>>> You once mentioned that the original PTM proposal contained the text
>>> effectively meaning that "projected texture is like a light source",
>>> but then this text was simplified (maybe too much) for the actual
>>> spec. As an implementor, looking at WD2 of PTM (
>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/ProjectiveTextureMapping.html
>>> ), I don't know how exactly the projected color should be used (at
>>> which point of the lighting equation is it applied).
>>>
>>> My old notion about it is on
>>> https://github.com/michaliskambi/x3d-tests/wiki/Clarify-%22Projective-texturing%22-component
>>> , see the section """TODO: Address how the projective texturing in X3D
>>> 4 spec affects existing textures""". We talked about this issue on the
>>> mailing list and teleconferences :)
>>>
>>> Regards,
>>> Michalis
>>
>> As ever, thanks for your tremendous thoroughness. We took a quick look at these. Now that we have the Shape component and updated lighting/rendering sorted out, it seems we can finally address the concerns.
>>
>> You have best perspective on how PTM might fit into the X3D4 specification. We are thinking that the basic approach is to treat the modification of every pixel affected by a projected texel as similar to any other light source, with the main difference simply being that color of light varies from the PTM light source.
>>
>> Dick thinks that specification probably goes in the PTM component Concepts section. Perhaps additional words and even equation modifications are needed elsewhere in the X3D4 specification.
>>
>> Hoping you can revisit. We can dedicate X3D working group meeting this Friday, or following Friday, to review this topic.
>>
>> Step by step....
>>
>>
>>> wt., 6 paź 2020 o 06:00 Don Brutzman <brutzman at nps.edu> napisał(a):
>>>>
>>>> Found that the PTM nodes had never been put into X3D XML Schema, DOCTYPE or X3DUOM, etc. etc. Working to remedy that.
>>>>
>>>> [1] 42 Projective Texture Mapping (PTM) Component
>>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/ProjectiveTextureMapping.html
>>>>
>>>> Suggest following changes in nodes below:
>>>>
>>>> a. modify farDistance, nearDistance to have bounds of [0,∞)
>>>>
>>>> b. farDistance default of 10m seems like a good value if used in virtual rooms. nevertheless might consider longer default value for farDistance, perhaps 100 (meters) to reduce potential for future author puzzlement.
>>>>
>>>> Anything else?
>>>>
>>>> =============================
>>>> 42.3.1 X3DTextureProjectorNode
>>>>
>>>> X3DTextureProjectorNode : X3DChildNode {
>>>> SFString [in,out] description ""
>>>> SFVec3f [in,out] direction 0 0 1 (-∞,∞)
>>>> SFFloat [in,out] farDistance 10
>>>> SFBool [in,out] global TRUE
>>>> SFVec3f [in,out] location 0 0 0 (-∞,∞)
>>>> SFNode [in,out] metadata NULL [X3DMetadataObject]
>>>> SFFloat [in,out] nearDistance 1
>>>> SFBool [in,out] on TRUE
>>>> SFNode [in,out] texture NULL [X3DTexture2DNode]
>>>> SFFloat [out] aspectRatio (0,∞)
>>>> }
>>>> =============================
>>>> 42.4.1 TextureProjectorParallel
>>>>
>>>> TextureProjectorParallel : X3DTextureProjectorNode {
>>>> SFString [in,out] description ""
>>>> SFVec3f [in,out] direction 0 0 1 (-∞,∞)
>>>> SFFloat [in,out] farDistance 10
>>>> SFVec4f [in,out] fieldOfView -1 -1 1 1 (-∞,∞)
>>>> SFBool [in,out] global TRUE
>>>> SFVec3f [in,out] location 0 0 0 (-∞,∞)
>>>> SFNode [in,out] metadata NULL [X3DMetadataObject]
>>>> SFFloat [in,out] nearDistance 1
>>>> SFBool [in,out] on TRUE
>>>> SFNode [in,out] texture NULL [X3DTexture2DNode]
>>>> SFFloat [out] aspectRatio (0,∞)
>>>> }
>>>> =============================
>>>> 42.4.2 TextureProjectorPerspective
>>>>
>>>> TextureProjectorPerspective : X3DTextureProjectorNode {
>>>> SFString [in,out] description ""
>>>> SFVec3f [in,out] direction 0 0 1 (-∞,∞)
>>>> SFFloat [in,out] farDistance 10
>>>> SFFloat [in,out] fieldOfView π/4 (0,π)
>>>> SFBool [in,out] global TRUE
>>>> SFVec3f [in,out] location 0 0 0 (-∞,∞)
>>>> SFNode [in,out] metadata NULL [X3DMetadataObject]
>>>> SFFloat [in,out] nearDistance 1
>>>> SFBool [in,out] on TRUE
>>>> SFNode [in,out] texture NULL [X3DTexture2DNode]
>>>> SFVec3f [in,out] upVector 0 0 1
>>>> SFFloat [out] aspectRatio (0,∞)
>>>> }
>>>> =============================
>>>>
>>>> all the best, Don
>>>> --
>>>> Don Brutzman Naval Postgraduate School, Code USW/Br brutzman at nps.edu
>>>> Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149
>>>> X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman
>>>>
>>>> _______________________________________________
>>>> x3d-public mailing list
>>>> x3d-public at web3d.org
>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>
>> all the best, Don
>> --
>> Don Brutzman Naval Postgraduate School, Code USW/Br brutzman at nps.edu
>> Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149
>> X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman
all the best, Don
--
Don Brutzman Naval Postgraduate School, Code USW/Br brutzman at nps.edu
Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman
More information about the x3d-public
mailing list