Light layer question

[Headroom]

I 've been experimenting with a few ideas for my physical-computing / LED-lighting-system:

http://www.indigorenderer.com/forum/vie ... =3&t=11010

The file has 2 light layers, one for each RGB LED. Each LED has three emitters, one for each color, so the output of each LED triplet is on one light layer with the idea to be able to mix the colors as that's what the electronics behind the scenes will be doing.

The first image shows both LED's with all three light layer channels at default (white).
the second image shows LED #1 with the blue channel at 1 and the green and red at 0 and the second LED with red at 1 and 0 for the other two.

Yet, I still see more than red, blue and purple. There is still some green in there even though none should be emitted (?). I am pretty sure there is a lack of understanding on my side and would appreciate some helpful hints.

[CTZn]

Some saturated caustics, 1.0 is way too much even for pure colour. Could you match the LED's spec more ? Are they emitting pure colors ?

I must say that this lamp has entered a new dimension now, I like the results. Reminds me my early tests with GFARayrace

Edit: could you please embed the emitting materials in a code tag so we can check wether and how they are emitting ?

[Headroom]

You are right about the colors being too saturated. I am certain there are more things I can do to make the render approximate reality better. I guess when matching the LED spec better tabulated spectra ( or whatever that was called in Indigo) are called for.

The spec sheet is here:
http://www.philipslumileds.com/uploads/265/DS68-pdf

These are arranged in a star pattern that is part of my model:
http://ledsupply.com/07007-prgb0-0.php

Most of these things are imported as STL and come from Alibre Design, the CAD package I use at home to design the mechanical components

I am just not exactly sure how to translate the charts in the specs into the data needed for Indigo.

The next thing is that I would need to create a more realistic material for the glass template that is located between the LED and the wall. I expect to make it out of simple float glass, or Borosilicate glass. Finding data about transmission and cauchy-b is not easy and I'd have to consolidate data from different sources. I am not exactly sure how much of an effect it would have.

In the meantime I will try to come up with a nice color changing algorithm. I have one LED hooked up to the electronict, which in turn are connected to my computer and was able to play a little with it.

[CTZn]

Exciting, have nice findings !

About the light data, it's a bit theorical for me but we could use the figures 5 and 6 for the spectral part. We generalize the amber response in 6 and offset peak for each color.

The support should be tabulated medium for the best. I'll be rough and tell you to check for regular_tabulated into the technical reference tell me if that's something that you want to sort out.

About the glass, well what can I tell ? In my opinion if you are going for a flat glass you can consider discarding diffraction as you will be emitting a very thin spectrum bandwidth anyways. Even then, flatness will not let much left.

off the top of my head I remember a value of 0.0014 as default ?

[CTZn]

Here's a method that should work:

We will use peaks estimates to set each color; the amber peak is roughly at 600nm (0.6E-06m). It ranges from 460 to 780nm. You can take an arbitrary estimates sample count at equal distances. That's a response profile.

Next, estimate the start value for each of red, green, blue of whatever model and determinate the corresponding range end. Reuse response data or estimate another.

Don't miss the IGS example in the tech reference.

Amazing how the ambient temperature is affecting efficacy.

edit: you could use fig. 26 to create an IES profile.

[Headroom]

Thanks for these very helpful hints!
I'll see how far I get with the tabulated data.

I think I'll draw a line at the IES profile though. In combination with the tab data and the five light layers for the full system the render will take forever......

[Headroom]

Here's a method that should work:

We will use peaks estimates to set each color; the amber peak is roughly at 600nm (0.6E-06m). It ranges from 460 to 780nm. You can take an arbitrary estimates sample count at equal distances. That's a response profile.

Next, estimate the start value for each of red, green, blue of whatever model and determinate the corresponding range end. Reuse response data or estimate another.

Don't miss the IGS example in the tech reference.

Amazing how the ambient temperature is affecting efficacy.

edit: you could use fig. 26 to create an IES profile.

Just read through the manual. Thanks for the spectrum::peak tip! I would likely have skipped over that part.
The technical reference manual is not exactly light reading

[CTZn]

The peak spectrum type is more accessible but it outputs a square response.

See a regular tabulated code example here: http://www.indigorenderer.com/materials ... iew_source

IIRC a blank space is enough for a separator.

edit: in fact there is support for regular tabulated data if you use SkIndigo, not sure for blendigo. edit 2: I should have said dispersion above, and not diffraction.

[Headroom]

Now the question is how do I translate these charts into data points useable in Indigo. I have created IES files before and that appears to be pretty simple so I'll do that.
I am not sure though about the emission spectra other than printing an enlarged copy and then use a ruler and pencil.

Any other ideas or perhaps software solutions /

The neatest thing would be of course if one could create curves in blender to trace the ones in the chart and then have a python script spit out the numbers but that would be well beyond my very rusty coding abilities. Rusty as in pitted, flaky with lots of corroded-through holes

[CTZn]

I think one can find 2d graphs plotting software, but the most affordable way is to get the image resized into an image editing application and then use rulers has helpers to read/aproximate the values.

But ok, I'll provide you with the things I mentionned

Converting the image into a curve is a good idea ! edit: what strikes me is that the pdf curve data is vectorial ("real" data), how to get to this ?

[galinette]

Some saturated caustics, 1.0 is way too much even for pure colour. Could you match the LED's spec more ? Are they emitting pure colors ?

Mmmh, not sure! Color leds have a very high purity and are usually outside the sRGB gamut (meaning they are too saturated to be represented by a sRGB triplet)

You are right, best is using LED spectral data, but I'd bet that this would lead to colors so saturated they will be clamped by Indigo.

Etienne

[CTZn]

Saturation has the green light then !

Ideally, shouldn't we use the wavelength-dependent shader definition eval(real wavelen, vec3 pos) real ?
Does the data sheet provide us enough for such an adaptation ?

[CTZn]

Hey headroom, I didn't forgot about your project ! At the contrary I got hooked into implementing a graphical resolution for tabulated data generation in Maya, I have further points to evaluate before it's done.

For the reasons galinette mentioned, generating such data may not make a big difference here from using a peak spectrum due to the signal narrowness.

[Headroom]

Thanks. That sounds very interesting!

I am still trying to grasp how to translate the information in the spec sheet into spectral radiance needed for Indigo. The chart in the spec sheet (figure 5) is dimensionless in the vertical axis and also does not account for the fact that the lumen output for the different color leds is different.

Tonight I finally have some time to play with the LED and see with my own eyes how saturated the colors of the LED really are

[CTZn]

Scaling and offsetting the curve vertically should be an option hopefully, though I'm not sure I'll read what I want in the first place from the curve editor, interpolated results notably.

Anyways emission scale will do just this, scaling the emitted power. We can use normalised curves I think.

I am not very good either with handling energy related workflows...