[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Brad] FW: Blender Radiance Interface II
From: |
Thomas Bleicher |
Subject: |
Re: [Brad] FW: Blender Radiance Interface II |
Date: |
Wed, 13 Jul 2005 22:09:38 +0200 |
User-agent: |
Mutt/1.5.6+20040523i |
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