View Full Version : Pixel Data access plug

02 February 2003, 06:06 PM
Is there a plugin which will give me the RGB values from specific locations in an image in a form usable for controlling other colors (like lights)?

The problem I've got, is that I'm using Texture Channel to control the colors of the R, G and B channels on lights. The only problem, is that when the image is a sequence, it does not update! the data seems frozen on one frame, not necessarily frame 1. (That's not all -- Texture Channel also applies a 1 m/s animation which you can't adjust or get rid of, which requires a matching negative animation applied to the texture to get the bloody thing to stand still. Go figure.)

The application is rather like spinning lights, but instead of spinning, I'm scanning a TV screen with a line of lights moving across it over one frame. If it would have worked, it would allow me to have a TV screen with video, softly reflected in the specular channel from a lacquered wood floor. Vastly cheaper than soft reflections.

Does Overcaster work with sequences?

02 February 2003, 09:27 PM
couldn't you just composite this sort of effect in post? just render out your specular shading pass and use it as an Alpha channel to apply the reflection within.

I'm not 100% clear on what 'look' you're going for. Do you have a sample comp you could post to make this a little more clear?


02 February 2003, 01:09 AM
CourtJester, If you find a good solution to this inside lightwave(via plugin, script, or other) please let me know =)

02 February 2003, 12:53 AM
Funny that Texture channel will not permit animation n time, but introduces a bogus animation on the X axis.... wrong dimension!

Anyway, here's a test shot, which I deliberately rendered at too low an AA setting so you can see just what I'm doing. Yep, that's reflection in the spec channel by creating a picture by sampling it with lights.

Too bad nobody thought of allowing us to texture area lights in this way. Instant TV screens, billboard lights, etc. without radiosity or plugins. Linear lights would draw a "strip" of color from a texture, while the others would simply draw a color from one point in texture space. Oh well.

Currently, Texture Channel or expressions is the only way to map values onto the light color. Maybe Expressions will work?

Well, I don't have the time to fiddle with it right now, so here's a lowdown on how I do it currently. Any of you expression types could fiddle with this to see if Texture Channel could be eliminated from the pipeline.

(Edited to add: it isn't Texture Channel, it's the Image Editor stage that's the problem. Stills work fine, but animations or sequences are borked.)

1. Load your source image. (For simple black-and-white operation skip ahead to step 4 and use the source sequence for all Texture Channel inputs.)

Clone it three times. For later clarity, let's say it's SMPTE color bars.

2. Apply a Texture Filter to each of the three clones, and apply a Value Texture to all three, with its blending mode set to Multiply.

3. For the first one, set the Value color to pure red; the second, pure green; the third, pure blue. This will separate out the RGB values from the source image, which we need to do because Texture Channel is monochrome/luminance only.

4. Create the first light to be textured. Shadowmapped spot is preferred, depending on application (that's what is used in the sample image given).

5. Apply Texture Channel to the red channel. Give it a texture, planar, default size. Animate the texture 1m/s in the positive direction (slopes UP to right)*. Use the red clone image. Repeat the process for the other channels, using their respective images.

5A I almost forgot, since Texture Channel works on luminance, it treats the images as full-color, so blue and red will be under-represented. Use Scale on the Graph Editor to scale the modifier up so that all three top out at 100% (SMPTE color bars are good for this calibration -- they don't need to be at any particular height, just the same as each other).

6. The texture is essentially 1 meter by 1 meter in texture space, where 0,0 is in the middle and the extreme edges are +/- 0.5 or 500mm. Position the texture using its Y attribute to place the light as a specific "scan line". The planned density of lights in your array will determine the distribution of the Y values.

7. For a skydome, arrange the lights in a half circle (aimed to the middle), parent them to a null and spin them around. Be sure to set the relative intensities of these lights in accordance with the cosine of their angle with the X axis, else the top and bottom of your objects will receive too much light. For example, if the middle "equator" light is 100%, multiply the intensities of the others by the cosine of their angular positions. There is no point in having a light directly at the "poles" because cosine 90 = 0.

For a TV screen/ "area light", simply set them up in a vertical line and sweep them across the "screen" in a sawtooth pattern, same intensity all. That's what I used in the test image.

(*) Now here is where things get a bit screwy. With texture channel, the Axis option simply determines which of the three "directions" of texture space will be used. (When it's an Image map, Z is effectivly irrelevant.) Because we are restricted to one axis, you cannot move your light around in three dimensions in the texture space. That wiped out my first plan, to texture the light by spinning it around a spherical projection, done to world co-ordinates.

Fortunately, whether you are doing a skydome or a TV screen, it does not affect what you do here -- we will be "scanning" the image the same way. You simply use a spherical projection image (like Skytracer images baked to spherical) for skydomes.

You will find that the point in texture space from which the value output by Texture Channel is derived, DOESN'T BLOODY STAND STILL like you would expect... it moves to image right, loops to image left and then returns to center 30 frames later! If you are using SMPTE color bars, it is as if the texture is moving to the left, such that what started out as green, becomes magenta, red, blue, white, yellow and cyan! I verified that in a scene where I set up a light in the manner described here, sans the compensating animation, and I got a light source that changed its color just as described here, in OpenGL.

Because of that, the Graph Editor of course will lie about what you are seeing. Use the X channel trick mentioned below, or OpenGL, to see what is really happening.

To get the damn thing to sit still, you need to animate at 1m/s to the positive. To animate it to scan over one frame, as we do for this trick, you need to factor that 1m/s in, so the "loop speed" is 31m/sec, else you get drift. It's easier to handle if you simply use an external reference null and refer all the Texture Channels to it. This is also where you can adjust the effective "horizontal hold" of the image' grab all the keys of the motion and move them up +/- 0.5m to adjust the image position on the "light grid".

You can create a grid of lights and skip the scanning entirely, positioning each light on the grid manually, but as I understand it, that makes for longer render times.

NOTE: one way to see what the bloody hell is happening, is to copy and paste the modifier to the X channel of a null. Then, set a linear motion for this null from top to bottom in Y, turn on show motion paths, and you'll have a neat graph on screen.

CGTalk Moderation
01 January 2006, 12:00 PM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.