Yes, agreed 100%. If you are serious about geometry preview, you are certainly better off with rshow. I wrote glrad only because it was low-hanging fruit at the time, having written all this OpenGL stuff to support rholo.
That said, I have added listening for the mouse wheel, and glrad will now zoom in response. The rholo drivers will ignore it, rather than responding inappropriately, since zooming doesn't really make sense in that tool. Cheers, -Greg > From: Georg Mischler <schor...@schorsch.com> > Subject: Re: [Radiance-dev] Radiance and Open-Gl > Date: April 27, 2016 11:59:25 PM PDT > > That's quite interesting information (at least for me, after > being out of the loop for a while). > > But I think there are two different contexts to consider here. > Glrad is obviously a quick-and-dirty solution, but it works and is > included in the distribution. I think it's absolutely worth it to > fix some small stuff in there like checking for another two event > keys to get the scroll wheel working properly. > > For more advanced features, I'd prefer a less platform dependent > solution (which then in turn tends to add toolkit dependencies). > > I've already wondered what might have happened with rshow. > I don't see Tk as a problem at all. I use it all the time (it comes > included with Python) and consider it the most underestimated GUI > toolkit on the planet. > Tcl as a language though... might be hard for anyone but you to > maintain. > Btw: The simplest approach for the complexity problem seems to be > frustrum clipping. Probably works well for trees in a forest, but not > so well when you have very detailed geometry within the space you're > looking at. > > I've looked at higher level 3d toolkits from time to time out of a > more general interest (again from a Python perspective). Many are > rather huge and loaded with game-related features that we wouldn't > need. My current favourites are Panda3D and VTK. They both are > sufficiently powerful, cross-platform, with mature APIs in several > languages, and adequately free licenses. > But I haven't managed to actually play around with either of them yet. > > Cheers > -schorsch > > > Am 2016-04-28 07:17, schrieb Peter Apian-Bennewitz: >> Hi folks, >> before you get all carried away with Xlib events for mouse scroll , - >> and to add some thoughts on the rediscovery of glrad: >> Rshow, http://www.pab-opto.de/progs/rshow/ , the current Open-Gl >> version of my 1993 rshow on the then Iris-Gl, is still existing. Comes >> with GUI and some extra features, like generating image mapping, data >> display, grid generation, raytracing and multiple windows. Not much >> advertising for it over the years (except this one, also see 1998 >> paper on rshow), it is still in daily use here and at Fraunhofer ISE. >> (Note to LBNL: ISE is /not/ IBP, in case you shift all credit to IBP >> again). >> Lessons learned: >> The core problem with Open-Gl display in practice seems complexity. >> E.g.: Being inside a cabin with a forest outside doesn't matter for >> raytracing speed, but it does for plain Open-Gl, since it tries to >> draw all trees outside, visible or not. Today’s entry graphic cards >> have more power then a 1995 SGI Onyx2 , yes, but scenes have become >> more complex too, so brute force works only so much. >> Rshow has a commandline option to ignore geometry below a certain >> size, so that allow interactive navigation with smooth, tessellated >> CAD surfaces, but it is a rather amateurish solution. Its Tcl/Tk GUI >> is a bit dated too, although, Tcl/Tk libraries are still supported by >> Debian and others. Apart from all this, I had not a single project in >> the last 20 years where rshow was not used, - "works for me". >> There's at least one other Radiance geometry renderer out there, >> written by Andreas Gerber, based on some graphics library, but I don't >> further details at hand. >> And one of the nicest Open-GL renderers had been the one in "Ecotect", >> - before it disappeared in the garbage bin of Autodesk. >> Both rshow and glrad use the legacy API of Open-Gl, which has changed >> since then with the introduction of "shaders". It is still backward >> compatible (and probably will be a while with the mass of existing >> programs), but users are encouraged to upgrade. >> Actually, I would have a look at the rendering engines available for >> some games if I were to start a very fast hardware Radiance-previewer >> from scratch today. They probably solved the Level-of-detail problem >> neatly. The drawback is, of course, the dependency on their feature >> library. >> cheers >> Peter >> On 04/28/16 05:17, Douglas L Reeder wrote: >>> Randolph, >>> Yes, after I saw your 5 values I rotated it both ways and got/duplicated >>> your >>> results. >>> Doug >>>> On Apr 27, 2016, at 8:25 PM, Randolph M. Fritz <rmfri...@gmail.com >>>> <mailto:rmfri...@gmail.com>> wrote: >>>> On Apr 27, 2016 6:50 PM, "Douglas L Reeder" <d...@centurylink.net >>>> <mailto:d...@centurylink.net>> wrote: >>>> > >>>> > Randolph, >>>> > >>>> > On os x with a logitech 3 button mouse with the center button being a >>>> > mouse >>>> wheel xev returns button 1 for the left button, 2 for depressing the >>>> wheel, 3 >>>> for the right button, and 4 for rotating the wheel. >>>> > >>>> > >>>> Hunh, interesting. Did you try rotating the wheel both ways? >>>> _______________________________________________ Radiance-dev mailing list Radiance-dev@radiance-online.org http://www.radiance-online.org/mailman/listinfo/radiance-dev
