IES light shape

[papicrunch]

Hello,

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

thank,

papi

sorry for my english

[symek]

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

[jason_slab]

nice example Symek!

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

jason

[papicrunch]

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

[rdg]

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

[symek]

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 November 26, 2008 by SYmek

[papicrunch]

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

[Jason]

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:)

[rdg]

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

Sounds like a shader a day

[jason_slab]

Sounds like a shader a day

yes it does sound like it indeed

js

[symek]

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

Let it be Sunday, Georg

[peterr]

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.

[Mario Marengo]

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.

[Jason]

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?

[rdg]

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.

[Mario Marengo]

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.

[rdg]

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

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

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 November 28, 2008 by rdg

[Mario Marengo]

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).

[Mario Marengo]

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

[rdg]

Didn't know how lost I was

Until I found you.