[x3d-public] extra NavigationInfo modes, ptm

GPU Group gpugroup at gmail.com
Thu Jan 30 08:52:46 PST 2020 

https://webglfundamentals.org/webgl/lessons/webgl-render-to-texture.html
- shows rendering to a texture in webgl, so a GenerateOnceTexture or
GeneratedTexture with some frequency / start/stop / once fields could
work.in webgl
-Doug


On Thu, Jan 30, 2020 at 9:40 AM GPU Group <gpugroup at gmail.com> wrote:

> Upvector Hypotheses:
> H0: orientation,translation vs upvector - they do the same thing, its a
> matter of convenience, and given one, internally can convert to the other.
> If so then if its more convenient during scene authoring to follow
> viewpoint syntax, and more convenient in shaders to use upvector, then a
> few lines of code in the implementation can convert.
>
> Processing vs visualization
> Hypothesis:weeb3d needs a general node(s) for creating a texture once to
> be used repeatedly later
> (GeneratedCubeMapTexture I think it re-generates every frame)
> <GenerateOnceTexture>
> - uses backbuffer or fbo for target
> - <scenegraph with viewpoint, shaders etc listed here to render to
> backbuffer (or USE from Switch case)>
> - scrapes backbuffer into a texture
> - maybe a fall-back texture in case fbo capabilities aren't available (are
> they in GL 2.1/webgl?)
> </GenerateOnceTexture>
>
> -Doug
>
>
> On Thu, Jan 30, 2020 at 8:56 AM Andreas Plesch <andreasplesch at gmail.com>
> wrote:
>
>> I agree, just dealing with generating texture coordinates (on the fly, in
>> the shader) and plugging into the texCoord field feels much more seamless.
>>
>> Would that work for typical use cases ? Are those limited to
>> reconstruction of obliquely acquired images (from the air or inside a body)
>> ?
>>
>> Applying oblique imagery to a surface is really more of an image
>> processing step, and less of a visualization step.
>>
>> Since a projector really acts as a light source, could it be modeled as
>> an image based light ?
>>
>> I did not understand what the advantage of direction+upVector over
>> orientation as rotation is? Perhaps it is easier to animate direction
>> separately since upVector typically is constant ?
>>
>> ---on the phone---
>>
>> On Thu, Jan 30, 2020, 7:59 AM Michalis Kamburelis <
>> michalis.kambi at gmail.com> wrote:
>>
>>>  I think the alternative approach to Projective Texture Mapping,
>>> described by Andreas, is almost exactly what I proposed and
>>> implemented long time ago :)
>>>
>>> CGE approach to projective texture mapping (unrelated to PTM in X3Dv4)
>>> is on https://castle-engine.io/x3d_extensions_shadow_maps.php . It's
>>> part of shadow maps specs, but it's useful without shadow maps as
>>> well.
>>>
>>> Basically you can just use """ProjectedTextureCoordinate { projector
>>> USE MyViewport }""" as a texture coordinate (in a "texCoord" field).
>>> This generates texture coordinates, nothing more. You set up the
>>> appropriate textures using existing texturing methods.
>>>
>>> In the same spirit, I did mirrors on flat objects:
>>> https://castle-engine.io/x3d_extensions_mirror_plane.php , where you
>>> can use """TextureCoordinateGenerator { mode "MIRROR-PLANE" }""".
>>>
>>> I admit I like my approach a bit. It cooperates with existing texture
>>> specification without anything additional -- because it just generates
>>> texture coordinates, and doesn't try to do more. But I'm no longer
>>> subjective :)
>>>
>>> Regards,
>>> Michalis
>>>
>>> śr., 29 sty 2020 o 23:57 Andreas Plesch <andreasplesch at gmail.com>
>>> napisał(a):
>>> >
>>> > Hi Michalis,
>>> >
>>> > I took the opportunity to look at
>>> >
>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD1/Part01/components/ProjectiveTextureMapping.html
>>> > and some of the history.
>>> >
>>> > My main thought was why not reuse the existing, abstract viewpoint
>>> > nodes to define the projector characteristics. The projector node
>>> > fields just reiterate the viewpoint node fields, for the most part.
>>> > But probably there are enough differences since viewpoint mixes camera
>>> > and navigation options.
>>> >
>>> > Why not follow viewpoint and use orientation as a rotation instead of
>>> > direction and upVector ? Seems more consistent and simpler.
>>> >
>>> > The definition of the coordinate system for location/direction seems
>>> > to be missing. It is probably implied that it is the local coordinate
>>> > system.
>>> >
>>> > Overall, it feels strange to have a global projector to affect all
>>> > appearances by default but perhaps that is the most common scenario.
>>> > The term Texture Mapping rather implies that it is a way to compute
>>> > texture coordinates for a given texture, similar to
>>> > TextureCoordinateGenerator, and on a similar level:
>>> > ProjectiveTextureGenerator. DEF/USE would allow applying it to
>>> > multiple Appearances easily.
>>> >
>>> > -Andreas
>>> >
>>> > On Mon, Jan 27, 2020 at 6:18 PM Michalis Kamburelis
>>> > <michalis.kambi at gmail.com> wrote:
>>> > >
>>> > > Andreas Plesch <andreasplesch at gmail.com> wrote:
>>> > > >
>>> > > > x3dom has an extra explorationMode field which restricts mouse
>>> function in examine/turntable mode.
>>> > > > zoom, pan, rotate values restrict to only these.
>>> > > > -zoom, -pan, -rotate disable these.
>>> > > > The field tends to be quite useful.
>>> > > >
>>> > > > I think x-ite implemented Projective Texture Mapping.
>>> > >
>>> > > Good news we have an implementation of PTM.
>>> > >
>>> > > I had some questions about how the Projective Texture Mapping in X3D
>>> > > v4 applies the texture -- what happens if the shape already has a
>>> > > ImageTexture, what happens if shape already has MultiTexture etc. I
>>> > > listed them on "TODO: Address how the projective texturing in spec
>>> > > affects existing textures" in
>>> > >
>>> https://github.com/michaliskambi/x3d-tests/wiki/Clarify-%22Projective-texturing%22-component#todo-address-how-the-projective-texturing-in-spec-affects-existing-textures
>>> > > . I'll test how X_ITE answered these questions.
>>> > >
>>> > > Regards,
>>> > > Michalis
>>> > >
>>> > > >
>>> > > > ---on the phone---
>>> > > >
>>> > > > On Mon, Jan 27, 2020, 3:00 PM <x3d-public-request at web3d.org>
>>> wrote:
>>> > > >>
>>> > > >> Send x3d-public mailing list submissions to
>>> > > >>         x3d-public at web3d.org
>>> > > >>
>>> > > >> To subscribe or unsubscribe via the World Wide Web, visit
>>> > > >>         http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>> > > >> or, via email, send a message with subject or body 'help' to
>>> > > >>         x3d-public-request at web3d.org
>>> > > >>
>>> > > >> You can reach the person managing the list at
>>> > > >>         x3d-public-owner at web3d.org
>>> > > >>
>>> > > >> When replying, please edit your Subject line so it is more
>>> specific
>>> > > >> than "Re: Contents of x3d-public digest..."
>>> > > >>
>>> > > >>
>>> > > >> Today's Topics:
>>> > > >>
>>> > > >>    1. Re: x3d v4 proposed changes > 2 opensource criteria > any
>>> > > >>       that are short (GPU Group)
>>> > > >>
>>> > > >>
>>> > > >>
>>> ----------------------------------------------------------------------
>>> > > >>
>>> > > >> Message: 1
>>> > > >> Date: Mon, 27 Jan 2020 12:18:39 -0700
>>> > > >> From: GPU Group <gpugroup at gmail.com>
>>> > > >> To: X3D Graphics public mailing list <x3d-public at web3d.org>
>>> > > >> Subject: Re: [x3d-public] x3d v4 proposed changes > 2 opensource
>>> > > >>         criteria > any that are short
>>> > > >> Message-ID:
>>> > > >>         <
>>> CAM2ogRfqXoH1duy9iGvX9BEmLFCpiLbYYO_HwMuR7HbYXkRvmg at mail.gmail.com>
>>> > > >> Content-Type: text/plain; charset="utf-8"
>>> > > >>
>>> > > >> INVENTORY
>>> > > >> FREEWRL
>>> > > >> * X3Dv4 Implementations
>>> > > >>    https://www.web3d.org/x3dv4-implementations
>>> > > >> 1) 43 Projective Texture Mapping
>>> > > >> x freewrl does not implement, document is mistaken
>>> > > >> 2) 23.4.4 NavigationInfo > TURNTABLE
>>> > > >> * freewrl implemented
>>> > > >> (other freewrl navmodes and related not in v3.3:
>>> > > >> DIST - explicit control over distance to pivot point for examine,
>>> turntable
>>> > > >> - touchpads don't need RMB
>>> > > >> SHIFT - turns off sensors
>>> > > >> HOVER - isOver mode (useful for touch pad - allows triggering of
>>> isOver
>>> > > >> only)
>>> > > >> PEDAL - can drag 'floating cursor' in steps
>>> > > >> SPHERICAL - like FLY: YAWPITCH except rotations constrained to
>>> viewpoint
>>> > > >> local axes)
>>> > > >> subsets of FLY: YAWZ, XY, YAWPTICH,ROLL)
>>> > > >> 3) GeoSpatial > GeoOrigin - freewrl still allows in v3.3, never
>>> deprecated
>>> > > >> in freewrl
>>> > > >> 4) The rest freewrl has not implemented
>>> > > >> /FREEWRL
>>> > > >> Does this table miss anything?
>>> > > >> /INVENTORY
>>> > > >> -Doug Sanden
>>> > > >> PS who's doing projective texture mapping? Should start with that?
>>> > > >>
>>> > > >>
>>> > > >> On Mon, Jan 27, 2020 at 11:59 AM GPU Group <gpugroup at gmail.com>
>>> wrote:
>>> > > >>
>>> > > >> > INVENTORY
>>> > > >> > FREEWRL
>>> > > >> > * X3Dv4 Implementations
>>> > > >> >    https://www.web3d.org/x3dv4-implementations
>>> > > >> > 1) 43 Projective Texture Mapping
>>> > > >> > x freewrl does not implement, document is mistaken
>>> > > >> > 2) 23.4.4 NavigationInfo > TURNTABLE
>>> > > >> > * freewrl implemented
>>> > > >> > (other freewrl navmodes and related not in v3.3:
>>> > > >> > DIST - explicit control over distance to pivot point for
>>> examine,
>>> > > >> > turntable - touchpads don't need RMB
>>> > > >> > SHIFT - turns off sensors
>>> > > >> > HOVER - isOver mode (useful for touch pad - allows triggering
>>> of isOver
>>> > > >> > only)
>>> > > >> > PEDAL - can drag 'floating cursor' in steps
>>> > > >> > SPHERICAL - like FLY: YAWPITCH except rotations constrained to
>>> viewpoint
>>> > > >> > local axes)
>>> > > >> > subsets of FLY: YAWZ, XY, YAWPTICH,ROLL)
>>> > > >> > 3) GeoSpatial > GeoOrigin - freewrl still allows in v3.3, never
>>> deprecated
>>> > > >> > in freewrl
>>> > > >> > 4) The rest freewrl has not implemented
>>> > > >> > /FREEWRL
>>> > > >> > Does this table miss anything?
>>> > > >> > /INVENTORY
>>> > > >> >
>>> > > >> >
>>> > > >> > On Mon, Jan 27, 2020 at 11:14 AM Don Brutzman <brutzman at nps.edu>
>>> wrote:
>>> > > >> >
>>> > > >> >> Thanks for writing Doug.
>>> > > >> >>
>>> > > >> >> On 1/27/2020 6:01 AM, GPU Group wrote:
>>> > > >> >> > A rule of web3d.org <http://web3d.org> is that changes to
>>> the spec
>>> > > >> >> need a least 2 opensource implementations.
>>> > > >> >>
>>> > > >> >> * Web3D Standards Adoption Process
>>> > > >> >>    https://www.web3d.org/standards/adoption-process
>>> > > >> >>
>>> > > >> >> 5.c. "Identify at least two independent and interoperable
>>> implementations
>>> > > >> >> (at least one should be open source)"
>>> > > >> >>
>>> > > >> >> > Q. are there any proposed changes that do not yet have 2
>>> opensource
>>> > > >> >> implementations?
>>> > > >> >>
>>> > > >> >> Yes, plenty.  We have not taken a recent inventory of features
>>> yet, but
>>> > > >> >> will be tracking that at
>>> > > >> >>
>>> > > >> >> * X3Dv4 Implementations
>>> > > >> >>    https://www.web3d.org/x3dv4-implementations
>>> > > >> >>
>>> > > >> >> Our prominent open-source implementations for X3Dv3.3 include
>>> FreeWrl,
>>> > > >> >> X_ITE, X3DOM, Castle Game Engine.  Soon Xj3D will be back on
>>> the table as
>>> > > >> >> well.  There are also non-rendering X3Dv4 implementations for
>>> Java,
>>> > > >> >> JavaScript, Python, conversions and validation.  Not sure
>>> about Titania but
>>> > > >> >> presumably yes.  X3D-Editv4 is on the horizon. Interestingly
>>> everything on
>>> > > >> >> this list is open source.
>>> > > >> >>
>>> > > >> >> Hoping that FreeWrl developers are keen to keep their
>>> record-setting X3D
>>> > > >> >> support accomplishments continuing!  8)
>>> > > >> >>
>>> > > >> >> All feedback welcome, appreciate your many efforts.
>>> > > >> >>
>>> > > >> >> > Thanks,
>>> > > >> >> > Doug Sanden
>>> > > >> >> > -freewrl
>>> > > >> >>
>>> > > >> >> 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
>>> > > >> >>
>>> > > >> >
>>> > > >> -------------- next part --------------
>>> > > >> An HTML attachment was scrubbed...
>>> > > >> URL: <
>>> http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200127/53a57192/attachment-0001.html
>>> >
>>> > > >>
>>> > > >> ------------------------------
>>> > > >>
>>> > > >> Subject: Digest Footer
>>> > > >>
>>> > > >> _______________________________________________
>>> > > >> x3d-public mailing list
>>> > > >> x3d-public at web3d.org
>>> > > >> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>> > > >>
>>> > > >>
>>> > > >> ------------------------------
>>> > > >>
>>> > > >> End of x3d-public Digest, Vol 130, Issue 49
>>> > > >> *******************************************
>>> > > >
>>> > > > _______________________________________________
>>> > > > x3d-public mailing list
>>> > > > x3d-public at web3d.org
>>> > > > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>> >
>>> >
>>> >
>>> > --
>>> > 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/20200130/44797a0b/attachment-0001.html>

More information about the x3d-public mailing list