--- Begin Message ---
|
Subject: |
Re: FW: Blender Radiance Interface II |
|
Date: |
Mon, 11 Jul 2005 14:24:01 +0200 |
|
User-agent: |
Mutt/1.5.6+20040523i |
Hi Francesco.
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).
On Sun, Jul 10, 2005 at 23:55:30 +0100, Francesco Anselmo wrote:
> Probably the biggest problem for merging the two projects
> would be deciding with interface to use ...
> Your one is more blender-oriented, i.e. non overlapping ...
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.
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.
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".
> It looks like it works nicely. I only had to change a couple
> of lines in InterfaceObjects.py to be able to see gensky
> and gendaylit in the Skies menu ...
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.
> It needs more checking, but it is a great starting point
> indeed!
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.
> > I'm already harvesting some of your code. I couldn't work
> > out how to calculate -vh and -vv correctly even after I had
> > a look at the source (...<whimper>...) so I picked the relevant
> > 3 lines from your code. Do you have a reference for this:
>
> > factor = math.sqrt(lens*lens + 16*16)
> > vh = 2 * math.acos(lens/factor) * 180.0/math.pi
>
> If I remember well, I took it from a message from Greg, and modified
> it a little bit to make it work better.
So "16" is a universal number for lens calculation? I do know (from a
comment in the sources) that a viewplane at 16 units distance has a
role in the calculation. I tried to reverse calculate vh and vv from
the view3D glFrustum but screwed up. _It looks right_ now, so one
headache less. I'll ask it on the Blender list when I annonce
exif there, too.
> > I found 3 different approches for this fov calculation, but
> > only your version looks like delivering the right values.
>
> This may well be luck ;)
> But I still want to include a "camera window" inside the b/rad
> interface, to make it possible to select angular, hemispherical,
> cylindrical and parallel view ...
The "cameras" page just cries for something in the right half of the
page. I wanted the preview to appear there in a fixed frame. Then
I discovered that I could calculate it on the fly in a popup window
and left it at that.
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.
I prefer Blender preview renderings, though, because they don't need
temporary files. You never know what scenes those users are about
to edit ...
> > You've posted a script to calculate sunpaths to the Radiance
> > list recently. I want do include this, too. Again I don't
> > know where the math comes from and I'd like to know how it
> > works. Do you know some literature about this I should read?
>
> 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. ;).
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.
> The Radiance community is not this big, but people
> from the blender one could get interested, especially
> because you're interface looks nice. The geo module
> is really sleek!
Only after I had reduced the colors severely, believe me!
There is still a lot of design work to do on that.
And will it be usefull to others as well?
> I could give you access to my CVS, if you like.
> We should really talk about integration or merging the
> two projects.
Any time. I planed to take a few steps back and review the
whole Radiance part of the interface now with the input
of the Radiance and Blender users. I have not looked at
your code in detail so I can not judge where there are
good interface points (interface: "API" not "buttons").
I'd be happy if we can use exif as framework and abstraction
for the Blender scene, where individual functions can "plug
in" to access and set values for the export. That would prove
the whole exercise. But judging from what I've seen so far this
is not the way Python is used in the Blender community. I'm
always happy to find a class defined instead of only functions.
> Your code is very easy to integrate, having the time.
> I think the main difference is that I've also been
> thinking about exporting animations, that's why I've
> preferred to export everything inside the same folder
> using the frame name and without nesting other
> folders. But using ranimate would improve the situation.
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.
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.
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.
> 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 ...
> 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'll spoil your list and add a few more items ;)
> - insert spotlight radiance multiplier
> - add an installation procedure
+ make scripts "Blender Scripting Guideline" compliant
+ add "preferences" page to set and change paths etc.
> - add camera settings window
=> I'm right on it; need's controls to select vh and vv and change
lens and image x,y accordingly
> - check layers and instance management (probably already working well)
> - fix calculation bug when object and grid mesh have a different name
> - check platform independence
=> there are four major points to it:
- use of path settings (Windows vs. Unix)
- presence of Python libraries ("try: import ...; except: foo")
- presence of Radiance tools (do they work identical on Windows?)
- Blender's platform dependent pitfalls
> - increase export flexibility (for instance some objects as meshes,
> some not ...)
- I'd really like to have a direct "mesh" primitive export for smooth
meshes; but mesh.c code is so scary ...
> - add analysis tools (falsecolor, picture export, glare analysis, etc.)
> - extend IES files support, photometry visualisation and basic library
=> consider it done (can be improved, of course)
+ EULUMDAT support (if there is any advantage over IES)
I have never seen a TM14 file; probably outdated
> - fix DXF output, adding a settings window and add it again to the menu
> - add Radiance import menu item and extend Radiance import capabilities
> - add external VTK export (improved with material colours and surface
> normals)
> - add external openDX export
> - add advanced (Makefile or batch file based) rendering, supporting
> mkillum, mkpmap, radzilla
> - add batch rendering option (render picture command)
> - complete material library management
> - add weather data management/selection
> - add radmap support
> - add holodeck support
> - add cubemap support
> - add lightmaps support
> - add ranimate and ranimove support
> - add an option to make a "sliced" view of the model based on the shape
> of the active selected object
> - add pdf report generation
=> depends on good report templates;
Reportlab is a nice library for this (wanted to try it anyway ...);
conflicts with hand editing reports in ie. Word, though.
Alternative: create XML/XHTML and use a postprocessor/stylesheet
> - load and save project parameters
=> basics are there to store text in text objects; 2.37 has other
improvements
> - 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.
> - write more tutorials and documentation
+ set up CVS/Subversion/wiki for documentation
> - make the code more "pythonic", adding docstrings, etc.
>
> I'm really happy you've started looking in the same direction,
> and would be glad if we can work together.
We'll just have to sort out some minor things:
- use CVS or Subversion
- who get's the fame, who the money ;)
- ...
I'm not sure wether exif is in a state to start a major code merge
yet. It should be worked out and stabilized more to avoid big rewrites
when a definition changes. Bits of code can "leak" any time of course.
> Also, I think that I'll need to switch to windoze to fix some
> issues, both because many people have asked to be able to use
> b/rad from windoze and because sometimes I need it too ...
Speaking as one who has spent 98 % of the working day in a Windows
environment for the last 2 years I can say: It's not that bad. But
I missed all the little tools I have in Linux (should install cygwin
sometime). Just stay away from Win9x and WinME.
Nevertheless: I'm glad to be back among penguins!
Thomas
--- End Message ---