Coatings - Iridescence

[MADjestic]

Hard to convince because there is no support for Mantra in Maya and 3DS Max?

I am afraid due to the usual ability among so many Max/Maya people to strongly rely in out-of-the-box sollutions - to grab some ready-made Mental Ray shader and fire the render - Mantra would hardly become too popular...

(at least what I mostly saw in my experience)

[kumpa]

hi!

what about non-nc version of it ?

kumpa

[lisux]

I am afraid due to the usual ability among so many Max/Maya people to strongly rely in out-of-the-box sollutions - to grab some ready-made Mental Ray shader and fire the render - Mantra would hardly become too popular...

(at least what I mostly saw in my experience)

Yes I am agree, Mantra is so powerful, but it needs more shaders out of the box to made it ready for new users or simple studios or environments where you don't have enough time to develop your own shaders.

I hope that for H9 SESI will made this effort.

Maybe they can use many shaders that are in the exchange a good shaders collection will be great.

[Jens]

My personal guess is that houdini's main target user groups are larger studios (at least not freelancers, very small studios). Houdini seems to me like a good choice for any task ranging from simple to very complex scenarios... however it's only exceptional when you look at the more complex projects / areas where the very unique procedual concept start to shine. People who know Houdini well enough to achieve benefits from its procedural structure most likely have all the knowledge to work with VOP's/VEX to get the shaders they need. In short while I'd appreciate more 'out of the box' setups, I don't think their main share of paying customers would appreciate efforts into that direction. Trying to stay in line with Maya,Max and co in that area would likely take most of their resources and it's heavily fought territory.

Before I read those tutorials of FrenchOP to start getting an idea about the potential power of the group and copy SOP I underestimated them (and considered them the equivalent to 'ctrl-g / ctrl-c' in other programs ) ... seems to me that the developers of sidefx much more enjoy giving the users more new options and let them do the thinking, compared to spending a lot of time to make 'fool-proof' guided tools. Besides at least a few years ago when I worked a bit in a small CG studio even they had a few guys who did nothing but preparing scenes for rendering / setting shaders up. Things might have changed, but those premade 'SSS,GI etc.' setups where not usable for animations, since usually they had to be split for the rendering layers anyhow (if it was going to be an animation). An experienced photoshop artists could make any still look exceptional and not too much effort was needed for texture, shaders, lightening here. In short only in personal fun projects were these 'out of the box setups' appreciated.

Ah well, we'll see what happens in the future and my view on this might be utterly wrong

I wish ProE had Mantra support.

[digitallysane]

People who know Houdini well enough to achieve benefits from its procedural structure most likely have all the knowledge to work with VOP's/VEX to get the shaders they need.

This is not true. We are a very small studio, we intend to get Houdini (Escape) and the shader writing is a big issue for us. And I'm sure there would be many in our position.

Houdini is very good for projects of any scale (we intend to use it mainly for broadcast-type work), but in order to be more appealing and useful to small studios it needs some fixes (and I don't think that having a decent shader library included is something out of the ordinary).

And I do think that small studios are _key_ to the growth of any software.

Dragos

[Jason]

Hey Jens,

Did you ever manage to wrap up this wonderful piece of technology into VOPs?

[rendertan]

Hi

I have a quick doubt, in the phase difference function:

float out_eps;

out_eps = asin(sin(in_eps)/n);

but in_eps is the cosine of the angle between the surface normal and the viewer, this is a typo no?

The formula states the angle between N and I, not the cosine of this angle, shouldn't it be:

out_eps = asin(sin( acos(in_eps))/n);

Perhaps it would be more efficient if we factor it as:

float intef(float lambda, in_eps, n,d){

float f1 = 2 * d * n * sqrt( in_eps * in_eps + (n*n) - 1);

return f1 / (lambda * n);

}

Or am i overlooking something?

[Mario Marengo]

out_eps = asin(sin( acos(in_eps))/n);

Perhaps it would be more efficient if we factor it as:

float intef(float lambda, in_eps, n,d){

float f1 = 2 * d * n * sqrt( in_eps * in_eps + (n*n) - 1);

return f1 / (lambda * n);

}

You're probably right about the cos thing, though I haven't looked at Jens' VOPs, but I can imagine that since angles in shaders typically originate from dot products, then it's very possible that in_eps variable represents a cosine instead of a a sine.

Regarding the simplification of the expression using trig identities though... I think there might be a mistake there..

The expression:

asin( sin(acos(x))/n )

could be written as:

asin( sqrt(1-x*x)/n )

But I don't know the full expression so I could be missing something...

[rendertan]

Hi Mario

My fault, i should've posted the complete function listing, for the expression simplification otherwise... sorry for that

The original expression (with the angle, not cosine) would be:

float out_eps;

out_eps = asin( sin( acos(in_eps) ) / n );

return 2 * n * d * cos( out_eps ) / lambda;

so we want the cosine of out_eps, which i :cough: forgot to mention.

So 2 * n * d * cos( asin( sin( acos(in_eps)) / n)) / lambda

reduced to

float f1 = 2 * d * n * sqrt( in_eps * in_eps + (n*n) - 1);

return f1 / (lambda * n);

just fired up maxima, everything seems ok

Hopefully i'll manage to clean up these coated metal tests, and post something useful here.

Once again, thanks for your help Mario

You're probably right about the cos thing, though I haven't looked at Jens' VOPs, but I can imagine that since angles in shaders typically originate from dot products, then it's very possible that in_eps variable represents a cosine instead of a a sine.

Regarding the simplification of the expression using trig identities though... I think there might be a mistake there..

The expression:

asin( sin(acos(x))/n )

could be written as:

asin( sqrt(1-x*x)/n )

But I don't know the full expression so I could be missing something...

[smidur]

hi,

I rebuild Jens shader for renderman, which was obviously not a major achievement thanks to Jens posting his file 1 year and a half ago.. thanks a lot. I love odforce...

anyways, all working fine except for a tiny little thing.

renderman's fresnel looks different than mantras. any ideas how to get the same result?

1/IOR got me close to what mantra is doing but not quite the same

thanks a lot

[Mario Marengo]

renderman's fresnel looks different than mantras. any ideas how to get the same result?

1/IOR got me close to what mantra is doing but not quite the same

Hi semidur,

There are a lot of possibilities for the difference between RSL's and VEX's fresnel()...

1. VEX's fresnel() changed quite a bit between H8 (when Jens posted this) and H9. The most obvious change was the returned value for Kt, which was incorrect prior to H9. Also, total internal reflection (TIR) wasn't handled properly <H9, IIRC. I believe all issues are now fixed (for versions >=H9).

2. I haven't checked RSL in a while now, but it also used to have a bug with Kt (similar to pre-H9 VEX).

3. The value for "eta" in both cases should be the ratio between the incident IOR (usually air=1) and the transmitted IOR (usually >1). So, e.g, eta for glass would be around 1/1.5 (or 0.666)... though the VEX docs seem to suggest the opposite... <shrug>.

4. Given an "eta" as described in #3, then both RSL and VEX expect the incidence vector "i" or "I" to point toward P (not toward the source) -- i.e: the angle between I and N would be >90deg. If this is not the case, then RSL will return TIR (Kt=0,Kr=1), and I'm not sure about VEX's behaviour...

5. In the case of TIR, I believe VEX will arbitrarily set T to -I, whereas RSL might do something different. In any case, you should watch out for Kt=0 (or Kr=1) and branch appropriately -- i.e: don't assume T is necessarily always valid... it may not be.

To match VEX's current (H9 and above) Kt value in RSL (assuming the old bug is still around), set it to Kt = 1-Kr.

HTH.

[smidur]

thanks a lot Mario, very informative...

will have a go at it tomorrow.

I did test the mantra fresnel in H 8.2.66 and the rsl one with 13.5 so I guess that might explain it. thanks again for the detailed help...

cheers,

Martin

Hi semidur,

There are a lot of possibilities for the difference between RSL's and VEX's fresnel()...

1. VEX's fresnel() changed quite a bit between H8 (when Jens posted this) and H9. The most obvious change was the returned value for Kt, which was incorrect prior to H9. Also, total internal reflection (TIR) wasn't handled properly <H9, IIRC. I believe all issues are now fixed (for versions >=H9).

2. I haven't checked RSL in a while now, but it also used to have a bug with Kt (similar to pre-H9 VEX).

3. The value for "eta" in both cases should be the ratio between the incident IOR (usually air=1) and the transmitted IOR (usually >1). So, e.g, eta for glass would be around 1/1.5 (or 0.666)... though the VEX docs seem to suggest the opposite... <shrug>.

4. Given an "eta" as described in #3, then both RSL and VEX expect the incidence vector "i" or "I" to point toward P (not toward the source) -- i.e: the angle between I and N would be >90deg. If this is not the case, then RSL will return TIR (Kt=0,Kr=1), and I'm not sure about VEX's behaviour...

5. In the case of TIR, I believe VEX will arbitrarily set T to -I, whereas RSL might do something different. In any case, you should watch out for Kt=0 (or Kr=1) and branch appropriately -- i.e: don't assume T is necessarily always valid... it may not be.

To match VEX's current (H9 and above) Kt value in RSL (assuming the old bug is still around), set it to Kt = 1-Kr.

HTH.

[michalf]

Hello

I wonder if anybody reimplemented this as RSL and can share the code

[symek]

Hello

I wonder if anybody reimplemented this as RSL and can share the code

Hej Michał,

Here you go. Note, this is a *Vex* code (from above thread, but I don't remember which one) patched to compile with 3delight, not the native RSL. Seems to work with 3delight 10 though.

Miłych bąbelków!

skk.

irid_rsl.tar

[michalf]

Hej Michał,

Here you go. Note, this is a *Vex* code (from above thread, but I don't remember which one) patched to compile with 3delight, not the native RSL. Seems to work with 3delight 10 though.

Miłych bąbelków!

skk.

thanks SYmek ! much appreciated.

ps. to nie będą bąbelki tylko pióra

[symek]

Bobma! Pochwal sie, jak skonczysz.

ps Chrome got mad, sorry.

Edited November 24, 2011 by SYmek

[Jason]

Hi all,

Did anyone have a PBR-compatible anisotropic tweak of this iridescence going?

[Nando]

Hi there!!

I am working on the iridescence Shader now, i find the above example quite useful but when i download the file i am not able to see the contents?? even if i am trying to recreate and understand the way he has created.. i don't know what are the operators he has used in-order to build that Shader can somebody help me with that..

the picture representing! the operators where i don't know the names! so if some one can tell me, it would be useful.

thanks!

Edited April 1, 2012 by fernansha

[symek]

Middle mouse on an oparator to check its type. Once they have a custom names (like "red"), as they should, it's hard to decode what types they are.

[Nando]

Middle mouse on an oparator to check its type. Once they have a custom names (like "red"), as they should, it's hard to decode what types they are.

if i download the file,and try opening it, its giving me some errors nd i cant see anything it there!! i am using Houdini 11.1 is there any other options to open the file and see the contents