[Brad] exif/brad

[Francesco Anselmo]

Hi Thomas,

> Before recoding/adding lots of features we should discuss a concept
> for the basic framework (interfaces, layout elements, scene structure
> etc.) to help us in structuring the code and work around some
> shortcomings of the Blender API. 

I think all your work on the interface and on writing good re-usable
classes really opens a good possibility to split the work in an easy 
way and to speed up development consistently.

The main design principles I've used when I've started to code
brad were:

1. try not to sacrifice too much the Radiance versatility with the GUI
2. allow to export animations and to deal with parenting/constrains 
   relations (export "all")
3. try to use the blender interface when possible, if not, extend
   it with new functions within the export plugin
4. be multiplatform, to make things easier for those poor windoze users
5. provide at least two levels of interaction (basic/advanced)
6. i18n

I still feel like I've failed is some areas, for instance I've recently
fixed parenting, but broken instancing, or brad doesn't take into
account all the possible scenarios for windoze users (use of cygwin 
binaries, use of desktop radiance binaries, etc.).
Also, the everchanging Blender API has contributed to my constant
frustrations. The situation is better now, but bf-python developers
always change something here and there in a non back-compatible way.

I don't know if you've tried to use brad. I've designed it as a
small application within blender, with movable windows and drop-down
menus. The menu hierarchy is divided into logical areas:
Program: for program related functions (exit, change preferences)
Import/export: self-explaining
Libraries: display and deal with material, luminaires, object, weather
data libraries
Simulation: setup and manage Radiance simulations (location, time of the
day and of the year, skies - with or without hdr mapping, rpict, rview,
rtrace, maybe rtcontrib, with or without rad, with or without mkillum,
rholo, texture baking, ranimate, ranimove, sun path diagrams, etc.)
Analysis: functions for managing and displaying pictures, animations,
calculation grids, plots, reports, etc.
As you see, I haven't managed to develop everything, but this was the
idea.

I still think this subdivision is making sense, at least from my
perspective as a user and lighting designer.

I also think that an up-to-date window/unix version of rview (using
wxWidgets) is long overdue, and may be added to the scope of our
efforts, together with a tailored wxPython/VTK/openDX post-processor,
that shows the results in an interactive way.

Among the other ideas I have are:
- Add functions for modeling in an "architectural oriented way"
  (wall, door, window, etc ...)
- GUI for energyplus and/or esp-r

> That's the picture. Last night I even thought a step further:
> all elements are basically OpenGL primitives. It should be possible
> to abstract the Blender interface with a moderately thin wrapper.
> That would allow the use independent of Blender except for the
> scene related functions. So far, there are no others, though.

The idea is good indeed, I particularly like the attitude of
making things general.

> With all our functions, options, visualizations and whatnots
> I thought it would be better to have an easy way to combine
> basic elements to more complex layouts: Don't do all the
> sky parameters at once but use one frame/class for time, one
> for location, one for options etc.

This agrees very well with providing different levels of interaction
(easy, advanced).
 
> > Thanks for sharing your work, I think it could be really appreciated by
> > the bf-python community.
> 
> So far the feedback was ... low. I think I'll have to answer my
> questions on my own. I may not have found an answer but I have
> pretty good workarounds!

Well, so far you're one of the few who has expressed interest in this area
and the only one who has done something similar :)
I've also felt "alone" when writing to the bf-python ml, but people there
are mainly interested into other things. 

> PS: Are you going to the workshop next week? I won't be there
> and I don't think I'll have something to show off ready in time.
> Nevertheless, new ideas and feedback would be welcome.

Unfortunately I'm not going to Montreal in the end, there will be
many interesting software demonstrations, and I'm sure the cdrom
will be extremely interesting.

BTW, about the name of your little creature, do you know what
an EXIF header is?

Thanks for all your feedback, this discussion may become really
useful.

Francesco