Position of object defined by color

[t_overberg]

Hi,

i have a little (?) problem. Perhaps there is someone out there, who can help me. I have some spheres placed on the grid and all spheres textured with one large projection. Now i want that the spheres change their hight depending on the color the sphere get from the projected image. If a sphere is black because the projection from the image makes it black the sphere should rest without moving. If the sphere is white because the projection from the image makes it white the sphere should move up to 0, 1, 0. 

The movement works when i use only a shader without texture or projection. If i pull the shader color from black to white the sphere moves from 0, 0, 0 to 0, 1, 0. But it doesnt work when i use a texture file or projection.

Has somebody an idea?

Thanks a lot

Thomas 

[joojaa]

use a particle expression and instancer, and a array mapper.

[t_overberg]

Thanks and sorry Joojaa, but i think it is not possible to do it with particles and instances. Forgot to write this. I described it with spheres to make understanding easier, but for the final animation there are many different objects to move, no spheres.

Alternatively i have to read the greycolor from the image at defined points (pixels) and transfer these informations to the objects-shader-colors or directly to the objects y-translate.

Thanks

Thomas 

[joojaa]

Ok but then it will just be slower thats all. Tough really this si the point where you dig out SoUP, or make your own. Orl make a particle object for the lookup but pass the info to the actual nodes in the particle expression*. Or wirite simplae api node to convert array values to and array of values. Or make one instance per particle**

*Sortof like

float $nupos[];
$nupos[particleobject.id]=oarticleobject.mappedvalue;
if (particleobject.id==$lastParticleNumber){
  obj1.tz=$nupos[1];
  obj2.tz=$nupos[2];
  obj3.tz=$nupos[3];
  obj4.tz=$nupos[4];
  obj5.tz=$nupos[5];
  obj6.tz=$nupos[6];
  ..... generate as many names as you need (yeah dont type)
}

the above isnt as stupid as it sounds as it does indeed get compiled its MUCH smarter than using settatr! Besides thsi isnt going to be the source of the slowness As code it looks stupid agreed, but you will be using it trough other code even c can look really ugly after a preprocessing macros gets its job done.

** it also isnt as stupid as it sounds just unwieldy for users. However if you need to drive transofrms that are subobjects of a rig then this wont work offcourse.

Alternatively i have to read the greycolor from the image at defined points
(pixels) and transfer these informations to the objects-shader-colors
or directly to the objects y-translate.

sure, just even slower