[Bf-cycles] passing scene data to a kernel
aurel.w at gmail.com
Sun May 1 21:16:49 CEST 2011
I looked into the cycles code for lights and some parts were rather
hard to read/understand. This was mainly because due to how scene data
gets passed to the render kernels. All the scene data is stored in
float, float4, uchar4,.. textures. For e.g. for a light a
"__light_distribution" float4 texture is stored where the x, y, z and
w decode different data of the light source.
However, there is no general definition or documentation, what 'x',
'y', 'z' and 'w' might store, so you really have to go through the
entire code, which sets them to understand, what they really encode.
In the case of lamps, someone can also see, that each of those four
floats doesn't even encode a specific variable, which might be passed
to the kernel, but the rather encodes a more complex protocol.
x: the total accumulated area
y: in case of a triangle light source this encodes the index of the
triangle in the mesh with a positive integer value. In the case of a
point light source, this encodes the index of the light with a
negative integer. The sign represents the type of the light source.
z: set to a constant 1.0f. In the kernel code this is then assigned
'to a weight' variable, but just from reading light.cpp you would
never figure out, that this is some sort of weighting
(distribution[offset].z = 1.0f;)
w: In case the light source is a triangle, so if y > 0, then this
encodes the object id, to which the triangle belongs to. Otherwise, in
the case of point light, this encodes the unimplemented 'radius' of a
Please note, that this protocol, of how to pass data to the kernel is
not documented, I have just read light.cpp a couple of minutes to
figure this out. When writing a kernel, you now have to know this
protocol and acess x,y,z and w accordingly.
Of course it is necessary to pass all the scene data compactly with
textures, but in my opinion it can't be done as in the case of the
light source. Someone needs to set and access this data with named
variables and not implicitly by x,y,z and w. Also when writing a
kernel, it shouldn't be necessary to understand such a completely
obfuscated protocol. Not even documenting it would solve the real
I haven't looked too much into other parts of the code, which pass
data to a kernel, but I guess they have the same issues.
More information about the Bf-cycles