Occlusion Shader...
Moderators: jesterKing, stiv
That is already how I did it, that is not the problem. Working on it, however, I have totally overlooked the fact (I suppose others already know about this, and Ton probably is laughing reading this thread) that Ton apparently already was experimenting with this, I just saw that there is already unused code for it in ray.c! Although it seems much more complicated than it needs to be, I haven't tested that code, would be interesting to hear from Ton why exactly it is unused. The comment in the code says it has something to do with recursion, but that should not happen unless he tried to do pathtracing, which might actually be the case... Well, well, in that case yafray will really be history...
Well, it's done, it is correct as far as I can see, no distances used yet, I did it another way which works ok too. Same link:
http://www.stormpages.com/eeshlo/hray/aotest.html
And that's it, more work to be done to make it a bit more versatile but I guess I'll better wait until I hear from anybody if they think if it's good enough to be included in Blender, until then, back to the work I was supposed to do...
http://www.stormpages.com/eeshlo/hray/aotest.html
And that's it, more work to be done to make it a bit more versatile but I guess I'll better wait until I hear from anybody if they think if it's good enough to be included in Blender, until then, back to the work I was supposed to do...
What's the speed on this? Is it a ray-trace type thing, with accompanying speed penalties (although I've been thrilled with the ray-shadow speed, especially on sunlight)? What's your sense on how it stacks up to the Yafray AO?
I think it looks nice, and if things could be set up to render the AO pass separately, or even to a fourth channel in targa files, it would allow some great tweaking flexibility outside Blender. This is useful - almost a one-click boost for the renderer in many situations. I say: "Put it in the cvs and let the world decide!"
I think it looks nice, and if things could be set up to render the AO pass separately, or even to a fourth channel in targa files, it would allow some great tweaking flexibility outside Blender. This is useful - almost a one-click boost for the renderer in many situations. I say: "Put it in the cvs and let the world decide!"
eeshlo: What method is this? Maybe it's some falloff setting you use, but the falloff looks a bit odd. I'm sure it's just a matter of tweaking settings.
It's quite important to composite the pass correctly too. A correct way of compositing it would be (iirc):
(Lighting + Ambient) + (AO * Ambient)
Actually, I'm not 100% certain about this, my memory could fail me. It is 4 AM after all ;o)
I'd love to hear more about your method, I'm very interested in this stuff.
It's quite important to composite the pass correctly too. A correct way of compositing it would be (iirc):
(Lighting + Ambient) + (AO * Ambient)
Actually, I'm not 100% certain about this, my memory could fail me. It is 4 AM after all ;o)
I'd love to hear more about your method, I'm very interested in this stuff.
cont...
Again... sorry for throwing a "wrench" in your current projectseeshlo wrote:but I guess I'll better wait until I hear from anybody if they think if it's good enough to be included in Blender, until then, back to the work I was supposed to do...

Like Macke, I too would love to play around with this... is there a way I can download a Blender version that has this in it to test and give feedback? I'm curious how your adding the layers... How's the overall speed? What about animation speeds?...
The second set of images you posted look great... the only thing I notice is a perfect horizontal break of "Dirt/Shadow" about a quarter of the way up on the pillars... not a smooth transition, almost a "line" where the shadows start/stop...
Again... if render times are looking good and a render with this quality and effect can be achieved, than I would think it should be in Blender....

_____SysAdm
-
- Posts: 442
- Joined: Wed Oct 23, 2002 2:47 pm
So what is going on in this sceen ? How was it made, with what lighting , how fast? Or is it all a hack ? If not then please share it so Blender can get faster and more powerful.eeshlo wrote:Well, it's done, it is correct as far as I can see, no distances used yet, I did it another way which works ok too. Same link:
http://www.stormpages.com/eeshlo/hray/aotest.html
And that's it, more work to be done to make it a bit more versatile but I guess I'll better wait until I hear from anybody if they think if it's good enough to be included in Blender, until then, back to the work I was supposed to do...
Looks good
Yafray hemilight currently does not do the exact same thing (although I updated it for comparison of course). It is raytracing yes, but still not as slow as you might think, depending on what you would find acceptable I guess..harkyman wrote:What's the speed on this? Is it a ray-trace type thing, with accompanying speed penalties (although I've been thrilled with the ray-shadow speed, especially on sunlight)? What's your sense on how it stacks up to the Yafray AO?
That would be twice the ambient lighting, I think that should be AO*ambient only. As there is no such ambient lighting in Blender (or at least I didn't use any) I just added the AO result as an approximation to that, which looks quite good (to me anyway). Note that unlike the AO only pass, the AO calculation also makes use of the bumpnormals, so you don't get a 'flat' result by just literaly adding the AO only pass as you can see.macke wrote: It's quite important to composite the pass correctly too. A correct way of compositing it would be (iirc):
(Lighting + Ambient) + (AO * Ambient)
As I mentioned before this could be extended to include something like a HDR diffuse map for ambient light for instance.
I haven't used the shader code, as I said, I already had partly coded this soon after the Blender raytracer was in cvs, otherwise I wouldn't have been able to do this so fast. Not that it is rocket science of course... Besides that, I have been doing similar things since about two years ago for my own raytracer.SysAdm wrote: Again... sorry for throwing a "wrench" in your current projects but I was excited to see the original shader's source code and knew if a Blender guru like yourself took a look at it, then something similiar would be possible in Blender...
AO is not really a very recent invention. There are more AO shaders/plugins available for various other renderers.
Not yet, I will first have to do some more work to make things more controlable and usable, then I will have to wait until I can get the current Blender compile problems sorted out, and then more waiting still, since this is not something I can just commit to cvs, I will have to submit this to Ton et al for review first, they then hack it to bits and if it is good enough will give the ok.. or not...Like Macke, I too would love to play around with this... is there a way I can download a Blender version that has this in it to test and give feedback?
There is no layers as such, I just adapted the code to render only the ao for the pictures. It is really just a single pass otherwise. And then I just add,sub,mult or whatever, will become user setting I guess...I'm curious how your adding the layers...
There is now another picture on the site (the very last one) of the AO only pass using the distances as well which probably looks more even and smoother.The second set of images you posted look great... the only thing I notice is a perfect horizontal break of "Dirt/Shadow" about a quarter of the way up on the pillars... not a smooth transition, almost a "line" where the shadows start/stop...
The rendertimes for the sponza picture with sunlight and added AO using 64 samples on my 1.4Ghz Athlon is 4 minutes and 20 seconds... you decide if it is good enough, can be optimized a bit further probably and depends on what sort of result you want, dirt or smooth AO, etc...How's the overall speed? What about animation speeds?...
It might also get a lot slower actually when using refraction/reflection, but didn't test this yet either.
edit: almost forgot, the part the yafray critics will really like to hear about, don't gloat too much, but yes, yafray is in fact much slower rendering the same scene...
"""""""""
nd I'm sure that once Green gets back to coding renderman support again for Blender that yafray probably will only be a vague memory.
""""""""
the renderman code that is in the tuhopuu cvs already has this implemented, (was infact one of the main things that made me want to write renderman support for blender)
the example images on your page look accurate to me, I would love to see this implemented into blender.
nd I'm sure that once Green gets back to coding renderman support again for Blender that yafray probably will only be a vague memory.
""""""""
the renderman code that is in the tuhopuu cvs already has this implemented, (was infact one of the main things that made me want to write renderman support for blender)
the example images on your page look accurate to me, I would love to see this implemented into blender.
-
- Posts: 35
- Joined: Sun Dec 15, 2002 10:52 pm
This is one of those things I've been looking into. I've been thinking extensively about how to improve the sequence editor and add a sort of node tree/custom render pipeline thing.harkyman wrote:I think it looks nice, and if things could be set up to render the AO pass separately, or even to a fourth channel in targa files, it would allow some great tweaking flexibility outside Blender. This is useful - almost a one-click boost for the renderer in many situations. I say: "Put it in the cvs and let the world decide!"
For example, what I'd like to be able to do is produce a diffuse, spec, ambient, z-buffer etc. from the renderer (all at once preferably to save processing the scene graph etc. every time) as separate images, and then use the sequence editor/node tree, to interactively composite those elements. Of course, if this could all work internally at floating point precision, that would be very nice indeed.
Professionally compositing separate passes in this manner is absolutely essential.
Check out this thread on elYsiun about Ambient Occlusion workflow in Blender:
http://www.elysiun.com/forum/viewtopic. ... on&start=0
http://www.elysiun.com/forum/viewtopic. ... on&start=0
cont...
Been there, read that... but if you read the whole post you will notice that technique does not work for interiors... look at eeshlo examples... (interior shots)arangel wrote:Check out this thread on elYsiun about Ambient Occlusion workflow in Blender:
http://www.elysiun.com/forum/viewtopic. ... on&start=0
Sounds brutaleeshlo wrote:I will have to submit this to Ton et al for review first, they then hack it to bits and if it is good enough will give the ok.. or not...

___SysAdm
Re: cont...
Well, it is more than an on/off switch, I mean, you do want some control over the result don't you?SysAdm wrote:... but hopefully this method will be a simple on/off switch in Blender or maybe even Ton has had this "idle" in the code waiting to be released...
And about the code already in Blender, although the comment says something about 'ambient occlusion', it is meant to do something completely different instead: emulating yafray's pathlight, so a form of raytraced GI. This is however really too slow to be useful in Blender. The comment in the code says something about recursion, this could be avoided though, but it would still be quite slow, just like using the brute-force pathlight in yafray (without cache).
(Besides that It also has a strange error, I would be surprised to see if it produced any result at all, still haven't tried it though...).
In any case, possibly, since last week at the last coder meeting when I talked to Ton about this, it could well have sparked some interest again, so maybe, who knows what Ton (or anyone else) is working on at the moment...
-
- Posts: 442
- Joined: Wed Oct 23, 2002 2:47 pm
Re: cont...
But you will at the very least release a test patch that we may all test for you when you are happy with the feature right ?eeshlo wrote:Well, it is more than an on/off switch, I mean, you do want some control over the result don't you?SysAdm wrote:... but hopefully this method will be a simple on/off switch in Blender or maybe even Ton has had this "idle" in the code waiting to be released...
And about the code already in Blender, although the comment says something about 'ambient occlusion', it is meant to do something completely different instead: emulating yafray's pathlight, so a form of raytraced GI. This is however really too slow to be useful in Blender. The comment in the code says something about recursion, this could be avoided though, but it would still be quite slow, just like using the brute-force pathlight in yafray (without cache).
(Besides that It also has a strange error, I would be surprised to see if it produced any result at all, still haven't tried it though...).
In any case, possibly, since last week at the last coder meeting when I talked to Ton about this, it could well have sparked some interest again, so maybe, who knows what Ton (or anyone else) is working on at the moment...