Jump to content
papicrunch

IES light shape

Recommended Posts

Hello,

I want to know if there is a way to import IES file into houdini' lights ?

thank,

papi

sorry for my english

Share this post


Link to post
Share on other sites
Hello,

I want to know if there is a way to import IES file into houdini' lights ?

thank,

papi

sorry for my english

AFAIK there is no ready to use tool for that. After all if you're not interested with recreating any particular light but rather having similar control on ligth cone, you can do it without IES...

igs.hip

Share this post


Link to post
Share on other sites

nice example Symek!

i would still like to see IES light profiles in Houdini, especially since we have Physically based rendering

jason

Share this post


Link to post
Share on other sites

thank for reply,

But in your exemple the shape of light is only in "2D"' projection, with IES the patern's light look much "3d"

Here just un simple exemple in maya :

IESmaya.jpg

papi

Share this post


Link to post
Share on other sites
But in your exemple the shape of light is only in "2D"' projection, with IES the patern's light look much "3d"

I guess this would require a real IES parser in the light shader.

A workaround would be to roll your own light shader that reads lookup tables for light Intensity in 3D

Acording to this source [1] the last three sets of numbers in an IES file define vertical and horizontal angle values and the candela value at this point.

Once you convert these to ramps the light shader could calculate the bearing of the sample and look up the intensity of the lamp in this direction.

[1] http://www.vuw.ac.nz/architecture-onlinete...ard_format.html

Share this post


Link to post
Share on other sites
thank for reply,

But in your exemple the shape of light is only in "2D"' projection, with IES the patern's light look much "3d"

Here just un simple exemple in maya :

papi

Well, you are right, this is not fully functional IES light setup, but 2 minute example. It doesn't bother with light distance / attenuation. I used to deal with that issue but failed miserably by IES file parser (which is crude format, but exists in a few flavors). As Georg says, adding distance attenuation per ies sample would require writing your own light shader (nothing that can't be done in a week or so).

Edited by SYmek

Share this post


Link to post
Share on other sites

ok thank for advice,

I really new in houdini world but I will take look, how capture informations in IES file and try to use them into light or 3d texture.

papi,

sorry again for my poor english speak :(

Share this post


Link to post
Share on other sites
ok thank for advice,

I really new in houdini world but I will take look, how capture informations in IES file and try to use them into light or 3d texture.

papi,

sorry again for my poor english speak :(

Maybe you can convince rdg or SYmek to anamous to try to make an IES shader for you:)

Share this post


Link to post
Share on other sites
Maybe you can convince rdg or SYmek to anamous to try to make an IES shader for you:)

Sounds like a shader a day :)

Share this post


Link to post
Share on other sites
Maybe you can convince rdg or SYmek to anamous to try to make an IES shader for you:)

Let it be Sunday, Georg :ph34r:

Share this post


Link to post
Share on other sites
AFAIK there is no ready to use tool for that. After all if you're not interested with recreating any particular light but rather having similar control on ligth cone, you can do it without IES...

One of the rare examples where the op:// reference doesn't work so well. It brings my 3d viewport interaction to a crawl.

Share this post


Link to post
Share on other sites
Sounds like a shader a day :)

Hmmm... not so trivial, this.

Writing the shader to output different intensities based on axial angle, sure, five minutes. Encoding a distribution in a way that can be used to parameterize the shader? sure, ramps will do for axially symmetrical distributions, but for quadrant and plane symmetries, as well as for fully volumetric distributions... well... you need to get a little more creative (array of ramps + filtered lookup function?).

Finally, assuming you have a nice compact representation for all distribution types, which the light object can store locally and use to parameterize the shader, then, if you want to be able to load arbitrary definitions from file in standard ies format (which is the whole idea, right?), you need to deal with the whole parsing issue... not a biggie, but it's there.

So yeah, the shader itself is definitely a "shader-a-day" thing :)

But for a full-featured, flexible IES light object (to drive this simple shader)... a few days, I would think.

Share this post


Link to post
Share on other sites
One of the rare examples where the op:// reference doesn't work so well. It brings my 3d viewport interaction to a crawl.

Another potential gotcha:

I've found, too, that using the op:/ syntax to reference floating point images can screw up in the IFD on the way to Mantra. Setting your comp to 8-bit solves this. Admittedly this was a few months ago that I tried this.

Perhaps a different bit depth might affect your viewport speed too?

Share this post


Link to post
Share on other sites
Hmmm... not so trivial, this.

Aware of this and appreciate your thoughts, I am. Yes, hmmm.

Two ramps won't suffice but a nice image will do.

A full blown IES will probably not be the result of this exercise, but maybe a IEStoLightMap.py.

But for a full-featured, flexible IES light object (to drive this simple shader)... a few days, I would think.

Unlikely, taking my C/HDK ignorance into account.

op:// textures aren't anti-aliased I was told from the first day.

Share this post


Link to post
Share on other sites
Two ramps won't suffice but a nice image will do.

Yup, an environment map might be a good choice to support everything, including volumetric distributions.

Share this post


Link to post
Share on other sites
Yup, an environment map might be a good choice to support everything, including volumetric distributions.

:unsure:

the environment map might also be a shortcut to the azimuth/roll/hither calculation ...

:unsure:

As the acos(dot(normalize(L), vector3(0, 0, 1)) to create a 0..360 degree angle worked fine in SOPs but somehow gets screwed up in the light shader.

This snippet doesn't give a 0..360 of course, I test if L.y - respective L.x - is < 0 and add 180 if so ...

Edited by rdg

Share this post


Link to post
Share on other sites
As the acos(dot(normalize(L), vector3(0, 0, 1)) to create a 0..360 degree angle worked fine in SOPs but somehow gets screwed up in the light shader.

This snippet doesn't give a 0..360 of course, I test if L.y - respective L.x - is < 0 and add 180 if so ...

Not sure what you're after exactly, but if you're looking for the axial angle, the I'd imagine that inside the light context, it would look something like acos(dot(normalize(-L),normalize(Lz))), which has a range of [0,PI]. (but I'm going by memory here... I *think* Lz is in current space but you should double check that).

Share this post


Link to post
Share on other sites
Not sure what you're after exactly, but if you're looking for the axial angle ...

Oh wait. You're probably looking for a way to get the lat-long angles, right? (elevation and azimuth)

If that's the case, then just get L in the light's space (unit length) and derive the angles from its components. Something like this:

vector v = normalize(vtransform("space:object",-L));
float latitude = acos(v.z); // range [0,PI], measured from the light's z-axis
float longitude = atan2(v.y,v.x); // range [-PI,PI], measured from the light's x-axis

Share this post


Link to post
Share on other sites

Didn't know how lost I was

Until I found you.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×