Fixes for API changes in OSL RendererServices:
* Added two new required get_matrix methods, from OSL RendererServices (otherwise the constructor fails). The two new matrix methods probably still need an implementation.
* Removed deprecated "get_pointcloud_attr_query" and "pointcloud". There are two new routines for pointclouds, function headers for those are there.
* Removed the (unused) PARTIO code parts from OSL. It was marked as not tested / not working, and due to the api changes here broken for sure. Code is still in svn history if needed.
* Location: Basically the same as the location from Object Info node for object instances on particles, but in principle there could be additional offsets for dupli objects, so included for completeness.
* Size: Single float scale of the particle. Also directly translates to object scale for current dupli objects, but handy to have as a single float to start with instead of a scale vector (currently not even exposed in Object Info).
* Rotation: This is a quaternion, which are not yet supported by Cycles nodes. The float4 is copied to internal Cycles data and stored in the particles texture data, but the node doesn't have a socket for it yet and the data is not yet written to the stack. Code is just commented out so could be enabled quickly if/when rotation support is added to cycles.
* Velocity: Linear velocity vector of particles.
* Angular Velocity: Angular velocity around principle axes.
The texture data is currently packed tightly into the particles texture, which saves a few bytes, but requires an additional texture lookup for some vector attributes which spread over two float4s. Could also add another float4 to particle size to avoid this.
the implementation was following my early commit for Math node
I haven't had a chance to run those through Brecht, but would like to do eventually. (they work fine though)
It was read of initialized memory around holdout_weight in cases when
holdout material is used. Seems that it should be assigned to result
of shader_holdout_eval here.
If Brecht could double check this it'll be great.
This could potentially fix#32224: Holdout Error with CUDA Cycles Render
direct and indirect lighting differently. Rather than picking one light for each
point on the path, it now loops over all lights for direct lighting. For indirect
lighting it still picks a random light each time.
It gives control over the number of AA samples, and the number of Diffuse, Glossy,
Transmission, AO, Mesh Light, Background and Lamp samples for each AA sample.
This helps tuning render performance/noise and tends to give less noise for renders
dominated by direct lighting.
This sampling mode only works on the CPU, and still needs proper tile rendering
to show progress (will follow tommorrow or so), because each AA sample can be quite
slow now and so the delay between each update wil be too long.
* Removed a workaround for the NodeType enum, uses consecutive values now.
I could not find issues with CUDA, when compiling with Toolkit 4.2 (all sm kernels) and regression files rendered fine on my GPU with sm_21.
The particle data is stored in a separate texture if any of the dupli objects uses particle info nodes in shaders. To map dupli objects onto particles the store an additional particle_index value, which is different from the simple dupli object index (only visible particles, also works for particle dupli groups mode).
Some simple use cases on the code.blender.org blog:
http://code.blender.org/index.php/2012/05/particle-info-node/
