I've noticed the bagginsbill shadow catcher doesn't seem to work with IDL. Perhaps it's me who make an error somewhere, but i'm unable to have good results using it and IDL...

Oh, and Bill, you've talked some times ago about a sort of volumetric effect shader, something you've applied to a sphere to get that sort of magical spelling effect, could you talk more about it? :)

My Store

Please, tell me why i haven't thought about that... O_O
Will try and tell you :)

My Store

Oops, I deleted my post. I'm doubting myself now, as to whether it did use an AO node at all, or whether I'm making that bit up.

"If I were a shadow, I know I wouldn't like to be half of what I should be."
Mr Otsuka, the old black tomcat in Kafka on the Shore (Haruki Murakami)

Just a second thought: should it be possible to have a shadow catcher that works with IDL shadows instead of AO shadow?
Since the arrival of IDL into Poser, i never use AO anymore.

My Store

PoserPro 2010 now takes the AO node under consideration when applying IDL.

do you have poser pro 2010?

Quote - PoserPro 2010 now takes the AO node under consideration when applying IDL.

It does if you tick the 'Evaluate in IDL' checkbox on the AO node (default is unticked). That's what was in my deleted post, but VB was too quick for me!

Edit: isn't this the same in Poser 8? I thought it was...

"If I were a shadow, I know I wouldn't like to be half of what I should be."
Mr Otsuka, the old black tomcat in Kafka on the Shore (Haruki Murakami)

look IBL didnt cast shadows. with IDL you get soft shadows where you can not predict what will happen. with IDL almost everything can have a shadows.

its hard if not impossible

Actually it's not possible under P8 or 2010 ( IDL) the better way is render shadows separatly ti use them under your favorite 2S software

@IsaoShi, evaluate in IDL dont work too, shadow catcher meterial come with two materials, with and without AO, both dont work, use layer, you have better results !

Génération mobiles Le Forum / Le Site

 

Many different sub-topics are flying here.

There is a version of the shadow catcher that includes an AO node. That was for getting AO shadows caught when you did not use light-based AO.

With IBL + light-based AO, that version was not needed. The simple one that just uses Diffuse node alone as its sensor was sufficient.

With IDL, we have a problem. Actually two problems. If you also are using render GC we have three problems, one of which was always there even without IDL, but it's worse now.  I don't see an easy solution to these.

First problem:

During IDL pre-calc, when the irradiance cache is being populated, all direct illumination is excluded. The values coming out of the Diffuse node are only what is produced by secondary lighting. Ignoring occlusion for the moment, the secondary lighting is entirely what is in the shadows.

Now the shadow catcher is trying to detect whether a given spot on the ground is getting only secondary illumination, or primary and secondary illumination. But during precalc, there is NO primary illumination being detected. So during precalc, the entire ground is "in shadow". Therefore, the entire ground will be opaque!!!

This leads to the second problem. The IDL pre-calc, seeing that the ground is opaque, will use the luminance of the ground as part of its lighting calculation. The "under" sides of props and figures will be under lit. (pardon the pun)

But when the final render is done, the direct illumination will be detected, and the ground will become transparent over most of its surface. Thus, whatever was under/behind it will be revealed, but that is not what was used in the lighting pre-calc. Things will look wrong.

Another problem is the calibration step. During calibration, the entire surface is opaque, and to calibrate it correctly, you're trying to measure the illumination of the directly lit areas and the shadowed areas and load those into the shadow catcher. But the calibrating ground will produce a lot of bounced light!!! Worse - it will be 100% reflected diffuse illumination, which you should know by now is a no no. This will illuminate other surfaces, which in turn will re-illuminate the ground again. So, by indirection, the ground is illuminating itself (if you have 2 bounces or more) and the measurement it is getting during pre-calc will be different than the measurement it gets during the render, when the ground is essentially not there.

Another problem with calibration is if the illumination of the ground is very high, which it often is in an outdoor scene with a very bright envsphere and a sun. The purpose of the calibration step is to sample the lit and unlit values. But the lit value can be greater than 1, as measured by a white Diffuse node with Diffuse_Value = 1. This problem is easily solved however. Just change the Diffuse_Value in the shadow catcher DIffuse node to something much less than 1. Usually .5 is enough to avoid trying to sample a hyper-color.

In the end, though, I can't figure out how to deal with the fact that the calibration step of the ground with IDL enabled interferes with the very thing it is trying to measure. I had thought that making the ground invisible to raytracing would take care of it. But it doesn't.

---

Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)

@Anthanasius: Thanks - it's so long since I used the shadow catcher, I couldn't remember the node setup.
Come to think of it, I can't remember the last time I used AO. Haven't things changed in the last 8 months!
Cool new avatar!

"If I were a shadow, I know I wouldn't like to be half of what I should be."
Mr Otsuka, the old black tomcat in Kafka on the Shore (Haruki Murakami)

Quote - Oh, and Bill, you've talked some times ago about a sort of volumetric effect shader, something you've applied to a sphere to get that sort of magical spelling effect, could you talk more about it? :)

I was actually trying to make a cloud generator for the EnvSphere, something that generates 100 miles of clouds. I did get something that was moderately correct, but I never got it perfect. I lost interest.

However, for a localized cloud (contained within a 50 foot or smaller prop) it worked pretty well.

It involves a lot of trigonometry.

Here's how I did it.

First I assumed the camera was at 0, 0, 0. This isn't true, but it's close enough to make it work OK.

The shader calculates the vector formed by the camera and the point being shaded. This gives me altitude and a vector I can use to project the camera's viewpoint into space.

From the shaded point, I then project multiple coordinates along the view vector. At each of these points, I evaluate a clouds-type of node, such as fBm or Fractal_Sum.

These values are blended together, from back to front, forming a sampling of how light rays from all those points would combine as they move towards the camera.

The more points I use, the better the approximation becomes. In the limit as the number of points approaches infinity, a perfect volumetric rendering of the 3D cloud is possible. But that isn't practical.

In attempting to do a finite number of sample points, I had to choose a spacing for these points. In the case of the EnvSphere, I first chose simulated concentric spheres, and used the points where the vector intersects those spheres. But the cloud layer is actually bounded by a lower and upper altitude. The intersections of the spheres with these boundaries leads to many samples lying outside the cloud layer, and becoming wasted calculations that produce "nothing here". So I attempted to slide the samples down so they are always within the boundary layer. But as the vector approaches horizontal, the spacing increases dramatically. Looking straight up, the samples might be 50 feet apart. Looking close to the horizon, they would be miles apart. The result was that at certain angles, the illusion of smoothly varying cloud density would disappear, and the concentric spheres would become visible.

I then tried various ways of skewing or bending the vector, but nothing worked right. Or I wasn't implementing them correctly. Either way, it became an overwhelmingly difficult problem to work on using only Poser nodes. If I could just write a straightforward program with variables and loops, I think I could do it. But just expressing everything with a constant set of nodes seems very difficult.

These sampling problems don't occur in the bounded cloudy sphere case. Uniform sampling is pretty good.

---

Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)

Sorry, i've been out for a long time ;)

So a shadow catcher is something impossible for PP2010?
What about the standard ground, will it only catch the 'real' shadow and not the IDL ones?

As for your volumetric shader Bill, i was thinking about one you showed in a thread i can't find now where you applied it to an orb to make some magical effect.

My Store

Quote - Sorry, i've been out for a long time ;)

So a shadow catcher is something impossible for PP2010?
What about the standard ground, will it only catch the 'real' shadow and not the IDL ones?

As for your volumetric shader Bill, i was thinking about one you showed in a thread i can't find now where you applied it to an orb to make some magical effect.

if you have poser pro 2010 then you dont need the shadow catcher.

you use the aux render passes and combined them in photoshop or GIMP. you can then tweak the shadow and AO passes for hours in real time. also colors.