I'm thinking to program an interactive viewer based on rview, i like it more than rholo, and i think it's possile to make some improvements calculating an opengl depth and color map from viewpoint and from light sources. Now i'm starting with x11 and i have not found a way to use events with callbacks or signals so as not to use a loop that waste a lot cpu. is there any way?
thanks and sorry for my english,
Ignacio Munarriz
Is the problem that you want to check for input occasionally while continuing the ray calculation? In such a circustance, polling works just fine, so long as you don't do it too often. Rview already has such a mechanism in place in its X11 driver. What is the problem, exactly?
-Greg
From: Ignacio Munárriz <[email protected]>
Date: December 23, 2004 1:19:03 AM PST
I'm thinking to program an interactive viewer based on rview, i like it more than rholo, and i think it's possile to make some improvements calculating an opengl depth and color map from viewpoint and from light sources. Now i'm starting with x11 and i have not found a way to use events with callbacks or signals so as not to use a loop that waste a lot cpu. is there any way?
thanks and sorry for my english,
Ignacio Munarriz
Begin forwarded message:
Greg, unfortunately, although polling is very simple, it is also very
inefficient. The CPU can waste an awful lot of time just waiting for input.
And i need that time for ray calculation. I think that rholo start a fork
process and the processor divide the time between ray calculation and
visualization-events. The best way would be that the hardware interrupt call
diretly the event function so dont need a loop to search for input
----- Original Message -----
From: "Greg Ward" <[email protected]>
To: "code development" <[email protected]>
Sent: Thursday, December 23, 2004 4:47 PM
Subject: Re: [Radiance-dev] x11 events
Is the problem that you want to check for input occasionally while
continuing the ray calculation? In such a circustance, polling works
just fine, so long as you don't do it too often. Rview already has
such a mechanism in place in its X11 driver. What is the problem,
exactly?
-Greg
Begin forwarded message:
From: Ignacio Mun�rriz <[email protected]>
Date: December 23, 2004 1:19:03 AM PST
I'm thinking to program an interactive viewer based on rview, i like
it more than rholo, and i think it's possile to make some
improvements calculating an opengl depth and color map from viewpoint
and from light sources. Now i'm starting with x11 and i have not found
a way to use events with callbacks or signals so as not to use a loop
that waste a lot cpu. is there any way?
thanks and sorry for my english,
Ignacio Munarriz
_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev
Ignacio Munárriz wrote:
Greg, unfortunately, although polling is very simple, it is also very
inefficient. The CPU can waste an awful lot of time just waiting for input.
And i need that time for ray calculation. I think that rholo start a fork
process and the processor divide the time between ray calculation and
visualization-events. The best way would be that the hardware interrupt call
diretly the event function so dont need a loop to search for input
IRQ handling with X11 ? Hm. IRQ handling is approximately half-a-dozen layers underneath the X11 library calls. So these are really two very different worlds.
Anyway; X11 has ways to specify call-backs, but as far as I remember interleaving them with other, non-X11 tasks is cumbersome. So using the X11 polling calls is likely the easiest way to go.
Your program wouldn't waste CPU cycles because it does the raytracing. Just check for pending user input every 30 to 100 milliseconds is practically enough for interactive update rates (provides your program collects all pending input then and not just the last one) and that time interval could be given by querying some clock (man gettimeofday) or set a timer (man ualarm), which should both have neglectable overhead.
my 2-euro-cents thoughts
-Peter
--
pab-opto, Freiburg, Germany, http://www.pab-opto.de
[see web page to check digital email signature]
Peter Apian-Bennewitz wrote:
Ignacio Munárriz wrote:
>Greg, unfortunately, although polling is very simple, it is also very
>inefficient. The CPU can waste an awful lot of time just waiting for input.
>And i need that time for ray calculation. I think that rholo start a fork
>process and the processor divide the time between ray calculation and
>visualization-events. The best way would be that the hardware interrupt call
>diretly the event function so dont need a loop to search for input
>
>
IRQ handling with X11 ? Hm. IRQ handling is approximately half-a-dozen
layers underneath the X11 library calls. So these are really two very
different worlds.
Speaking about layers of abstraction...
Have you considered a cross-platform solution?
I have recommended Python and/or WxWidgets before, and I'll
continue to do so. I really like the enthusiasm people put into
such projects, but if you develop for X11, then that will just
perpetuate the porting problems we already have.
Of course, abstract toolkits like WxWidgets also have the
advantage that programming with them is *much* easier and more
convenient than with any platform specific API.
-schorsch
--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/
Maybe, the best way is using a timer. I worked with wxwidgets and i did a
first aproximation of the viewer adding a orbit and a pan function to glrad
but I would not like to soil Gregs code with new libraries, and probably
wxwidgets also use a timer on x11.
I am only starting with the viewer, learning greg's code (it's amazing). I
would like to do an interactive viewer althougth it works at small
resolutions (300x300 px or so) starting from rview. I think rview can be
optimized for architecture visualization on some ways:
- adding interactive orbit, pan and walkthrough functions
- using opengl to obtain point(color=object number,z buffer=distance)
intersections from viewer
- using opengl to make shadow maps from light points and using them or
forcing the ray calculation in function of the distance to the shadow (to
avoid too small shadow pictures)
- using the irradiance caching but adding to the file all the values cached
from all the hemisphere and using them to the ambient component (indirect
irradiance) and also for the rough specular component
- using opengl objects duplication in the plane of simmetry and stencil
buffer to calculate points intersections of reflections(specular
sampling)(color=object, zbuffer=distance)
The viewer will try to optimize time but maintaining all greg's light and
material calculation
thanks peter and georg
----- Original Message -----
From: "Georg Mischler" <[email protected]>
To: "code development" <[email protected]>
Sent: Friday, December 24, 2004 12:28 PM
Subject: Re: [Radiance-dev] x11 events
Peter Apian-Bennewitz wrote:
Ignacio Mun�rriz wrote:
>Greg, unfortunately, although polling is very simple, it is also very
>inefficient. The CPU can waste an awful lot of time just waiting for
input.
>And i need that time for ray calculation. I think that rholo start a fork
>process and the processor divide the time between ray calculation and
>visualization-events. The best way would be that the hardware interrupt
call
>diretly the event function so dont need a loop to search for input
>
>
IRQ handling with X11 ? Hm. IRQ handling is approximately half-a-dozen
layers underneath the X11 library calls. So these are really two very
different worlds.
Speaking about layers of abstraction...
Have you considered a cross-platform solution?
I have recommended Python and/or WxWidgets before, and I'll
continue to do so. I really like the enthusiasm people put into
such projects, but if you develop for X11, then that will just
perpetuate the porting problems we already have.
Of course, abstract toolkits like WxWidgets also have the
advantage that programming with them is *much* easier and more
convenient than with any platform specific API.
-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
Ignacio Munárriz wrote:
...
I am only starting with the viewer, learning greg's code (it's amazing). I
would like to do an interactive viewer althougth it works at small
resolutions (300x300 px or so) starting from rview. I think rview can be
optimized for architecture visualization on some ways:- adding interactive orbit, pan and walkthrough functions
- using opengl to obtain point(color=object number,z buffer=distance)
intersections from viewer
- using opengl to make shadow maps from light points and using them or
forcing the ray calculation in function of the distance to the shadow (to
avoid too small shadow pictures)
- using the irradiance caching but adding to the file all the values cached
from all the hemisphere and using them to the ambient component (indirect
irradiance) and also for the rough specular component
- using opengl objects duplication in the plane of simmetry and stencil
buffer to calculate points intersections of reflections(specular
sampling)(color=object, zbuffer=distance)The viewer will try to optimize time but maintaining all greg's light and
material calculation
Hi Ignacio
very noble and good ideas. If you want more two-cents thoughts on merging raytracing and Open-GL from an old chap:
It has been tried before, one is rshow (nudge-nudge,wink-wink to use a Python phrase) the other was an LBNL project approx 6 years ago which aimed at achieving realtime RT with a Cray as backend (there may very well be other projects that I'm not aware of). The later had been original fueled by a proposal written by Greg (than at LBNL), but apparently the thing didn't take off (a good part being that Greg wasn't at LBNL anymore).
From these, one core problem seemed to be that Open-GL and the Radiance engine differ vastly on how they are able to handle large sets of objects. Naked Open-GL scales badly with the number of objects to display, while the Radiance engine scales well but throws away all values (in rview at least). Rholo re-uses the values, but doesn't seem to implement Open-GL to its maximum use (e.g. it doesn't try to use HW accelerated rendering to fill time wise intermediate gaps in RT data, it doesn't map any values to 3d polygons in the scene, etc.). Due to the first fact, that Open-GL doesn't scale well, such a hybrid approach seems tricky, as a straight 1:1 use of existing geometry would potentially dead-lock on complex geometries (the location of that boundary depends on the power of the graphic card).
A meta-3D-structure that envelopes the core structures of the 3d model and thereby de-douples the Open-GL rendering from the complexity of the underlying input geometry, while offering surfaces to map RT generated data onto, is conceivable. And left as an exercise to the reader....
I'm not current with computer graphics at all, just some thoughts where green gras *may* be over the hill in another valley.
Now- where are those Xmas cookies, and what's on for dinner tonight -
cheers
Peter
--
pab-opto, Freiburg, Germany, http://www.pab-opto.de
[see web page to check digital email signature]
Thanks Peter, i will not try to make an universal viewer, i�ll try to
optimize it to architecture visualization(withot nature), so the number of
objects will be small (walls, ceiling.. big polygons) and the reflections
will be planar (windows, floor...opengl mirror solution), it could be a good
solution for www interior buildings walktroughs,
happy Xmas and don�t eat too much "Pl�tzchen"
----- Original Message -----
From: "Peter Apian-Bennewitz" <[email protected]>
To: "code development" <[email protected]>
Sent: Saturday, December 25, 2004 1:04 PM
Subject: Re: [Radiance-dev] x11 events
Ignacio Mun�rriz wrote:
...
I am only starting with the viewer, learning greg's code (it's amazing). I
would like to do an interactive viewer althougth it works at small
resolutions (300x300 px or so) starting from rview. I think rview can be
optimized for architecture visualization on some ways:- adding interactive orbit, pan and walkthrough functions
- using opengl to obtain point(color=object number,z buffer=distance)
intersections from viewer
- using opengl to make shadow maps from light points and using them or
forcing the ray calculation in function of the distance to the shadow (to
avoid too small shadow pictures)
- using the irradiance caching but adding to the file all the values cached
from all the hemisphere and using them to the ambient component (indirect
irradiance) and also for the rough specular component
- using opengl objects duplication in the plane of simmetry and stencil
buffer to calculate points intersections of reflections(specular
sampling)(color=object, zbuffer=distance)The viewer will try to optimize time but maintaining all greg's light and
material calculation
Hi Ignacio
very noble and good ideas. If you want more two-cents thoughts on
merging raytracing and Open-GL from an old chap:
It has been tried before, one is rshow (nudge-nudge,wink-wink to use a
Python phrase) the other was an LBNL project approx 6 years ago which
aimed at achieving realtime RT with a Cray as backend (there may very
well be other projects that I'm not aware of). The later had been
original fueled by a proposal written by Greg (than at LBNL), but
apparently the thing didn't take off (a good part being that Greg wasn't
at LBNL anymore).
From these, one core problem seemed to be that Open-GL and the Radiance
engine differ vastly on how they are able to handle large sets of
objects. Naked Open-GL scales badly with the number of objects to
display, while the Radiance engine scales well but throws away all
values (in rview at least). Rholo re-uses the values, but doesn't seem
to implement Open-GL to its maximum use (e.g. it doesn't try to use HW
accelerated rendering to fill time wise intermediate gaps in RT data, it
doesn't map any values to 3d polygons in the scene, etc.). Due to the
first fact, that Open-GL doesn't scale well, such a hybrid approach
seems tricky, as a straight 1:1 use of existing geometry would
potentially dead-lock on complex geometries (the location of that
boundary depends on the power of the graphic card).
A meta-3D-structure that envelopes the core structures of the 3d model
and thereby de-douples the Open-GL rendering from the complexity of the
underlying input geometry, while offering surfaces to map RT generated
data onto, is conceivable. And left as an exercise to the reader....
I'm not current with computer graphics at all, just some thoughts where
green gras *may* be over the hill in another valley.
Now- where are those Xmas cookies, and what's on for dinner tonight -
cheers
Peter
--
pab-opto, Freiburg, Germany, http://www.pab-opto.de
[see web page to check digital email signature]
_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev