Radiance and Open-Gl

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 <[email protected] >>> <mailto:[email protected]>> wrote:

On Apr 27, 2016 6:50 PM, "Douglas L Reeder" <[email protected] >>> <mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
http://www.radiance-online.org/mailman/listinfo/radiance-dev

_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev

--
  pab-opto, Freiburg, Germany, http://www.pab-opto.de

_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

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 <[email protected]>
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 <[email protected] >>>> <mailto:[email protected]>> wrote:
On Apr 27, 2016 6:50 PM, "Douglas L Reeder" <[email protected] >>>> <mailto:[email protected]>> 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?