Re: [Brad] FW: Blender Radiance Interface II

[Thomas Bleicher]

On Wed, Jul 13, 2005 at 00:46:48 +0100, Francesco Anselmo wrote:
> 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 ...

For an easy navigation (without having to read a manual) I like
to have logical groups of functions accessible everywhere. Right now
I can think of this structure:

* Data: luminaires, material, views/cameras, fields
* Skies: gensky, gendaylit, mappings, sunpath
* Options: rad, rpict, oconv, pfilt
* Evaluation: postprocessing, reports, ... 
* Export: summary and "Export" button(!), selection, animation
* Settings: profiles, config, library management

Where only one option is possible (gensky or gendaylit) menus are
great. Else I'd like to keep a "visual presence" of this function
(button) on the screen for an easy orientation.

> Well, the main reason to keep using Blender is because it enables
> to directly work with the model without re-inventing the wheel.

ACK.

> > > 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.

Blenders preview is good enough (and quick) to check the viewpoint.
Should work with cylindrical views, too (panorama).

BTW: I figured out how the fov calculation works. 

    ## the lens value is the distance to a plane that would
    ## yield 32 units along the major image dimension (x or y)
    ## or 16 units for one half of the image:
    ##  
    ##     - +           Thus we can calculate angle a:
    ##       |\  
    ##       | \           a = atan(16/lens)
    ##       |  \     
    ##   16u |   \       fov for the larger dimension:
    ##       |    \       
    ##       |     \       a = fov/2
    ##       |    (a\      fov = 2 * atan(16/lens)*180/pi
    ##     - +------->[] 
    ##
    ##       | lens  |
    ##
    ##                                             q.e.d.

Fisheyes, material and luminous situation have to be checked in rvu.

> 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

Meglio cosi! Sono anni che ho letto un libro in italiano ...

Thanks for the link.

> 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 ...

I think you can't draw into the 3DView window. You'd have to create a
mesh and set the material to "wireframe" or something. Or you could
try to create a backdrop image for the "world" settings ("writing in
the sky ...").

> My approach for walkthrought has been: use rad with multiple views.

ACK.

> 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 ...

This would create a lot of duplicates of identical objects. A folder
for each animated object and exports with frame extension might be
better to understand. Ranimate should be able to work with that
as well as far as I have seen in the man page.

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

Perhaps we can create a "standard library" for Radiance evaluations
that can be used by others as well (independend of Blender). I don't
know if there's a point, though. They will have to interact with the
modeler for the export and everything else may not be that spectacular
(example to prove me wrong: sunpath :).

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

That's how computers should be used:
dusty in summer, rusty in winter ;)

> > >    + make scripts "Blender Scripting Guideline" compliant
> 
> This is really a good idea, 

We won't get rid of the dependencies, but menu integration should
work.

> > > >  - 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 ...

The problem is to know _when_ to check for differences. I fear we'll
have to (let others) try and crash ;)

> 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 ...

That's the way to go until I'm the C guru I want to be (don't hold
your breath).

> 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 ...

Any ideas _what_ to report or how reports should look like?

> 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/

[...]
 
> https://savannah.nongnu.org/account/register.php

I'll check it.


Thomas