Is it possible to get reflections from an HDRI map (tdl:ed or not?) in the glossy reflections? At the moment I'm only getting reflections from the geo that's been baked into the point cloud?

Thanks!

Doh, my bad! Already had it going in there (just had too much blur). Would it be possible to set the "distance" to the HDRI? Since the reflections gets blurrier the further away they are it would be cool to be able to say how far away the "environement" is to control how blurred it gets? Makes sense? :-)

Looks like it does. However I'm having problems getting the environment anything else than really blurred? In this image I have a tdl in the env slot and glossy reflections.



Is there a way to bake out stuff that's not visible through camera into a point cloud? So that I don't get stuff like the checkered ground just being cut off like this?

The original shaders posted on the first page have been updated. I've fixed some transparency and baking related issues I ran into in production. Also, I've broken the uber shaders into some of the more popular effects to have the option of a smaller, more specialized shader.

They are located and will be updated from here: http://blog.cameronleger.com/code/many- … d-shaders/

Good luck. Let me know how the workflow goes, I've yet to try it.

I'll have yet another fix for atmosphere shaders and transparency later (getting around a bug).

Playing with SSS now, latest shader has presets for the materials described in the BSSRDF paper. Looks great.

Hi!

I have not tried with miss_fast_skin. I'll make a note to try it with that. You're saying the SSS color from miss_fast_skin is baked, but not bounced onto other things? Also, is this with the atmosphere or light shader?

PTC SSS is really simple. The extra attributes that have to be used to compute SSS are not needed, these are specified in the shader. You can use it like any other effect in my shaders. I only ever use standard Maya shaders in my renders, except I have used mia_material_x without problems.

The values are a little different for SSS though. There are a few main "look" tweaks. IOR should almost always be 1.3, except when simulating marble it should be 1.5. The presets use numbers from the paper describing BSSRDF. You should be able to pick one of them and then only have to tweak scale, depending on your scene size. If you pick custom, you can use your own values. The default values in the custom section are those of the skin1 preset. If you want to see the values for the other presets you can look in the shader code for them.

ok, never mind the last question... I tried light linking and it works :)

Hi Cameron,
  finally I had some time to experiment with your shader, and I was pleasantly surprised how easy it was to use (for the very basic functionalities, at least; I just tested AO and color bleeding with the volume shader, by now).
I'll add my voice to the choir, then, in thanking you for the nice work and, above all, for sharing it.
Though, after taking a glance at your code, there are a few things I can't really get, both regarding the code itself and something you wrote on this forum thread and your website.

  ::
 
  The first thing is at line 661 of the volume shader (in the most recent version on your website), within the GI_AO condition:
 

aov_AO = Oi*1-occlusion(  //because we set aov_AO to 1 earlier, we subtract the occlusion from 1

I'd guess it should be, instead

aov_AO = Oi * (1-occlusion(

In fact, that should be the same operation you do within the basic AO condition; am I wrong?
Also, what do you mean exactly by "because we set aov_AO to 1 earlier, we subtract the occlusion from 1"?
As far as I interpreted it, line 661 means:

aov_AO = the inverse of occlusion amount, premultiplied by the shaded point's opacity.

where, I thought, the "inverse of occlusion" is just a convenient way to store the occlusion pass, for compositing purposes, without inverting it later on. Is there something I got wrong?

  ::
 
  Another thing I can't understand is at line 691, whithin GI (and GI_AO) composite's condition:

Ci += aov_GI * aov_AO; // Since we're doing AO and GI at the same time, multiply them onto each other, because we set aov_AO to 1 earlier, if there's no occlusion, it's multiplied by 1

I'm not exaclty sure that this is the way it should be. I might be wrong, as I don't have a deep knowledge of compositing but, as far as I know, AO shouldn't be multiplied just by the GI.
I would have expected something like:

Ci = (Ci + aov_GI) * aov_AO;

But that is just if I got what GI_AO is intended for, otherwise I'm totally missing the point (which is equally probable).
I Thought it was some sort of AO's alternative, as it performs the same operation. But I can't get what the purpose of such an alternative is. Can you please explain that? (If the reason regards rendertimes, just ignore this last question and see the next point).

  ::
 
  Regarding rendertimes, on the very first post of this thread you said

cleger wrote:

[...] AO added 60 seconds. GI added 72 seconds. Rendering those separately would give you two sets of normal images and GI and AO, at 372 seconds. [...] Also, if you're using GI and plan to use AO as well, it's best to turn on the AO for GI. They'll both be calulated at the same time and it will save a lot of rendertime

But as I said above, I can't really see the reason why you should go for GI_AO instead of AO. When saying "rendering those separately" did you mean in two separate render passes, or using AO instead of GI_AO (together with GI) within the same pass?
In the former case I'd expect a "loss" in rendertimes, but I supposed this was caused by computing twice the lighting loops and, maybe, in loading twice the same PTC. Again, I might be wrong as I do not have a deep knowledge about how the renderer works (and I'd ask anybody to enlighten me about this, if possible).
In the latter case, instead, I must say I didn't experience the same thing. I've tried both the AO and GI_AO options and got exactly the same rendertimes (as I expected it to be, given the fact that the same code is executed, even though at different lines within the shader). I didn't get the same results in the composited render, though, mainly for the reasons I mentioned above.

  ::

  To conclude, if I misunderstood the way GI_AO is intended to be used, I would ask you to shed some light on that.
Otherwise, I would ask if it weren't someway simpler to get rid of the GI_AO and just use the normal AO option, provided GI's operations (or even just the compositing snippet) appear before the ones for AO, so that

Ci *= aov_AO;

is always computed after

Ci += aov_GI;

Please excuse me for being so long (I just wanted to be sure that my doubts were clear enough), for my bad English, and if my questions will turn out to be just noobly dumb.
 
Thanks again,
s

Cameron, thanks for replying that quick; you made the whole thing much clearer and helped a bit my nerdish self-esteem, too :)

cleger wrote:

"Computing the occlusion while calling this function is also possible (through the occlusion parameter), with the following restriction: indirectdiffuse() only sees geometry tagged as visible to reflections, as opposed to occlusion() which sees geometry visible to shadows. For more informations about visibility attributes refer to Attributes." [...]
So, I can test that out and see if that was indeed the idea that I was after (and if rendertimes are faster using that or AO and GI separate).

I guess it is, and it sounds nice, indeed.
I'll look into it, too, right after testing all the other features you already provided. I hope I'll come out with something useful to share as well, in the next future.

Cheers,
s

First, thanks for this great shader :)
Is there any way to combine photonmapping with this shader (like how the built in GI solution works for multiple bounces)?

I have pragma annotations for just about everything. So, everything is grouped into categories. In each category of functionality, you have the values at your control for the effect. The values are given "nice" names and have tooltip descriptions of what the value does, and in some cases, the best and/or default value.

The shader includes AOVs for each pass. Each pass will render out the normal image with the effect you've chosen on top of it. You can also use AOVs to render out the image before the effects and the bare effect for compositing. The specific AOVs are documented inside of the shader, but I'll also list them here.

Cleger, I'm using your shaders and enjoying them a lot.
However, I have objects with transparency mapping on them, and when I watch them in the ptcviewer the points seem to be not black, but dark gray.

This doesn't seem to be a problem for ao, but I'm seeing my object where it should be transparent using GI.
Am I doing something wrong? Your shaders seem to work for every other task and are even hard to get by without.

Thanks in advance!