[Brad] Re: exif/brad

[Thomas Bleicher]

On Mon, Aug 08, 2005 at 23:19:48 +0000, Francesco Anselmo wrote:
> 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

My selfish reading of this would be:
  
  Realise only what's easy to do; leave complex tasks to scripts.

> 2. allow to export animations and to deal with parenting/constrains 
>    relations (export "all")

Blender has it and we can access it -- it's logical do do it.
(Nobody says it's easy.)

> 3. try to use the blender interface when possible, if not, extend
>    it with new functions within the export plugin

Radiance etc. support will not work without extensions or it would
be unnecessarily hard to realize. If there is a module or package to
do the job, use it!

A _general purpose_ interface (which I'm trying to create now) should
not require anything outside Blender; not even a Python installation.
I try not to import any external module before I'm creating Radiance
specific stuff.

> 4. be multiplatform, to make things easier for those poor windoze users

I tried exif.py on Windows XP on my Laptop. After very few changes
it worked (except the Radiance stuff which I don't have installed).
Platform independence is possible.

> 5. provide at least two levels of interaction (basic/advanced)

Novice/Expert/Guru modes. I'd hide extended options as long as the
user doesn't ask for them. Best example: rad options vs. rpict options.
But where there is no "higher level interface" like "rad" available it
all depends on reasonable defaults. Working with Radiance requires some
understanding of the programs. We can't replace that. All we can do is
wrapping complex tasks in one-click-actions in our interface.

> 6. i18n

I was thinking about that, too. Is there a user base that would
justify the effort? I don't think it would be difficult to realize,
so maybe let's do it anyway.

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

I don't think we have to provide a solution for all installations.
Let's start with a (flexible) interface to the standard distribution
and add more variations when they are actually needed. I'd like to
have Radzilla support, too. But first Radiance support should work
sufficiently then I'd try to extend it for Radzilla.

Some things may best be configured with some sort of .ini-file.

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

And there's a new one coming up! And Python 2.4 ...

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

I tried it. The interface started and I played around a bit until
it crashed :( I have to confess that the code didn't make much sense
to me (never got my head around globals) and when I saw something
like 

    if event == 34:
        ...

somewhere way down in the code I thought there has to be another
solution for this id handling.

Your windows largely have inspired my new layout (and of course the
use of menu buttons). I tried to make them moveable, too, but then
decided to have an easy to configure, non overlapping layout scheme
instead. The benefit is that ever user can create his/her layouts
according to their typical workflows and access them directly. I'd
like to add floatable/moveable frames in the future so you can have
both flexibility and accessibility.

Other ibilities will be satisfied with use and experience.

> The menu hierarchy is divided into logical areas:
[...]
> As you see, I haven't managed to develop everything, but this was the
> idea.

Nothing's more scary than an empty TODO list.

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

I had no convincing solution for a menu hierarchy. I made that
configurable as well so I don't have to think about it any more.


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

I hope Schorsch get's around to do that for us. The only reason why
I regret never having mastered C is that I can't play and patch the
Radiance code. Someday I will have to learn to create Python modules
to wrap up Radiance. It would be better to write interfaces etc. in
Python if you can use a library instead of duplicating C code in
Python (like scene file parsing).

> Among the other ideas I have are:
> - Add functions for modeling in an "architectural oriented way"
>   (wall, door, window, etc ...)

Heavy. This would require the idea of physical entities within the
scene structure.

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

I think it's the key to provide unified interfaces for postprocessing
tasks. OTH I don't see much reason not to use Blender as some sort
of toolkit (with integrated 3D package) once the interface frames
are created. Mostly these are limits of the embedded Python.

> I've also felt "alone" when writing to the bf-python ml, but people there
> are mainly interested into other things. 

And they should be! I don't care much about bones etc. in return.

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

Let's hope PAB get's his disk soon. At the end of the month I
should have broadband internet, too. Finally.

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

Something that tells you that the horizon is still where geopyhsics
put it and it was only you who held the camera wrong. Or something
like that ;)

Exif.py was not much of a name in the first place. I wanted to
rename it anyway. After all, the new code is a complete rewrite
and I like more poetic names (gives me a reason to crossread my
classics again).


Thomas