Radiance Mac GUI?

What would be involved with creating a simple Radiance GUI with Xcode?
I don't know next to nothing about programming, but Xcode seems to be
reasonably easy to understand. It may be just a matter of linking fileds to
rpict options

What would be usefull is to have a small window (128 x 128 or so) that
renders a simple scene (with rview? or rpict?)
Maybe the scene is a sphere in a cornell box or something

And then several fields that correspond to the options in rifs - quality,
PENUMBRAS, DETAIL, VARIABILITY etc
plus advanced rendering options... ad as ar ab aa etc.

changing any of these values would re-render the thumbnail with those
settings.

If it could be done, it would be helpful in determining good render
settings.

Or - Ive heard and kind of experienced that each scene has its own quirks
and needs - maybe a simple scene would not give a reasonable idea of what
would be needed for a complex scene.

Any thoughts?

Rob F

AppleScript Studio would support the command-line components of Radiance. The real problem is that Xcode won't support rview, rholo, and ximage--those would have to be given a native Mac interface, probably a Cocoa interface. Unfortunately, there's a maintenance issue (ANSIfication, which I am told is not quite complete) that the Radiance development collective would need to address before a Cocoa interface to these apps can be written.

Meanwhile Georg Mischler's Rayfront <http://www.schorsch.com/> addresses your issues under X Windows. I'm not sure he has it running on Mac OS X, but it would probably be a simple port. However, it would be a Unix app--not Mac-like at all.

Randolph

···

On Wednesday, July 7, 2004, at 01:08 PM, Fitzsimmons, Rob wrote:

What would be involved with creating a simple Radiance GUI with Xcode?
I don't know next to nothing about programming, but Xcode seems to be
reasonably easy to understand. It may be just a matter of linking fileds to
rpict options

Fitzsimmons, Rob wrote:

What would be involved with creating a simple Radiance GUI with Xcode?

Yet another platform dependent render preview GUI?


http://www.wxpython.org/ (http://www.wxwidgets.org/)
http://pyopengl.sourceforge.net/

If we turn libraycalls.a into a Python extension (it's easy),
then a GUI in Python using WxPython/WxWidgets will work on all
platforms that Radiance currently supports. We have the sources
of Winrview, where we can borrow some of the logic about how to
paint the image and other stuff.

There are several GUI builders around that could be used for
this. The most promising one used to be BoaConstructor, although
development on that one seems to have slowed down.
The UI description files produced by Glade can also be used,
even on those platforms where WxWidgets doesn't use Gtk.

http://boa-constructor.sourceforge.net/ (fetch from CVS)
http://wxglade.sourceforge.net/

There will be a lot of details to solve, but those belong to
the dev-list. Any volunteers? :wink:

Or - Ive heard and kind of experienced that each scene has its own quirks
and needs - maybe a simple scene would not give a reasonable idea of what
would be needed for a complex scene.

Yes, that's entirely correct. You need to play with the real thing.

-schorsch

···

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

Fitzsimmons, Rob wrote:

Or - Ive heard and kind of experienced that each scene has its own quirks
and needs - maybe a simple scene would not give a reasonable idea of what
would be needed for a complex scene.

Bingo. Different scenes present different challenges to Radiance, and hence different optimal parameters. BTW, did you know that you can change parameters in rv(ie)u with the 'set' command, and then type 'new' to re-render the image? It's tedious, but it does offer a way to experiment with the rendering options.

···

----

      Rob Guglielmetti

e. [email protected]
w. www.rumblestrip.org

Randolph Fritz wrote:

  Unfortunately, there's a maintenance issue
(ANSIfication, which I am told is not quite complete) that the Radiance
development collective would need to address before a Cocoa interface
to these apps can be written.

The ANSIfication ist mostly complete. There are other changes to
the code base that would help more in making this possible, but
aren't going to be finished soon.

If anyone wants to start a GUI project (possibly rolling rview,
rholo, and ximage functionality all into one), I wouldn't see any
fundamental obstacles against beginning with that right away.
The important point is just to define very clear internal APIs
first, on several levels. Once the core codebase gets more
modular and flexible, the seperation between front end and back
end can be moved back and forth as the task requires. It's all a
matter of finding the right abstractions.

Meanwhile Georg Mischler's Rayfront <http://www.schorsch.com/>
addresses your issues under X Windows. I'm not sure he has it running
on Mac OS X, but it would probably be a simple port. However, it would
be a Unix app--not Mac-like at all.

I simply don't have a working mac myself, or I would have ported
Rayfront a long time ago. Donations gladly accepted...

But that might really be a seperate topic. I'm not sure if I
understand Rob correctly, but I think what he wants is primarily
a "better rview". While Rayfront has all the bells and whistles
to set up a project with variations, and to create and assign
materials, it still relies on the old rview on posix platforms.

-schorsch

···

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

Rob,

BTW, did you know that you can
change parameters in rv(ie)u with the 'set' command, and then type 'new'
to re-render the image?

As far as I'm aware, you could only do that once when filling
the ambient cache - say, changing the ab setting from 0 to 1.
Thereafter, rview will continue to re-use the ambient cache as originally
populated first time round. The calculation may add to it, but it won't
flush it out and start again. Any further changes to ambient parameters
usually lead to inconsistent and, most likely, misleading results.
The only way to be sure is to kill the session and start again.

Now that certainly used to be the case. Does anyone know if rview has
been modified to flush out the ambient calc and restart during the
same session? Actually, there would be very little to gain over
quitting and restarting as the calculation has to begin from er... the
beginning for both.

-John

···

-----------------------------------------------
Dr. John Mardaljevic
Senior Research Fellow
Institute of Energy and Sustainable Development
De Montfort University
The Gateway
Leicester
LE1 9BH, UK
+44 (0) 116 257 7972
+44 (0) 116 257 7981 (fax)

[email protected]
http://www.iesd.dmu.ac.uk/~jm

John Mardaljevic wrote:

Rob,

BTW, did you know that you can change parameters in rv(ie)u with the 'set' command, and then type 'new' to re-render the image?

As far as I'm aware, you could only do that once when filling
the ambient cache - say, changing the ab setting from 0 to 1.
Thereafter, rview will continue to re-use the ambient cache as originally
populated first time round. The calculation may add to it, but it won't
flush it out and start again. Any further changes to ambient parameters
usually lead to inconsistent and, most likely, misleading results.

Ack. I did *not* know that, John. Honestly, I only change parameters that affect a visual change and it's purely for aesthetic reasons. Increasing the ambient bounces to see the interior of a daylit space, or increasing the direct sampling to see the pattern of a linear fluorescent that's close to the ceiling, for example. But if what you say is still the case, surely my tip is useless for analytical work.

Thanks for the heads up, the Robs thank you.

···

----

      Rob Guglielmetti

e. [email protected]
w. www.rumblestrip.org

Hi,

just to add... there is a Blender extension for Radiance export in development, which will offer a preview, there is rshow (the radiance frontend-tools except trad have already been mentioned as well as rayfront)... Why not continuing one of the existing projects? And, first, define the project's goal...!

- rad-frontend (just like trad)? Setting rendering parameters and start? Sounds a bit like the renderpark-design...
- scene-viewer with real-time ability (radiance has rholo...)? Sounds like rshow for the Mac, which has (and needs, if you want to set view-parameters real-time) OpenGL support...
- project management (like rayfront)?
- frontend just to avoid the command-line (drag the .rif-file onto the myradiancerenderer-Icon)?

I personally would only need something like rshow on the Mac, as OpenGL-performance with support of textures etc is not available so far. Previewing is ok with rview. And one feature is really missing - and was afaik available in rshow: camera path generation. The bigger approach would be to integrate all the above into one project, like rayfront with OpenGL-preview...

BTW, to throw one more into the language-box, many Mac OS X apps use Java for the GUI... which would help to keep things portable... and there are even 3d-classes for Java... :wink:

CU Lars.

···

--
Lars O. Grobe
[email protected]

I have tried the Blender Python export Radiance script (radiance_my227_GUI)
, but never got it to work...
I load the script, make changes to the export path, then export (alt-P) and
get a "Python script error - check console"... the line "import os" is
highlighted

couldn't find an email of the guy who wrote it
http://mywebpages.comcast.net/rayae1/tutorial.htm
Have any of you used it successfully?

And I checked out the Brad Blender Radiance GUI
http://www.dream.unipa.it/dream/pub/dot/anselmo/radiance/06.php

That looks cool too

Rob

···

-----Original Message-----
From: [email protected]
To: John Mardaljevic; Radiance general discussion
Sent: 7/8/2004 7:32 AM
Subject: Re: [Radiance-general] Radiance Mac GUI?

Hi,

just to add... there is a Blender extension for Radiance export in
development, which will offer a preview, there is rshow (the radiance
frontend-tools except trad have already been mentioned as well as
rayfront)... Why not continuing one of the existing projects? And,
first, define the project's goal...!

Lars O. Grobe wrote:

Why not continuing one of the existing projects?

Most existing projects have one or several disadvantages:
- platform specific
- limited scope of functionality
- obsolete technology (eg. tcl)
- not available for free

And, first, define the project's goal...!

Obviously, various people may have different goals.

My own goal in this context is very simple: Have a cross-platform
replacement for rview/rholo/ximage. Whether that's one single
application or several is irrelevant (and trivial to have both
ways when the frontend is implemented in Python).

Once the basic functionality is in place, the "nice to have"
features like realtime preview with textures and camera paths for
rview can be added.

BTW, to throw one more into the language-box, many Mac OS X apps use
Java for the GUI... which would help to keep things portable...

Write once, debug everywhere?

Opinions vary about this, but I can't see any advantages of Java
over Python. Java is much harder to write and uses a lot more
memory for the same tasks. And while the Java bytecode is in
theory portable like with Python, the Java VMs come in many
subtly incompatible varieties, each with its own bugs that need
to be taken into account. The good ones are usually also closed
source, so that you can't compile them yourself on less popular
platforms.

and there are even 3d-classes for Java... :wink:

Graphics should be done with OpenGL in either case. Or maybe with
a higher level toolkit like VTK, which again uses OpenGL.

Again, if anyone wants to seriously look into those things, the
details will be more appropriately discussed on the dev-list.

-schorsch

···

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