well as I would like, but it works, just add a subsurface scattering node and
you can use it like any other BSDF.
It is using fully raytraced sampling compatible with progressive rendering
and other more advanced rendering algorithms we might used in the future, and
it uses no extra memory so it's suitable for complex scenes.
Disadvantage is that it can be quite noisy and slow. Two limitations that will
be solved are that it does not work with bump mapping yet, and that the falloff
function used is a simple cubic function, it's not using the real BSSRDF
falloff function yet.
The node has a color input, along with a scattering radius for each RGB color
channel along with an overall scale factor for the radii.
There is also no GPU support yet, will test if I can get that working later.
Node Documentation:
http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/Shaders#BSSRDF
Implementation notes:
http://wiki.blender.org/index.php/Dev:2.6/Source/Render/Cycles/Subsurface_Scattering
* Unnecessary shader inputs inside the Mix Shader are now ignored, in case the factor is 0.0 / 1.0 and not connected.
This way we save some render time for complex node graphs.
Example: http://www.pasteall.org/pic/show.php?id=48226
Check the Mix Shader at the end: In this case, Cycles will now avoid the complete huge shader tree, and only calculate the Diffuse Shader.
Rendertime decreased from 1:50 min to 1:20 min on CPU. GPU rendering benefits as well from this.
This only affects SVM, OSL was already doing these optimizations.
- pass string size to BLI_timestr() to avoid possible buffer overrun.
- quiet warning for mingw.
- include guards for windows utf conversion funcs.
- fix for mistage in edge-angle-selection check.
- some style cleanup.
* Move OpenGL settings out of the film panel into its own.
Imho these should go completely elsewhere, but better separated than mixed with Cycles settings.
The issue here was that the proxy nodes created for connecting extern group node sockets to the internal nodes were generated by the input/output nodes themselves.
0 input/output nodes: there would be no proxy that external group node sockets can map to
2+ input/output nodes: additional nodes would overwrite entries from previous nodes, so that only one of the input/output nodes would be used.
Solution is to always generate exactly 1 proxy node for every group socket in advance, regardless of whether it is used internally. Internal node sockets can then all map to this proxy node.
In the case out output nodes there should only ever be one active node, otherwise the connection to the proxy would be ambiguous. For this purpose the NODE_DO_OUTPUT flag has been exposed to RNA, so that cycles can check it and only use the active output.
PyNodes opens up the node system in Blender to scripters and adds a number of UI-level improvements.
=== Dynamic node type registration ===
Node types can now be added at runtime, using the RNA registration mechanism from python. This enables addons such as render engines to create a complete user interface with nodes.
Examples of how such nodes can be defined can be found in my personal wiki docs atm [1] and as a script template in release/scripts/templates_py/custom_nodes.py [2].
=== Node group improvements ===
Each node editor now has a tree history of edited node groups, which allows opening and editing nested node groups. The node editor also supports pinning now, so that different spaces can be used to edit different node groups simultaneously. For more ramblings and rationale see (really old) blog post on code.blender.org [3].
The interface of node groups has been overhauled. Sockets of a node group are no longer displayed in columns on either side, but instead special input/output nodes are used to mirror group sockets inside a node tree. This solves the problem of long node lines in groups and allows more adaptable node layout. Internal sockets can be exposed from a group by either connecting to the extension sockets in input/output nodes (shown as empty circle) or by adding sockets from the node property bar in the "Interface" panel. Further details such as the socket name can also be changed there.
[1] http://wiki.blender.org/index.php/User:Phonybone/Python_Nodes
[2] http://projects.blender.org/scm/viewvc.php/trunk/blender/release/scripts/templates_py/custom_nodes.py?view=markup&root=bf-blender
[3] http://code.blender.org/index.php/2012/01/improving-node-group-interface-editing/
before this only active scene would be rendered with border.
When do_render_fields_blur_3d() is finished, it'll modify
render's display rect so it'll correspond bordered render
result placed on black backgrund. Actual border is stored
nowhere, which makes it only way to re-calculate disprect
for all other renders used in compo based on source. Not
so big deal actually.
Also needed to modify Cycles a bit, because before this
patch it used border settings from scene being rendered.
Now made it so render data is passing to external engines.
Using a property inside RenderEngine structure for this.
Not best ever design for passing render data, but this
would prevent API breakage. So now external engines could
access engine.render to access active rendering settings.
Reviewed by Brecht, thanks!
* Make Cycles aware of sm_35 (Tesla K20, GeForce GTX TITAN).
The CUDA Toolkit 5.0 is needed for that and this is not officially used yet, but people with access to such cards can start testing. (just build sm_35 kernels).
* Deprecate computing capability 1.3 (sm_13)
This commit disables auto build of sm_13 CUDA platform, which means that starting with Blender 2.67, we don't support sm_13 devices anymore. It has become difficult to support that and it was already feature incomplete (no render-passes, AO, Multi Closure etc).
It's still possible to manually enable sm_13 for own tests, but building might break in the future.
Yes, again.
There's some t within which reset is not allowed. This is so no reset happens
too often for performance issues. If camera changes too often, some reset could
be missed because of this timeout.
For now tag engine for update, which will update viewport from blender side.
Proper solution could be to detect such a changes from blender side and tag
cycles for refresh instead of trying to detect changes form cycles, but that's
for later.
