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