Re: [Brad] FW: Blender Radiance Interface II

[Francesco Anselmo]

Hi Thomas,

On Mon, 2005-07-11 at 22:46 +0200, Thomas Bleicher wrote:
> My confirmation messages arrived finally so I can post
> this myself as well.

The Savannah mailserver seems to be slow sometimes ...

> > I tried to subscribe to the brad list, but didn't recieve a
> > confirmation email so far. We should forward this dialog later
> > to the list as well (if we're not between us on the list, too).

There are currently 13 people who subscribed to this discussion
list, and it is about time to post something interesting ;)
It has been very sleepy in the past months ...

> > I have no final idea about the interface design yet. The current
> > structure of "pages" and "subpages" (like "gensky" and "gendaylit")
> > allow me to cramp the interface with every special purpose page
> > i can think of, which is in fact the way I develop.

This is the main reason why I use menus and windows, every time
I need to add a new functionality, I add a command in the pertinent
menu and a new class for the window ...

> > I'd like to keep the interface, the higher level widgets and the
> > export logic as separate as possible. We may be the only users of
> > Blender for Radiance export but there are a 200000 Blender users
> > that might use the parts of the interface and there are some Radiance
> > users that might use the (pure Python) export/import/render control
> > classes. I'd like to allow them to do this.

This may happen more with your code, not with mine. As you may see,
I've also divided the gui code from the export related code, but your
abstractions make much more sense. I started coding without any
clear planning, just to make things work and learn how to
use both Python and Blender.

> > The Blender interface code is based on simple drawing commands and
> > widgets. It should be possible to port it to a simple toolkit with
> > OpenGL support (Qt, GTK, FOX, TK) and have a stand alone version
> > of the interface for non-Blender users. OTOH that would be only "yet
> > another frontend".

Well, the main reason to keep using Blender is because it enables
to directly work with the model without re-inventing the wheel.
Should we vote for the widget toolkit, I would prefer wxpython+VTK ...

> > That's still a bit messy. It works for me ...
> > The script should access the user environment and evaluate PATH
> > and RAYPATH to find these binaries.

In my scripts I prefer to set the PATH and RAYPATH variables
from within the program (os.putenv) to avoid problems.
I think that my initial intention was to ship the binaries
in a subfolder together with b/rad ...

> > Im afraid of situations where I don't understand the logic of the
> > Radiance code or underlying data and my reproduction introduces
> > errors, like the timezone settings for gensky or the use of sin/cos
> > in the calculation of the luminaire distribution mesh. The only
> > think I can say is "it looks right". I won't discover these errors
> > on my own.

That's when alpha/beta testers are really useful!

> > Reproducing Radiance perspectives in Blender is too much work to be
> > worth the effort, I fear. The best approche would be to dump the
> > scene to a temporary directory and start a simple rvu window with
> > correct view settings. Optimization of geometry and view parameters
> > is possible, too.

That's exactly what b/rad does when starting the interactive display.

> > I prefer Blender preview renderings, though, because they don't need
> > temporary files. You never know what scenes those users are about
> > to edit ...

But doing the preview with rvu is important to know exactly what the
scene is going to look like.

> > > Any good book about daylighting includes the equations
> > > I've used, but you can use the python class I've written
> > > and maybe make it nicer. Most of the time I code in a hurry
> > > and don't have time write things nicely ...
> > > I could copy something tomorrow from my books at work, if you
> > > like ...
> > 
> > If you have a few good title for me that'd be great. I can get the
> > books from the library then (Hey, I'm an academic! I know there's
> > a library in town. ;).

I've forgotten to copy the pages of my daylighting reference book (in
Italian), but you can get an extensive text about how to calculate
the sun's position from here:

http://www.powerfromthesun.net/chapter3/Chapter3Word.htm

> > There again is the need for an angular fisheye perspective.
> > 
> > Imagine:
> >   
> >   Instead of the map display in gensky there will be a fisheye view
> >   of the scene (and sky). On that we can draw the sunpath with "glLine"s
> >   depending on the gensky settings. When you set a rotation the matrix
> >   of the image can be rotated, too. You just have to love the OpenGL
> >   state engine.

Nice idea.
I've been thinking also of drawing the sun path directly in the blender
3d view, with a few sliders on the python gui where you can select date
and time, and the sun position and maybe opengl shadows vary
accordingly ...

> > Oh yes: animation! Another can of pink and wriggling things
> > you don't want to have for dinner.
> > 
> > I haven't spent much time on render control yet because rad
> > does all I need so far. Basic camera animation could be supported
> > by simply exporting every camera position as a new view. A single
> > rif file is enough for multiple animations.
> > 
> > To export an animated object you have to decide whether the object data
> > is animated or only the position/rotation of the object. In the last
> > case you only have to create a new scene *.rad file while for other
> > animations the whole object has to be exported as well. This complexity
> > was one reason why I started to encapsulate the Blender objects in the
> > ExportObject class. How an object has to be exported should be left to
> > the objects "export" method.

My approach for walkthrought has been: use rad with multiple views.
My approach for animations with moving objects until now has been:
create a different folder for each frame, change the frame and
export the scene in the right folder, create a script to perform
the rendering with rpict ...

> > Still there are some logic and sanity checks to be done on scene level.
> > Simple cases of animation can be done with rad and ranimate alone. I'd
> > prefer not to invent a new animation description language to control the
> > rendering of all types of animation. Where the basic tools don't work
> > any more we still can write bash scripts, makefiles and throw-away
> > python scripts. That seems to be in the spirit of Radiance.

ranimove would be a big improvement in dealing with animations, I
think ...

> > Then again I don't know how popular animation is within the Radiance
> > community. If there are a few standard cases of animation (ie. sunpath)
> > support within the interface for that situation might be usefull for
> > others as well.

I've got separate scripts for time-of-the-day, shadows, sun-tracks
animations, it is very easy to integrate them as well ...

> > > Also, I've put some VTK export capabilities to
> > > post process the calculation results. If you get the
> > > last code from the CVS there is a vector illuminance
> > > function in the export module.
> > 
> > I always thought Blender would be fine for the post processing.
> > Semi-transparent geometry surrounding 3D-graphs or trace results,
> > free selection of viewpoint ...

You can do much more with VTK, volume rendering, show vector fields
with streamlines, integrate results from other simulations (CFD,
etc ...).

> > > Here is my TODO for b/rad, as you see many things
> > > could already be included using your code :)
> > 
> > Help yourself! If you're going to use any of the interface classes,
> > drop me a line. I'm still not happy with the separation of draw()
> > and setSize() methods so this will be changed soon and most likely
> > break any code using it.

I don't think I'll manage to work on b/rad again before the end of
September, anyway ...

> >    + make scripts "Blender Scripting Guideline" compliant

This is really a good idea, 

> >    + add "preferences" page to set and change paths etc. 

I've already added something similar, that saves all the data to a
config file.

> > >  - check platform independence
> >      => there are four major points to it:
> >      - use of path settings (Windows vs. Unix)

I'm solving it now with 
  if sys.platform=='win32':
     etc ...

> >      - presence of Radiance tools (do they work identical on Windows?)

Unfortunately they don't. It would be great to work on windoze versions
of rvu and ximage, so that the average windoze user is not forced to
install cygwin with its X server or to stick to the old Desktop Radiance
binaries ...

> >    - I'd really like to have a direct "mesh" primitive export for smooth
> >      meshes; but mesh.c code is so scary ... 

I'm allowing the user to chose whether to export xforms, instances or
meshes. Meshes also support vertex normals and UV texture coordinates.
It's simple to use the mesh primitives, just export to obj and run
obj2mesh ...


> >    + EULUMDAT support (if there is any advantage over IES)
> >      I have never seen a TM14 file; probably outdated

I would add Eulumdat but won't bother about TM14 ...

> > >  - add pdf report generation
> >      => depends on good report templates;
> >      Reportlab is a nice library for this (wanted to try it anyway ...);

I've started using reportlab, very nice and complete. I would absolutely
prefer it, and it can easily be placed in a subfolder as well ...

> >      conflicts with hand editing reports in ie. Word, though.

Didn't know about it, but who cares? ;) just kiddin'

> > >  - load and save project parameters
> >      => basics are there to store text in text objects; 2.37 has other
> >      improvements

Need to check what has been introduced. But configfiles are very easy
to be used, or maybe pickling ...

> > >  - extensively check that everything is fine with use of Blender
> > >    internal matrix management
> >      Blender seems to be inconsistent in it's use if parent/child
> >      relations are present in the scene.

In fact I've experienced those problems and gave up fixing the
export class. 

> >    + set up CVS/Subversion/wiki for documentation

I've got the CVS, the patch and task manager @ savannah

https://savannah.nongnu.org/projects/brad/

> > We'll just have to sort out some minor things:
> > - use CVS or Subversion
> > - who get's the fame, who the money ;)

Good question, well I'm already famous ... ;o)

> > Nevertheless: I'm glad to be back among penguins!

So, welcome back!

I think you will need to join the savannah community
to be able to join the b/rad project and access
the cvs with writing permissions.
Could you try this?

https://savannah.nongnu.org/account/register.php

Thanks.

Take care,

--
Francesco