Radiance and Open-GI

Hi,

after Sarith Subramaniam volunteered successfully to create objview.py,
we started wondering why makeall doesn't build glrad on Linux.
SCons builds it without complaints, but it doesn't actually work.
If I understand the debugger correctly, it seems to have difficulties
setting the view size, hanging in an infinite loop around line 541 in
glrad.c.

Is there any specific reason why it's not supposed to work on Linux,
or is it just that nobody ever managed to find a solution?
Unfortunately, I'm not familiar with the involved APIs at all, so I
don't really know where to start looking for problems.
I just assume that it actually does work on MacOS and with Cygwin, where
makeall includes it in the build (if not, why would it still be there?).

Cheers
-schorsch

···

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

Yeah, one of the pieces of code I haven't really kept up with. I just checked in a fix for the broken window size negotiation that doesn't seem to work as it used to. This wasn't working under OS X either, and no one had noticed. That's just how important this program is to people.....

Cheers,
-Greg

···

From: Georg Mischler <[email protected]>
Subject: [Radiance-dev] Glrad on Linux
Date: April 24, 2016 12:12:58 PM PDT

Hi,

after Sarith Subramaniam volunteered successfully to create objview.py,
we started wondering why makeall doesn't build glrad on Linux.
SCons builds it without complaints, but it doesn't actually work.
If I understand the debugger correctly, it seems to have difficulties
setting the view size, hanging in an infinite loop around line 541 in
glrad.c.

Is there any specific reason why it's not supposed to work on Linux,
or is it just that nobody ever managed to find a solution?
Unfortunately, I'm not familiar with the involved APIs at all, so I
don't really know where to start looking for problems.
I just assume that it actually does work on MacOS and with Cygwin, where
makeall includes it in the build (if not, why would it still be there?).

Cheers
-schorsch

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

Cool, now I get to see something! I don't remember ever having seen
this working before, but I may have just forgotten...

Motion is *very* fast and jumpy. It was probably calibrated decades ago
with a much less powerfull graphics system (despite me trying it on an
onboard graphics module with Mesa in software mode).
The mouse wheel moves the view back, no matter which way it is turned.

Why isn't this used more often?
For one, all the tutorials instruct new users to use rvu (not sure
if glrad is actually ever mentioned). So many people probably don't even
know it exists.

The user interaction is also a bit limited in comparison.
With smoother motion, more motion options (eg. lateral and vertical),
and configurable speed, it probably could be quite popular.
Of course, those things might be somewhat fiddly to implement.

But the good news for now: it *does* work on Linux!

Cheers
-schorsch

···

Am 2016-04-25 04:05, schrieb Gregory J. Ward:

Yeah, one of the pieces of code I haven't really kept up with. I just
checked in a fix for the broken window size negotiation that doesn't
seem to work as it used to. This wasn't working under OS X either,
and no one had noticed. That's just how important this program is to
people.....

Cheers,
-Greg

From: Georg Mischler <[email protected]>
Subject: [Radiance-dev] Glrad on Linux
Date: April 24, 2016 12:12:58 PM PDT

Hi,

after Sarith Subramaniam volunteered successfully to create objview.py,
we started wondering why makeall doesn't build glrad on Linux.
SCons builds it without complaints, but it doesn't actually work.
If I understand the debugger correctly, it seems to have difficulties
setting the view size, hanging in an infinite loop around line 541 in
glrad.c.

Is there any specific reason why it's not supposed to work on Linux,
or is it just that nobody ever managed to find a solution?
Unfortunately, I'm not familiar with the involved APIs at all, so I
don't really know where to start looking for problems.
I just assume that it actually does work on MacOS and with Cygwin, where
makeall includes it in the build (if not, why would it still be there?).

Cheers
-schorsch

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

I agree that the interaction speed is way too fast. I'll see if I can tweak it a bit, but this was something I wrote because I had the routines from rholo and decided it might be useful to have a geometry-only preview.

Cheers,
-Greg

···

From: Georg Mischler <[email protected]>
Subject: Re: [Radiance-dev] Glrad on Linux
Date: April 25, 2016 12:27:44 PM PDT

Cool, now I get to see something! I don't remember ever having seen
this working before, but I may have just forgotten...

Motion is *very* fast and jumpy. It was probably calibrated decades ago
with a much less powerfull graphics system (despite me trying it on an
onboard graphics module with Mesa in software mode).
The mouse wheel moves the view back, no matter which way it is turned.

Why isn't this used more often?
For one, all the tutorials instruct new users to use rvu (not sure
if glrad is actually ever mentioned). So many people probably don't even
know it exists.

The user interaction is also a bit limited in comparison.
With smoother motion, more motion options (eg. lateral and vertical),
and configurable speed, it probably could be quite popular.
Of course, those things might be somewhat fiddly to implement.

But the good news for now: it *does* work on Linux!

Cheers
-schorsch

Am 2016-04-25 04:05, schrieb Gregory J. Ward:

Yeah, one of the pieces of code I haven't really kept up with. I just
checked in a fix for the broken window size negotiation that doesn't
seem to work as it used to. This wasn't working under OS X either,
and no one had noticed. That's just how important this program is to
people.....
Cheers,
-Greg

From: Georg Mischler <[email protected]>
Subject: [Radiance-dev] Glrad on Linux
Date: April 24, 2016 12:12:58 PM PDT
Hi,
after Sarith Subramaniam volunteered successfully to create objview.py,
we started wondering why makeall doesn't build glrad on Linux.
SCons builds it without complaints, but it doesn't actually work.
If I understand the debugger correctly, it seems to have difficulties
setting the view size, hanging in an infinite loop around line 541 in
glrad.c.
Is there any specific reason why it's not supposed to work on Linux,
or is it just that nobody ever managed to find a solution?
Unfortunately, I'm not familiar with the involved APIs at all, so I
don't really know where to start looking for problems.
I just assume that it actually does work on MacOS and with Cygwin, where
makeall includes it in the build (if not, why would it still be there?).
Cheers
-schorsch

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

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

Ah yes, that's a much better speed.

Most walkthrough viewers seem to use arrow keys for basic navigation.
Is the program even checking the mouse wheel, or is that a Mesa weirdness?

Colors also seem rather high contrast. Are surface colors taken directly
from Radiance reflectivities? If so, then maybe there should be some
non-linear scaling there.

Enough nits picked for the moment...

Cheers
-schorsch

···

Am 2016-04-25 21:58, schrieb Gregory J. Ward:

I agree that the interaction speed is way too fast. I'll see if I can
tweak it a bit, but this was something I wrote because I had the
routines from rholo and decided it might be useful to have a
geometry-only preview.

Cheers,
-Greg

From: Georg Mischler <[email protected]>
Subject: Re: [Radiance-dev] Glrad on Linux
Date: April 25, 2016 12:27:44 PM PDT

Cool, now I get to see something! I don't remember ever having seen
this working before, but I may have just forgotten...

Motion is *very* fast and jumpy. It was probably calibrated decades ago
with a much less powerfull graphics system (despite me trying it on an
onboard graphics module with Mesa in software mode).
The mouse wheel moves the view back, no matter which way it is turned.

Why isn't this used more often?
For one, all the tutorials instruct new users to use rvu (not sure
if glrad is actually ever mentioned). So many people probably don't even
know it exists.

The user interaction is also a bit limited in comparison.
With smoother motion, more motion options (eg. lateral and vertical),
and configurable speed, it probably could be quite popular.
Of course, those things might be somewhat fiddly to implement.

But the good news for now: it *does* work on Linux!

Cheers
-schorsch

Am 2016-04-25 04:05, schrieb Gregory J. Ward:

Yeah, one of the pieces of code I haven't really kept up with. I just
checked in a fix for the broken window size negotiation that doesn't
seem to work as it used to. This wasn't working under OS X either,
and no one had noticed. That's just how important this program is to
people.....
Cheers,
-Greg

From: Georg Mischler <[email protected]>
Subject: [Radiance-dev] Glrad on Linux
Date: April 24, 2016 12:12:58 PM PDT
Hi,
after Sarith Subramaniam volunteered successfully to create objview.py,
we started wondering why makeall doesn't build glrad on Linux.
SCons builds it without complaints, but it doesn't actually work.
If I understand the debugger correctly, it seems to have difficulties
setting the view size, hanging in an infinite loop around line 541 in
glrad.c.
Is there any specific reason why it's not supposed to work on Linux,
or is it just that nobody ever managed to find a solution?
Unfortunately, I'm not familiar with the involved APIs at all, so I
don't really know where to start looking for problems.
I just assume that it actually does work on MacOS and with Cygwin, where
makeall includes it in the build (if not, why would it still be there?).
Cheers
-schorsch

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

_______________________________________________
Radiance-dev mailing list
[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

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

I don't know how to get to the mouse wheel events from X11, so I'm not using that information. The '+' and '-' keys affect zoom as stated in the man page, but the arrow controls are also not standards in X11 as far as I know, so I'm not listening for those. If you have some insight on how to handle such events, I can try, but we might confirm first that people use this utility or have a desire for it. The controls were designed to mimic those in rholo, which I and perhaps a handful of others still use.

I don't remember how I light the objects -- I think it tries to use the light sources, specular and diffuse materials, etc. You would have to look in the src/common/rgl* routines. There are no cast shadows (or interreflections, obviously).

-Greg

···

From: Georg Mischler <[email protected]>
Subject: Re: [Radiance-dev] Glrad on Linux
Date: April 25, 2016 10:55:12 PM PDT

Ah yes, that's a much better speed.

Most walkthrough viewers seem to use arrow keys for basic navigation.
Is the program even checking the mouse wheel, or is that a Mesa weirdness?

Colors also seem rather high contrast. Are surface colors taken directly
from Radiance reflectivities? If so, then maybe there should be some
non-linear scaling there.

Enough nits picked for the moment...

Cheers
-schorsch

Am 2016-04-25 21:58, schrieb Gregory J. Ward:

I agree that the interaction speed is way too fast. I'll see if I can
tweak it a bit, but this was something I wrote because I had the
routines from rholo and decided it might be useful to have a
geometry-only preview.
Cheers,
-Greg

From: Georg Mischler <[email protected]>
Subject: Re: [Radiance-dev] Glrad on Linux
Date: April 25, 2016 12:27:44 PM PDT
Cool, now I get to see something! I don't remember ever having seen
this working before, but I may have just forgotten...
Motion is *very* fast and jumpy. It was probably calibrated decades ago
with a much less powerfull graphics system (despite me trying it on an
onboard graphics module with Mesa in software mode).
The mouse wheel moves the view back, no matter which way it is turned.
Why isn't this used more often?
For one, all the tutorials instruct new users to use rvu (not sure
if glrad is actually ever mentioned). So many people probably don't even
know it exists.
The user interaction is also a bit limited in comparison.
With smoother motion, more motion options (eg. lateral and vertical),
and configurable speed, it probably could be quite popular.
Of course, those things might be somewhat fiddly to implement.
But the good news for now: it *does* work on Linux!
Cheers
-schorsch
Am 2016-04-25 04:05, schrieb Gregory J. Ward:

Yeah, one of the pieces of code I haven't really kept up with. I just
checked in a fix for the broken window size negotiation that doesn't
seem to work as it used to. This wasn't working under OS X either,
and no one had noticed. That's just how important this program is to
people.....
Cheers,
-Greg

From: Georg Mischler <[email protected]>
Subject: [Radiance-dev] Glrad on Linux
Date: April 24, 2016 12:12:58 PM PDT
Hi,
after Sarith Subramaniam volunteered successfully to create objview.py,
we started wondering why makeall doesn't build glrad on Linux.
SCons builds it without complaints, but it doesn't actually work.
If I understand the debugger correctly, it seems to have difficulties
setting the view size, hanging in an infinite loop around line 541 in
glrad.c.
Is there any specific reason why it's not supposed to work on Linux,
or is it just that nobody ever managed to find a solution?
Unfortunately, I'm not familiar with the involved APIs at all, so I
don't really know where to start looking for problems.
I just assume that it actually does work on MacOS and with Cygwin, where
makeall includes it in the build (if not, why would it still be there?).
Cheers
-schorsch

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/
_______________________________________________
Radiance-dev mailing list
[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

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

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

Mouse wheel events are reported as mouse button presses; there's a list at
this web site: http://xahlee.info/kbd/X11_mouse_button_numbering.html. That
list is for Linux; I'm not sure if the same list is used on Mac OS.

YMMV.

Randolph

I have confirmed using xev that button 4 is scroll up and 5 is scroll down
on Mac OS. Anything fancier, I don't know.​

Randolph

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.

Doug

···

On Apr 27, 2016, at 7:36 PM, Randolph M. Fritz <[email protected]> wrote:

Mouse wheel events are reported as mouse button presses; there's a list at this web site: http://xahlee.info/kbd/X11_mouse_button_numbering.html. That list is for Linux; I'm not sure if the same list is used on Mac OS.

YMMV.

Randolph

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

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?

···

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

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

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.

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