2.29: radiosity render!

General discussion about the development of the open source Blender

Moderators: jesterKing, stiv

macke
Posts: 24
Joined: Tue Oct 15, 2002 11:57 pm

Post by macke » Mon Sep 08, 2003 8:07 pm

As far as I understand this method, it saves color information as vertex colors. I have a suggestion for you code monkeys, other than actually rewriting the renderer to allow raytracing. Do not save the color information as vertex colors. Generate a uv map in which you associate a color with each vertex, and create a shader which can read this map and interpolate in between the values for the current pixel being rendered (tricky as far as I understand considering blender does not utilize raytracing, another reason for including it). One could define the maximum distance (along the surface) a vertex may reside for it to be included in the filtering. With this method you could still produce nice smooth transitions since you'd weight the surrounding information into one which would then be the radiosity value of that rendered pixel. It would also mean that the number of vertices required to produce a nice smooth value is greatly reduced. However, this is at the expense of accuracy, another reason why raytracing should be implemented. To be accurate the mesh must be refined (and no, subdivision surfaces is not a good method, however subsurf's should be tesselated and subdivided if proven necessary automatically by the calculation) which imo requires a quite smart system of subdividing the mesh evenly to avoid subdividing areas where the verticies of an object are very close to each other. This to produce a nice even result of the calculation.

All in all, my opinion (as a non-blender user might i add, so feel free to just ignore it) is implement raytracing and let go of hacks like this.

fligh
Posts: 31
Joined: Mon Dec 30, 2002 11:28 pm
Location: US

Post by fligh » Tue Sep 09, 2003 3:44 pm

Aw shucks! We just got done celebrating the departure of Thorax and now *you* reappear.

%<

cessen
Posts: 109
Joined: Tue Oct 15, 2002 11:43 pm

Post by cessen » Tue Sep 09, 2003 4:57 pm

A couple of ideas:

1) Use the interactive sub-surf level for radiosity calculations (which then would be interpolated over the additional vertices during actual rendering).

2) Radiosity could calculate only indirect lighting (use regular lamps and such for first bounce).

slikdigit
Posts: 133
Joined: Wed Oct 16, 2002 3:52 am
Location: Northampton, MA (US)

Post by slikdigit » Tue Sep 09, 2003 5:11 pm

those are interesting ideas cessen, and I have some questions: Don't you have to do direct lighting to calculate indirect? or do you mean something like setting the 'emit' value based on the amount of light recieved from the standard blender lamps?
As to subdividing I'm ignorant of the way its currently done-but I assume it doesn't change the shape of the mesh (like subsurf does). would using the subsurf level significantly slow down the render?

Landis
Posts: 0
Joined: Sun May 11, 2003 11:45 pm

Post by Landis » Wed Sep 10, 2003 12:13 am

macke,

Welcome to the community and thank you for your input...hopefully some of the programmers here can talk to you about your ideas.

cessen,

Your lamp comment is interesting, although, as I said before, I am not a programmer, so I am not sure how difficult this would be. Also, the more I think about it, this feature would be nice to people who want to use ther current lamp setup for a radiosity calculation, but it really isnt that difficult to setup a similar scene using light emiting objects (such as a plane). What I have found useful is to place these "emitters" on top of your tradtional lamps in the same scene but on another layer altogether with your "lightbox" (the room in which your scene is inside that is used to allow the light to "bounce" around). This way if you want to render using traditional lamps versus radiosity, you can do so simply by turning on/off the applicable layers. This also works nice for integrating various lamps with the radiosity calculation like I needed to do for the bump (Nor) mapping I used on the turkish vase.

By the way...before I forget...

To whom it may concern,

Would it be very difficult to impliment a way to name your layers so that when I mouse over them I see things like "lamps", "vase", "camera's", etc.? Maybe you already can and I am just a jackass :oops: . This would be nice to allow for me to append an entire layer later on, in addition to the current "single mesh" method. Anyways...moving right along....
slikdigit wrote:As to subdividing I'm ignorant of the way its currently done-but I assume it doesn't change the shape of the mesh (like subsurf does). would using the subsurf level significantly slow down the render?
Forgive me if your question is meant to be different than the way I understand it but here goes:

You are correct, subdividing the mesh does NOT change the...."contour" of the mesh by any means which subsurf does. "Subdivide Smooth" does change the contour of a mesh if I am not mistaken but not to the degree of subsurf. Subdivision basically multiplies the number of selected vertices by a determined percentage. The end result is a much more dense (more vertices) version of the original mesh. This is nice because of if the fact that it can produce a VERY smooth and detailed mesh and can be applied to exclusive areas of a mesh where as subsurf takes hold of the entire mesh, HOWEVER, subdivision is not very realistic for animating (not the rendering of animations, but the actual animation phase of a project). The render times included with this feature were not really as much of a concern as the results it yielded when it was first introduced I would think. Subsurfs are a little more tricky to work with (as you seem to already know). As with most tools you have to seem to know where you are going prior to jumping in the car in order to achieve optimal results. The most powerful features of subsurf is:

....its ability to simplify the modeling process by doing the hard work (organic modeling) for you.....

...and...

...its ability to tell blender to display an item at a certain level of subsurf (including "zero" :!: ) while animating and to render at another. This, to me, illustrates Blender's focus on the developement phase of a project (modeling, texturing, and especially animation) rather than the render times involved at the end. Blenders scanline renderer is already very fast and besides, any high quality rendering (subsurf's, cranked up AA, etc.) done prior to the "end" of a project is merely for pleasure and really isnt a very "productive" habit even though I often find myself very guilty of this :roll: .

Having said this, comparing the rendertimes of subsurf vs. subdivision, I guess would have to depend on the mesh, the level of subdivision, and many other factors. I would have to say that given the situation (a render match between the two methods) was setup as fair as could possibly be, subsurf would have to take the win I think. Maybe I am wrong...hopefully someone reading this can enlighten all of us about what exactly happens when a mesh has had subsurf applied to it. As far as subsurf slowing down a radiosity render, I havent really noticed a very big hit in terms of results versus rendertime...meaning that it takes a little longer but it would look like shit without it which would defeat the purpose of the whole thing altogether!

Again, I did not mean to insult your intelligence, so if I have I apologise. Nevertheless someone will find this useful. Anyways I have typed too much. Take care.

Cheers,
Landis

slikdigit
Posts: 133
Joined: Wed Oct 16, 2002 3:52 am
Location: Northampton, MA (US)

Post by slikdigit » Wed Sep 10, 2003 1:34 am

No Landis, you didn't insult me at all. I'm just curious what Cessen means. Right now I'm not sure but its possible that the subpatching used for the radiosity calculation is based on the base or level 0 mesh and not the subdivided mesh. (Unless I'm wrong and it works with the final). If what Cessen says is "use the final mesh, not the level 0 for the radiosity calculation and sub-patch that- well this means many more patches thus probably higher rendertimes and more accuracy. If what he means is use the catmull clark algorithm to sub-patch instead of the standard technique used by radiosity then this will result in higher accuracy and still not increase the rendertime (at least by much). I don't think I'm expressing my question very eloquently though....
PS I'm really enjoying playing with the radiosity render. Try putting an emitter behind a door and animate the door moving open and shut (from the darkside.) pure entertainment.

Landis
Posts: 0
Joined: Sun May 11, 2003 11:45 pm

Post by Landis » Wed Sep 10, 2003 4:40 am

slikdigit wrote:Try putting an emitter behind a door and animate the door moving open and shut (from the darkside.) pure entertainment.
lol....nice.....well put....what can I say.....lol. It seems thta you and I may have the same sickness.

sten
Posts: 177
Joined: Sun Oct 13, 2002 7:47 pm

Post by sten » Wed Sep 10, 2003 8:03 am

not to much to read, but on morning it is *yawns*

sorry landis! just much information to digest during morning ;)

btw landis, macke is not new to our community, oh well, he might have left it, but he is an former old Blender user :) and a very good one, one of the best I know :) especially when it comes down to effects :D

Goofster
Posts: 108
Joined: Mon Oct 14, 2002 12:26 pm

Post by Goofster » Wed Sep 10, 2003 10:46 am

ztonzy wrote:not to much to read, but on morning it is *yawns*

sorry landis! just much information to digest during morning ;)

btw landis, macke is not new to our community, oh well, he might have left it, but he is an former old Blender user :) and a very good one, one of the best I know :) especially when it comes down to effects :D
you're just saying that because he will kick your ass if you don't :)

ton
Site Admin
Posts: 350
Joined: Wed Oct 16, 2002 12:13 am
Contact:

Post by ton » Wed Sep 10, 2003 2:28 pm

Let's all adopt the civilized convention not to discuss or judge persons here. With Blender's turbulent past more people have slammed doors and left the stage, and later came back again.
Anyone with positive intentions and interest in Blender's development is welcome here. We're also mature and strong enough to bear with criticism, and respect people's opinions, even when they're not ours.

When there are troubles with individuals here, I'll contact them personally first, and solve things in private conservations. This is something I expect from everyone here; use email and IRC for personall matters.

-Ton-

ton
Site Admin
Posts: 350
Joined: Wed Oct 16, 2002 12:13 am
Contact:

Post by ton » Wed Sep 10, 2003 4:34 pm

Cessen:

having procedural subdivision levels for meshes is at the list. Madprof proposed to extend the blender effects system for it (and move out the particles to another location!). That also enables fractal stuff, displacement mapping, etc.

Using a 'second bounce' lighting only is interesting to enhance usage of traditional lights yes... but might require a lot of coding to have it working. The fact that radiosity allows real area lights is the most interesting part of this system now.

Landis:

Naming layers, and extending them with useful options is at the functionality agenda... we need someone to finalize it into a real proposal ready for coding.

Macke:

You propose to use what is called 'shadowmaps' in game engines. A simple texture map per face then can enhance the radiosity appearance a lot, plus it saves quite some memory. It is quite a huge project though to code it, and integrate with blender rendering, realtime display, and the radiositizer. If a developer likes to work on that, I'll be happy to review the approach and assist if needed.

The Yafray team worked on a raytrace approach (photons) for the same effect, which gives far superior results, with as obvious 'con' a rendertime issue. We work with them to have Yafray working smoothly with Blender.

cessen
Posts: 109
Joined: Tue Oct 15, 2002 11:43 pm

Post by cessen » Wed Sep 10, 2003 5:41 pm

It seems that in my attempt to be short and to-the-point, I ended up confusing everyone. Sorry about that.

To explain the 1st idea a bit better:
You know how subsurfs currently have two subdivision levels? The level for the 3d window (interactive) and the one for the final render. What I propose is that the radiosity calculation be done on the interactive subdivision level, and then when the final render is done (with the higher subdivision level), the per-vertex lighting information is interpolated across the additional vertices. This would allow for faster radiosity calculations while still allowing for smooth subsurfs.

To explain the 2nd idea a bit better:
My proposition was that direct lighting would be calculated the normal way (using lamps, spots, and shaders), and then the radiosity calculation would calculate the remaining bouncing of the light.

However, it occurs to me, based on the discussion after my post, that there is a better way to do it. The steps would be as follows:

1) Diffuse shaders will be evaluated at each vertex for regular Blender lamps (lamp, spot, hemi, sun).
2) Area light sources will be evaluated at each vertex of objects (no shaders, obviously).
3) All the recieved light at each vertex will be added together.
4) The radiosity solution will be evaluated.
5) The direct lighting from the shaders/lamps will be subtracted back out from the vertex lighting.
6) Final rendering will be done by adding the vertex lighting (interpolated) to the actual per-pixel evaluated shader/lamp direct lighting.

Conceptually, what this means is that the light from shaders/lamps will be taken into account for indirect lighting during the radiosity computation, but the direct lighting for the shaders/lamps will be rendered the normal way. That way, you get both direct and indirect lighting from both area-lights and lamps.

Does this make sense to anyone?

harkyman
Posts: 98
Joined: Fri Oct 18, 2002 2:47 pm
Location: Pennsylvania, USA
Contact:

Post by harkyman » Wed Sep 10, 2003 6:13 pm

cessen: I like your implementation suggestion. Combining direct and indirect lighting (i.e. normal lamps as first bounce.)

I know that Ton said it was a difficult code undertaking, but this would, in my view, be the most useful way to use the radiosity. You set up your normal blender scene, do all of your work, and then, at the end, turn on the radio for the extra realism of indirect lighting.

ton
Site Admin
Posts: 350
Joined: Wed Oct 16, 2002 12:13 am
Contact:

Post by ton » Wed Sep 10, 2003 9:47 pm

cessen wrote:T
1) Diffuse shaders will be evaluated at each vertex for regular Blender lamps (lamp, spot, hemi, sun).
2) Area light sources will be evaluated at each vertex of objects (no shaders, obviously).
3) All the recieved light at each vertex will be added together.
4) The radiosity solution will be evaluated.
5) The direct lighting from the shaders/lamps will be subtracted back out from the vertex lighting.
6) Final rendering will be done by adding the vertex lighting (interpolated) to the actual per-pixel evaluated shader/lamp direct lighting.
Interesting concept! But... the radiosity system doesn't work with vertices or interpolate it. It works with faces only, and uses an energy-per-surface calculation. The area of the face also is taken into account. It's 'integral math' if that term is familiar. Only in the very end, this energy then is accumulated to the vertices, for smooth Gouraud interpolation.

Nevertheless, the regular lamps also could take part in the energy distribution. Each face then should store separately what energy it received from lamps, to subtract that from the final calculation.

Interesting! :)

cessen
Posts: 109
Joined: Tue Oct 15, 2002 11:43 pm

Post by cessen » Thu Sep 11, 2003 4:40 pm

ton wrote:Interesting concept! But... the radiosity system doesn't work with vertices or interpolate it.
Oh! Of course. I feel silly, now. (I knew that already, but for some reason was thinking in terms of vertices.) Just replace all the words "vertex" or "vertices" with "face" and "faces". :-)
ton wrote:It's 'integral math' if that term is familiar.
Yes. I've taken calculus (and I've also taught myself set theory and a good deal of linear algebra). I am fairly well versed in advanced math--not yet topology or advanced statistics, but I'm working on it. ;-)
ton wrote:Interesting! :)
Thanks! :D

Post Reply