| Age | Commit message (Collapse) | Author |
|---|
|
|
|
in the outliner.
|
|
it and others not.
|
|
|
|
* Alignment fix for the "Samples" panel, this way both columns are aligned nicely.
|
|
* "preview_aa_samples" minimum should be 0, not 1.
|
|
* UI Tooltip fix.
|
|
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.
|
|
|
|
'index' member to identify dupli objects, but this is not unique and in fact just 0 in most cases. Needs to use a simple dupli list counter instead.
|
|
* Add back a break, which was deleted in r47773.
|
|
Note that currently the reroute nodes are hardcoded to color values, which means they will not work for shader type connections (and possibly cause overhead for float and vector conversion). Looking into a solution.
|
|
The image file name function was updating the iuser->framenr using a supposed cfra parameter. However, the actual cfra is unknown when loading movies or sequences, so the iuser->framenr value itself was passed in its place, leading to incremental addition of the iuser frame offset. Removed the cfra parameter altogether from the image path function. This should instead be done separately if necessary, it's not an inherent part of constructing the image file name.
|
|
|
|
|
|
the type or explicitly casting).
|
|
|
|
|
|
information in material shaders for dupli objects. For now only the particle Age and individual Lifetime (in frames) are supported, more attributes can be added when needed.
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/
|
|
camera, same as in render. It draws objects in solid draw mode outside of
the border.
|
|
|
|
|
|
dupligroups.
|
|
|
|
other places, was mainly due to instancing not working, but also found
issues in procedural textures.
The problem was with --use_fast_math, this seems to now have way lower
precision for some operations. Disabled this flag and selectively use
fast math functions. Did not find performance regression on GTX 460 after
doing this.
|
|
|
|
|
|
pass index, and a random number unique to the instance of the object.
This can be useful to give some variation to a single material assigned to
multiple instances, either manually controlled through the object index, based
on the object location, or randomized for each instance.
http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/More#Object_Info
|
|
|
|
smoothing factor to reduce high values near the light.
http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/More#Light_Falloff
Note that this was already possible to do manually with the Ray Length, but
this adds a convenient node for it. This commit also makes the mapping node
min/max option work, fixing #31348.
|
|
|
|
also stop numpy from being found in /usr/include with cmake.
|
|
visibility
rather than viewport visibility, is more useful that way.
|
|
For sample images see:
http://www.dalaifelinto.com/?p=399 (equisolid)
http://www.dalaifelinto.com/?p=389 (equidistant)
The 'use_panorama' option is now part of a new Camera type: 'Panorama'.
Created two other panorama cameras:
- Equisolid: most of lens in the market simulate this lens - e.g. Nikon, Canon, ...)
this works as a real lens up to an extent. The final result takes the
sensor dimensions into account also.
.:. to simulate a Nikon DX2S with a 10.5mm lens do:
sensor: 23.7 x 15.7
fisheye lens: 10.5
fisheye fov: 180
render dimensions: 4288 x 2848
- Equidistant: this is not a real lens model. Although the old equidistant lens simulate
this lens. The result is always as a circular fisheye that takes the whole sensor
(in other words, it doesn't take the sensor into consideration).
This is perfect for fulldomes ;)
For the UI we have 10 to 360 as soft values and 10 to 3600 as hard values (because we can).
Reference material:
http://www.hdrlabs.com/tutorials/downloads_files/HDRI%20for%20CGI.pdf
http://www.bobatkins.com/photography/technical/field_of_view.html
Note, this is not a real simulation of the light path through the lens.
The ideal solution would be this:
https://graphics.stanford.edu/wikis/cs348b-11/Assignment3
http://www.graphics.stanford.edu/papers/camera/
Thanks Brecht for the fix, suggestions and code review.
Kudos for the dome community for keeping me stimulated on the topic since 2009 ;)
Patch partly implemented during lab time at VisGraf, IMPA - Rio de Janeiro.
|
|
Fix: texture coordinate normal output was not correct, still changed under
object transform.
|
|
* Some tiny updates and cleanups to the Cycles addon entry.
|
|
Most of the changes are related to adding support for motion data throughout
the code. There's some code for actual camera/object motion blur raytracing
but it's unfinished (it badly slows down the raytracing kernel even when the
option is turned off), so that code it disabled still.
Motion vector export from Blender tries to avoid computing derived meshes
when the mesh does not have a deforming modifier, and it also won't store
motion vectors for every vertex if only the object or camera is moving.
|
|
=== BVH build time optimizations ===
* BVH building was multithreaded. Not all building is multithreaded, packing
and the initial bounding/splitting is still single threaded, but recursive
splitting is, which was the main bottleneck.
* Object splitting now uses binning rather than sorting of all elements, using
code from the Embree raytracer from Intel.
http://software.intel.com/en-us/articles/embree-photo-realistic-ray-tracing-kernels/
* Other small changes to avoid allocations, pack memory more tightly, avoid
some unnecessary operations, ...
These optimizations do not work yet when Spatial Splits are enabled, for that
more work is needed. There's also other optimizations still needed, in
particular for the case of many low poly objects, the packing step and node
memory allocation.
BVH raytracing time should remain about the same, but BVH build time should be
significantly reduced, test here show speedup of about 5x to 10x on a dual core
and 5x to 25x on an 8-core machine, depending on the scene.
=== Threads ===
Centralized task scheduler for multithreading, which is basically the
CPU device threading code wrapped into something reusable.
Basic idea is that there is a single TaskScheduler that keeps a pool of threads,
one for each core. Other places in the code can then create a TaskPool that they
can drop Tasks in to be executed by the scheduler, and wait for them to complete
or cancel them early.
=== Normal ====
Added a Normal output to the texture coordinate node. This currently
gives the object space normal, which is the same under object animation.
In the future this might become a "generated" normal so it's also stable for
deforming objects, but for now it's already useful for non-deforming objects.
=== Render Layers ===
Per render layer Samples control, leaving it to 0 will use the common scene
setting.
Environment pass will now render environment even if film is set to transparent.
Exclude Layers" added. Scene layers (all object that influence the render,
directly or indirectly) are shared between all render layers. However sometimes
it's useful to leave out some object influence for a particular render layer.
That's what this option allows you to do.
=== Filter Glossy ===
When using a value higher than 0.0, this will blur glossy reflections after
blurry bounces, to reduce noise at the cost of accuracy. 1.0 is a good
starting value to tweak.
Some light paths have a low probability of being found while contributing much
light to the pixel. As a result these light paths will be found in some pixels
and not in others, causing fireflies. An example of such a difficult path might
be a small light that is causing a small specular highlight on a sharp glossy
material, which we are seeing through a rough glossy material. With path tracing
it is difficult to find the specular highlight, but if we increase the roughness
on the material the highlight gets bigger and softer, and so easier to find.
Often this blurring will be hardly noticeable, because we are seeing it through
a blurry material anyway, but there are also cases where this will lead to a
loss of detail in lighting.
|
|
|
|
size now, this seems to work well after some testing.
Fix: material override not working on objects without a material assigned.
|
|
|
|
individual render layers.
|
|
|
|
|
|
|
|
but this makes it more reliable for now.
Also add an integrator "Clamp" option, to clamp very light samples to a maximum
value. This will reduce accuracy but may help reducing noise and speed up
convergence.
|
|
location property (for the node editor), now renamed to "translation".
|
|
emitting objects or world lighting do not contribute to the shadow pass.
Consider this more as a pass useful for some compositing tricks, unlike
other lighting passes this pass can't be used to exactly reconstruct the
combined pass.
|
|
render layer rather than the viewport layers.
|
|
|
