Following one man's task of building a virtual world from the comfort of his pajamas. Discusses Procedural Terrain, Vegetation and Architecture generation. Also OpenCL, Voxels and Computer Graphics in general.
Friday, May 18, 2012
Radiosity Screenshot
Here is a quick update on the radiosity. In this image there is only ambient light. Sunlight will make it more interesting for sure.
2h is bit too long, isn't possible add some short cuts? It would be possible to compute shadows for one tree and "copy" it to another? If trees aren't drastically different you should not see big difference. I think it could be possible if you store shadow in voxel block (to store volumetric shadows). Copy it for every tree, move to correct position. Then you can for every (x,y,z) test if it intersection with some block that are near and then sum shadows values form it.
An area of 1km by 1km is pretty big. This includes a fairly large mountainside and a dense forest. It is the same area shown in my earlier video. 2 hours to generate the light solution for each nook and cranny that you could potentially see is not much. For instance generating the geometry for this took around 12 hours (although I used fewer farm nodes).
Right, I forgot that how much time take to create geometry. I image that you try create 100 time bigger area and shadowing will take 200h but if creating same geometry will take around 600h then this isn't that big problem than I thought :)
When I saw this article (http://www.antisphere.com/Research/VolumetricBillboards.php) I had to thought about your project and if you might benefit from such a technique.
I read their paper a couple of years ago when I was considering to use volumetric rendering. I think it is OK for some applications, but cannot be used to render closer objects with accuracy, unless you increase the number of slices to absurd quantities. Like any technique that does discrete samples it has some serious aliasing issues, also the pixel overdraw is too high. It may be better to use those CPU cycles creating better shading. May be one of those techniques that forever will be a few years ahead of the times in terms of feasibility.
Drool... Nicely done. It shines coupled with real geometry, those washes of color on rocks and parts of tree trunks really stands out making the under-canopy very interesting!
One thing I'm curious about, since the radiosity mapping can be baked into things (because the general topography is pretty static) - is there a general approach that you will use to skew the actual color's being shown by the radiocity, as dawn/day/dusk/night cycles occur in the lighting engine? For instance do you program a general skewing from yellow/warmer to blue/cooler as the day progresses?
Also worth thinking about are the interesting things that occur to radiocity color during daytime thunderstorms (greenish), and overcast days (pale uniform grey).
I'm sure this is a problem you. and others. have already thought about in terms of what a lighting engine must do, but I'm a sucker for geeking out on color rendition :)
As you noticed, changing time of day or atmospheric conditions it is a problem for static lighting. One thing I am considering is to bake multiple illumination layers and interpolate between them. I could have night, dusk and day for instance and mix them depending on the actual time.
You might want to turn down the diffuse bounce back a notch as the green color bleed is overdone. Also a little more contrast in the textures would improve the final image a lot. A hint of SSAO might help. Keep up the great work, hope you'll post a new video soon!
Looks good, especially when I look at those trees bordering the little courtyard-ish place (open space). You can see the change from light to shadow there =D.
... Just ... Awesome !!! :)
ReplyDeleteHow long it takes to compute radiosity?
About two hours for the entire forest scene, which is 1km x 1km. I used four machines in the farm.
Delete... Just ... Awesome !!! :D
Delete2h is bit too long, isn't possible add some short cuts?
It would be possible to compute shadows for one tree and "copy" it to another? If trees aren't drastically different you should not see big difference. I think it could be possible if you store shadow in voxel block (to store volumetric shadows). Copy it for every tree, move to correct position. Then you can for every (x,y,z) test if it intersection with some block that are near and then sum shadows values form it.
An area of 1km by 1km is pretty big. This includes a fairly large mountainside and a dense forest. It is the same area shown in my earlier video. 2 hours to generate the light solution for each nook and cranny that you could potentially see is not much. For instance generating the geometry for this took around 12 hours (although I used fewer farm nodes).
DeleteRight, I forgot that how much time take to create geometry. I image that you try create 100 time bigger area and shadowing will take 200h but if creating same geometry will take around 600h then this isn't that big problem than I thought :)
DeleteWhen I saw this article (http://www.antisphere.com/Research/VolumetricBillboards.php) I had to thought about your project and if you might benefit from such a technique.
ReplyDeleteI read their paper a couple of years ago when I was considering to use volumetric rendering. I think it is OK for some applications, but cannot be used to render closer objects with accuracy, unless you increase the number of slices to absurd quantities. Like any technique that does discrete samples it has some serious aliasing issues, also the pixel overdraw is too high. It may be better to use those CPU cycles creating better shading. May be one of those techniques that forever will be a few years ahead of the times in terms of feasibility.
Delete* I meant GPU cycles
DeleteIncredible.
ReplyDeleteAlthough 2 hours seems a lot, i guess this is somehow baked into the final texture meaning that you only generate it only once right?
Correct, the light is baked into the models.
DeleteDrool... Nicely done. It shines coupled with real geometry, those washes of color on rocks and parts of tree trunks really stands out making the under-canopy very interesting!
ReplyDeleteOne thing I'm curious about, since the radiosity mapping can be baked into things (because the general topography is pretty static) - is there a general approach that you will use to skew the actual color's being shown by the radiocity, as dawn/day/dusk/night cycles occur in the lighting engine? For instance do you program a general skewing from yellow/warmer to blue/cooler as the day progresses?
Also worth thinking about are the interesting things that occur to radiocity color during daytime thunderstorms (greenish), and overcast days (pale uniform grey).
I'm sure this is a problem you. and others. have already thought about in terms of what a lighting engine must do, but I'm a sucker for geeking out on color rendition :)
Great work as always!
As you noticed, changing time of day or atmospheric conditions it is a problem for static lighting. One thing I am considering is to bake multiple illumination layers and interpolate between them. I could have night, dusk and day for instance and mix them depending on the actual time.
DeleteYou might want to turn down the diffuse bounce back a notch as the green color bleed is overdone. Also a little more contrast in the textures would improve the final image a lot.
ReplyDeleteA hint of SSAO might help. Keep up the great work, hope you'll post a new video soon!
Looks good, especially when I look at those trees bordering the little courtyard-ish place (open space). You can see the change from light to shadow there =D.
ReplyDeleteSo, what do you plan to do next?