|
ZsquaredplusC
Guest
|
 |
« on: December 28, 2009, 04:16:57 AM » |
|
I have been playing with ambient occlusion. Currently using the "official" slow method of shooting a hemisphere of rays from the surface point and using the unrestircted ray count to darken the location. This looks good but the 50x slowdown for 50 rays (which is almots the bare minimum as it shows a lot of grain) is painfull. I saw iq's examples of using an orbit trap to fake AO, but the description was not too clear. Can anyone clarify? Or even give a quick snippet of source code to help me out? You have a 3D point trap at the origin. So each iteration you compare Z to the trap distance and...  Thanks for any tips. |
|
|
|
|
Logged
|
|
|
|
|
David Makin
|
|
« Reply #1 on: December 28, 2009, 02:30:27 PM » |
|
I have been playing with ambient occlusion. Currently using the "official" slow method of shooting a hemisphere of rays from the surface point and using the unrestircted ray count to darken the location. This looks good but the 50x slowdown for 50 rays (which is almots the bare minimum as it shows a lot of grain) is painfull. I saw iq's examples of using an orbit trap to fake AO, but the description was not too clear. Can anyone clarify? Or even give a quick snippet of source code to help me out? You have a 3D point trap at the origin. So each iteration you compare Z to the trap distance and... Thanks for any tips. |
|
|
|
|
Logged
|
|
|
|
|
subblue
|
|
« Reply #2 on: December 28, 2009, 04:39:52 PM » |
|
In my PixelBender renderer I'm using two methods. The first is the same as Makin has pointed out, using the smallest magnitude of the distance of Z from the origin at each iteration as the darkening factor. The second uses the ratio of the number of steps taken to reach intersection and the total number of steps allowed. Since the step size is determined by the distance estimation function the more occluded areas will require a greater number of smaller steps before the ray intersections the fractal surface. Shading the surface based on on the number of steps taken really helps define the edge details and when used in combination with the orbit trap shading adds a significant visual improvement with practically no overhead. The differences of each are illustrated by the images below: Orbit trap AO:  Step count AO:  How the different shading components combine together; orbit-trap AO, step count AO, combination, with Phong, with ray-traced shadows:  |
|
|
|
|
Logged
|
|
|
|
|
David Makin
|
|
« Reply #3 on: December 28, 2009, 05:33:14 PM » |
|
In my PixelBender renderer I'm using two methods. The first is the same as Makin has pointed out, using the smallest magnitude of the distance of Z from the origin at each iteration as the darkening factor.
The second uses the ratio of the number of steps taken to reach intersection and the total number of steps allowed. Since the step size is determined by the distance estimation function the more occluded areas will require a greater number of smaller steps before the ray intersections the fractal surface. Shading the surface based on on the number of steps taken really helps define the edge details and when used in combination with the orbit trap shading adds a significant visual improvement with practically no overhead.
Using the number of steps taken is an interesting idea but I believe it's somewhat flawed in that it will not stay constant as the viewpoint changes so on animations it will introduce a form of aliasing that will be hard to remove. Having said that a user-configurable option for it for doing high-quality stills is probably a good idea  |
|
|
|
|
Logged
|
|
|
|
|
subblue
|
|
« Reply #4 on: December 28, 2009, 05:39:26 PM » |
|
Using the number of steps taken is an interesting idea but I believe it's somewhat flawed in that it will not stay constant as the viewpoint changes so on animations it will introduce a form of aliasing that will be hard to remove. Having said that a user-configurable option for it for doing high-quality stills is probably a good idea From the animations I've created I haven't seen aliasing artefacts due to the step-count AO: <![CDATA[<a href="http://vimeo.com/moogaloop.swf?clip_id=8148760&amp;server=vimeo.com&amp;show_title=0&amp;show_byline=0&amp;show_portrait=0&amp;color=2391BB&amp;fullscreen=1" target="_blank">http://vimeo.com/moogaloop.swf?clip_id=8148760&amp;server=vimeo.com&amp;show_title=0&amp;show_byline=0&amp;show_portrait=0&amp;color=2391BB&amp;fullscreen=1</a>]]> |
|
|
|
|
Logged
|
|
|
|
|
David Makin
|
|
« Reply #5 on: December 28, 2009, 05:50:41 PM » |
|
Using the number of steps taken is an interesting idea but I believe it's somewhat flawed in that it will not stay constant as the viewpoint changes so on animations it will introduce a form of aliasing that will be hard to remove. Having said that a user-configurable option for it for doing high-quality stills is probably a good idea From the animations I've created I haven't seen aliasing artefacts due to the step-count AO: That's surprising Is that anim using step-count AO only ? Is there no problem when moving sideways ? What do you mean by "total number of steps allowed" in your description of the algorithm ? |
|
|
|
|
Logged
|
|
|
|
|
subblue
|
|
« Reply #6 on: December 28, 2009, 06:53:24 PM » |
|
The animation is using a blend of the orbit-trap and step count AO. However, just using the step count AO still gives smooth flickr free shading when the camera translates.
The total number of allowed steps is a threshold value for the raytracing process. If the ray tracing for a pixel reaches this number of steps then the ray will be aborted and the pixel will use the background colour. The parameter is the stepLimit in my PixelBender script. Provided this value is kept the same throughout the animation then shading will be consistent between frames.
|
|
|
|
|
Logged
|
|
|
|
|
David Makin
|
|
« Reply #7 on: December 28, 2009, 07:23:08 PM » |
|
The animation is using a blend of the orbit-trap and step count AO. However, just using the step count AO still gives smooth flickr free shading when the camera translates.
The total number of allowed steps is a threshold value for the raytracing process. If the ray tracing for a pixel reaches this number of steps then the ray will be aborted and the pixel will use the background colour. The parameter is the stepLimit in my PixelBender script. Provided this value is kept the same throughout the animation then shading will be consistent between frames.
There is a potential problem with that idea - if a ray travels on a path very close to a parallel surface then all the step distances will be very small and limiting the steps would end up colouring as the background even if further on along the ray a surface is encountered - this will have the effect of leaving thin slivers of background where some surfaces overlap. This problem is probably most likely to occur on Julia Sets. |
|
|
|
|
Logged
|
|
|
|
|
subblue
|
|
« Reply #8 on: December 28, 2009, 07:30:34 PM » |
|
There is a potential problem with that idea - if a ray travels on a path very close to a parallel surface then all the step distances will be very small and limiting the steps would end up colouring as the background even if further on along the ray a surface is encountered - this will have the effect of leaving thin slivers of background where some surfaces overlap. This problem is probably most likely to occur on Julia Sets.
Absolutely, but IMO it is worth it to keep the rendering as interactive as possible. By default I set the step limit to about 110 but it can be increased as required, which is often the case to resolve the far side bulbs in the Juliabulb renders. |
|
|
|
|
Logged
|
|
|
|
|
David Makin
|
|
« Reply #9 on: December 28, 2009, 07:40:01 PM » |
|
There is a potential problem with that idea - if a ray travels on a path very close to a parallel surface then all the step distances will be very small and limiting the steps would end up colouring as the background even if further on along the ray a surface is encountered - this will have the effect of leaving thin slivers of background where some surfaces overlap. This problem is probably most likely to occur on Julia Sets.
Absolutely, but IMO it is worth it to keep the rendering as interactive as possible. By default I set the step limit to about 110 but it can be increased as required, which is often the case to resolve the far side bulbs in the Juliabulb renders. Unfortunately that's the sort of optimisation that's inefficient for rendering using the CPU/FPU - it would almost certainly take more time to get the optimum max step count than the time doing so would actually save However I like the occlusion method so I think I'll try something similar but based on the distance estimate distances rather than the number of steps - I need to find a method where the user changing the "accuracy" parameter (which scales the actual steps taken) will have little or no effect on the ambient occlusion. |
|
|
|
« Last Edit: December 28, 2009, 07:44:45 PM by David Makin »
|
Logged
|
|
|
|
|
Buddhi
|
|
« Reply #10 on: December 28, 2009, 07:42:56 PM » |
|
I have some interesting suggestion. DE step count you can use for generate glow effect. I attached some example.
|
|
|
|
Logged
|
|
|
|
|
subblue
|
|
« Reply #11 on: December 28, 2009, 08:55:35 PM » |
|
Unfortunately that's the sort of optimisation that's inefficient for rendering using the CPU/FPU - it would almost certainly take more time to get the optimum max step count than the time doing so would actually save The maximum step count is set the same for all pixels and is just defined as a parameter constant so there is no need to try and calculate the optimum value and so adds no overhead at all It would be pointless to try and calculate the max step count as you would in effect have to render each point first! |
|
|
|
|
Logged
|
|
|
|
|
David Makin
|
|
« Reply #12 on: December 28, 2009, 09:18:01 PM » |
|
Unfortunately that's the sort of optimisation that's inefficient for rendering using the CPU/FPU - it would almost certainly take more time to get the optimum max step count than the time doing so would actually save The maximum step count is set the same for all pixels and is just defined as a parameter constant so there is no need to try and calculate the optimum value and so adds no overhead at all It would be pointless to try and calculate the max step count as you would in effect have to render each point first! Except that as you said, for Julias you have to increase the value to render correctly - if I included any maximum step count then adjusting the value until the render works using that value without errors on all stages of an animation (without simply setting the parameter to a very large value) would take so long as to make the option useless. In addition if the user changed the "accuracy" parameter (i.e. re-scaling *all* the actual step sizes used) then the max step count and any parameters for the ambient occlusion based on the number of steps would also need changing. |
|
|
|
|
Logged
|
|
|
|
|
David Makin
|
|
« Reply #13 on: December 28, 2009, 09:39:35 PM » |
|
<snip>
However I like the occlusion method so I think I'll try something similar but based on the distance estimate distances rather than the number of steps - I need to find a method where the user changing the "accuracy" parameter (which scales the actual steps taken) will have little or no effect on the ambient occlusion.
I've decided not to bother, as far as I can see viewing the same spot will change brightness as you rotate when using the steps taken - when the ray is perpendicular to the spot then it will appear brighter than at other angles. |
|
|
|
« Last Edit: December 28, 2009, 09:41:10 PM by David Makin »
|
Logged
|
|
|
|
|
gaston3d
Guest
|
|
« Reply #14 on: December 28, 2009, 10:00:09 PM » |
|
I have some interesting suggestion. DE step count you can use for generate glow effect. I attached some example.
nice. glowing fog and subsurface scattering like effect in upper left quarter. |
|
|
|
|
Logged
|
|
|
|
|
August 08, 2010, 01:23:38 PM
Dilber MC Theme by HarzeM