Animated radiosity?

General discussion about the development of the open source Blender

Moderators: jesterKing, stiv

Post Reply
LethalSideParting
Posts: 71
Joined: Mon Oct 21, 2002 12:53 am
Location: Bucks, England

Animated radiosity?

Post by LethalSideParting »

Hiya there guys.
I remember the days when discussion was rife on the Blender.nl boards about implementing radiosity for every frame (as opposed to 'calculate once', 'render animation', 'curse at improper lighting effects that turn up when objects move but their colour bleeding doesn't'.

Since we've got the sources now, would it be difficult to add a button to the render options where you can activate a radiosity calculation in between rendering each frame? I'm sure at lot of artists would appreciate it, and I can't believe it's that difficult to do...

Thoguhts?

LethalSideParting

noid
Posts: 5
Joined: Wed Oct 16, 2002 7:14 pm
Location: Joroinen, Finland
Contact:

Post by noid »

Maybe the current radiosity system could be extended like this:
After the radiosity calculation is done (and objects are subdivided & vertex colored accordingly), a cube map of each object is rendered into a texture. Then the textures are mapped onto the original (non-subdivided) objects as if they were normal environment maps.

This way the radiosity calculation would not ruin your original meshes by adding a gazillion polygons to them, and you could recalculate the radiosity in the next frame since you'd still have the original meshes intact.

I hope that made any sense :-)

joeri
Posts: 96
Joined: Fri Jan 10, 2003 6:41 pm
Contact:

Post by joeri »

Radiosity also calculates lights and shadows, so if you have moving objects in your scene you need to recalculate each frame.
This does not need to be a problem, even in the current blender a "press the right buttons" hack could make animated radio possible.

z3r0_d
Posts: 289
Joined: Wed Oct 16, 2002 2:38 am
Contact:

limitations

Post by z3r0_d »

If future versions of blender were to support radiosity on animations some things would have to be changed.

First, radsioty (for speed reasons) should not be calculated for every time a frame is rendered. Not that I mean not for every frame, but motion blur (which renderes frames more than once) would be murder if the radiosity were calculate per each render of the frame.

Part II , (and this is probably why it hasn't happened, and will not)
the subdivision of surfaces when radiosity is calculated would have to remain constant over the animation. Since each new element (I believe they can recieve light), for fast radiosity calculation are larger than what would be one pixel on screen, the movement of shadows will appear odd as they jump across elements. To fix this would require a smaller ElMax which would increase render time, making per-frame radiosity useless

Use another renderer if you want something mathematically correct results. (a raytracer most likely)

... If you feel like it you can use blender 2.04 to initate the radiosity calcuation (in python), and probably there is some uicontroller that can simulate mouse clicks, and keypresses in python (I have heard of one for X, but know of none, having not looked, for windows), to press the replace meshes button, the free radio data button, and stuff, to render and save an image.

RipSting
Posts: 5
Joined: Wed Nov 27, 2002 1:58 am
Location: Oregon, USA
Contact:

Post by RipSting »

So I've been thinking about this...

The reason Blender subdivides all your meshes is because it uses vertex paint to do all the lighting and coloring. HOWEVER, if it started out with a big black UV texture, it might be possible to do the whole radiosity routine by 'drawing' the light in UV "Texture-Paint mode".

You'd need to allocate a portion of the UV texture to each polygon (depending on how large the polygon's area is), and then access the UV TexturePaint code. Sure it's possible, but it would require a complete re-write...

Does this seem like a feasable solution?

z3r0_d
Posts: 289
Joined: Wed Oct 16, 2002 2:38 am
Contact:

*CRINGE*

Post by z3r0_d »

That would be (in the fewest words possible)

SLOW!

blender does radiosisty on vertex colors because it is MUCH faster, working on a texture would reduce the speed to the point where another renderer would be more efficent.

Jamesk
Posts: 239
Joined: Mon Oct 14, 2002 8:15 am
Location: Sweden

Post by Jamesk »

Another reason to use vertex colors is the resolution-independent nature if it. Using some kind of UV-map method would require an enormous texture if one didn't want to end up with interpolation artefacts a la realtime game graphics.

hannibar
Posts: 50
Joined: Wed Oct 16, 2002 3:02 pm

Post by hannibar »

My request would be that you could choose to bake a texture using UV.
Would be very nice for the game-engine too.

Dani
Posts: 143
Joined: Fri Oct 18, 2002 8:35 pm

Post by Dani »

I agree that UV baking would be a nice solution. And I don't think you really need such a huge texture. You could work on a per-surface basis, with an angle tolerarance and edge detection to determinate where (at which existing edge) the surface should be stopped. then generated a homogene resolution map for this surface, and bake the radioinfo onto it... and move on...

no?

Dani

hannibar
Posts: 50
Joined: Wed Oct 16, 2002 3:02 pm

Post by hannibar »

And if possible, not only radiosity, but also baking procedurals on an image using the UV mapping. And being able to bake several textures into one texture map.
...maybe I'm dreaming.

Post Reply