precompiled cubins instead,
Logic here is following now:
- If there're precompiled cubins, assume CUDA compute is available,
otherwise
- If cuda toolkit found, assume CUDA compute is available
- In all other cases CUDA compute is not available
For windows there're still check for only precompiled binaries,
no runtime compilation is allowed.
Ended up with such decision after discussion with Brecht. The thing
is, if we'll support runtime compilation on windows we'll end up
having lots of reports about different aspects of something doesn't
work (you need particular toolkit version, msvc installed, environment
variables set properly and so) and giving feedback on such reports
will waste time.
big lamps and sharp glossy reflections. This was already supported for mesh
lights and the background, so lamps should do it too.
This is not for free and it's a bit slower than I hoped even though there is
no extra BVH ray intersection. I'll try to optimize it more later.
* Area lights look a bit different now, they had the wrong shape before.
* Also fixes a sampling issue in the non-progressive integrator.
* Only enabled for the CPU, will test on the GPU later.
* An option to disable this will be added for situations where it does not help.
Same time comparison before/after:
http://www.pasteall.org/pic/show.php?id=43313http://www.pasteall.org/pic/show.php?id=43314
should be no functional changes yet. UV, tangent and intercept are now stored
as attributes, with the intention to add more like multiple uv's, vertex
colors, generated coordinates and motion vectors later.
Things got a bit messy due to having both triangle and curve data in the same
mesh data structure, which also gives us two sets of attributes. This will get
cleaned up when we split the mesh class.
Patch [#33445] - Experimental Cycles Hair Rendering (CPU only)
This patch allows hair data to be exported to cycles and introduces a new line segment primitive to render with.
The UI appears under the particle tab and there is a new hair info node available.
It is only available under the experimental feature set and for cpu rendering.
a size parameter between 0.0 and 1.0 that gives a angle of reflection between
0° and 90°, and a smooth parameter that gives and angle over which a smooth
transition from full to no reflection happens.
These work with global illumination and do importance sampling of the area within
the angle. Note that unlike most other BSDF's these are not energy conserving in
general, in particular if their weight is 1.0 and size > 2/3 (or 60°) they will
add more energy in each bounce.
Diffuse: http://www.pasteall.org/pic/show.php?id=42119
Specular: http://www.pasteall.org/pic/show.php?id=42120
Also some simple OSL optimization, passing thread data pointer directly instead
of via thread local storage, and creating ustrings for attribute lookup.
Now one no longer needs to match the sensor dimensions with the render dimensions manually.
IMPORTANT NOTE: if you were using AUTO before with mismathing sensor aspect ratio (comparing to the render dimensions)
this will change your render! We can doversion this, but apart from Tube project I don't know if anyone else
is using this yet (part due to this bug and the only recently fixed 3dview preview aspect ratio).
That should help more artists to take advantage of this fantastic Blender feature.
It still helps to know the parameters of kwnown cameras/lens though.
For example:
Nikon DX2S with a 10.5mm fisheye can be set with:
Render resolution: 4288 x 2848
Sensor 23.7 x 15.70 (15.70 can be ommitted if AUTO is used as fit method)
Note: some cameras render different sizes according to the recording mode.
For example, a Red Scarlet in 5k (@12 fps) can render a full circular fisheye with a sigma 4.5 lens.
The same camera in the 30fps recording mode renders 4k in a cropped circular image.
So it's not only the resolution that changes, but the actual sensor been used.
So just keep in mind that the more information you have from the camera/lens you want to emulate the better.
Bug found at/patch written as a follow up of the BlenderPRO2012, patch reviewed by Brecht Van Lommel
problem is that the curved interpolation is not constant speed which leads to
mismatches. Turns out this is really hard to solve and implement efficiently, so
curved motion blur is disabled for now, until I can find a solution.
This option enables keeping loaded images in the memory in-between
of rendering.
Implemented by keeping render engine alive for until Render structure
is being freed.
Cycles will free all data when render finishes, optionally keeping
image manager untouched. All shaders, meshes, objects will be
re-allocated next time rendering happens.
Cycles cession and scene will be re-created from scratch if render/
scene parameters were changed.
This will also allow to keep compiled OSL shaders in memory without
need to re-compile them again.
P.S. Performance panel could be cleaned up a bit, not so much happy
with it's vertical alignment currently but not sure how to make
it look better.
P.P.S. Currently the only way to free images from the device is to
disable Persistent Images option and start rendering.
This commit adds memory usage information while rendering.
It reports memory used by device, meaning:
- For CPU it'll report real memory consumption
- For GPU rendering it'll report GPU memory consumption, but it'll
also mean the same memory is used from host side.
This information displays information about memory requested by Cycles,
not memory really allocated on a device. Real memory usage might be
higher because of memory fragmentation or optimistic memory allocator.
There's really nothing we can do against this.
Also in contrast with blender internal's render cycles memory usage
does not include memory used by scene, only memory needed by cycles
itself will be displayed. So don't freak out if memory usage reported
by cycles would be much lower than blender internal's.
This commit also adds RenderEngine.update_memory_stats callback which
is used to tell memory consumption from external engine to blender.
This information is used to generate information line after rendering
is finished.
Documentation here:
http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/OSLhttp://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.65/Cycles
These changes require an OSL build from this repository:
https://github.com/DingTo/OpenShadingLanguage
The lib/ OSL has not been updated yet, so you might want to keep OSL disabled
until that is done.
Still todo:
* Auto update for external .osl files not working currently, press update manually
* Node could indicate better when a refresh is needed
* Attributes like UV or generated coordinates may be missing when requested from
an OSL shader, need a way to request them to be loaded by cycles
* Expose string, enum and other non-socket parameters
* Scons build support
Thanks to Thomas, Lukas and Dalai for the implementation.
* Moved kernel/osl/nodes to kernel/shaders
* Renamed standard attributes to use geom:, particle:, object: prefixes
* Update stdosl.h to properly reflect the closures we support
* Fix the wrong stdosl.h being used for building shaders
* Add geom:numpolyvertices, geom:trianglevertices, geom:polyvertices attributes
- move object_iterators.c --> view3d_iterators. (ED_object.h had to include ED_view3d.h which isn't so nice)
- move projection functions from view3d_view.c --> view3d_project.c (view3d_view was becoming a mishmash of utility functions and operators).
- some some cmake includes as system-includes.
It's using the Ward BSDF currently, which has some energy loss so might be a bit
dark. More/better BSDF options can be implemented later.
Patch by Mike Farnsworth, some modifications by me. Currently it's not possible yet
to set a custom tangent, that will follow as part of per-bsdf normals patch.
When the scene is updated Cycles resets the renderer device, cancelling
all existing tasks. The main thread would wait for all running tasks to
finish before continuing. This is ok when tasks can actually cancel in a
timely fashion. For OSL however, this does not work, since the OSL
shader group optimization takes quite a bit of time and can not be
easily be cancelled once running (on my crappy machine in full debug
mode: ~0.12 seconds for simple node trees). This would lead to very
laggy UI behavior and make it difficult to accurately control elements
such as sliders.
This patch removes the wait condition from the device->task_cancel
method. Instead it just sets the do_cancel flag and returns. To avoid
backlog in the task pool of the device it will return early from the
BlenderSession::sync function while the reset is going on (tested in
Session::resetting). Once all existing tasks have finished the do_cancel
flag is finally cleared again (checked in TaskPool::num_decrease).
Care has to be taken to avoid race conditions on the do_cancel flag,
since it can now be modified outside the TaskPool::cancel function
itself. For this purpose the scope of the TaskPool::num_mutex locks has
been extended, in most cases the mutex is now locked by the TaskPool
itself before calling TaskScheduler methods, instead of only locking
inside the num_increase/num_decrease functions themselves. The only
occurrence of a lock outside of the TaskPool methods is in
TaskScheduler::thread_run.
This patch is most useful in combination with the OSL renderer mode, so
it can probably wait until after the 2.64 release. SVM tasks tend to be
cancelled quickly, so the effect is less noticeable.
Regular rendering now works tiled, and supports save buffers to save memory
during render and cache render results.
Brick texture node by Thomas.
http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/Textures#Brick_Texture
Image texture Blended Box Mapping.
http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/Textures#Image_Texturehttp://mango.blender.org/production/blended_box/
Various bug fixes by Sergey and Campbell.
* Fix for reading freed memory in some node setups.
* Fix incorrect memory read when synchronizing mesh motion.
* Fix crash appearing when direct light usage is different on different layers.
* Fix for vector pass gives wrong result in some circumstances.
* Fix for wrong resolution used for rendering Render Layer node.
* Option to cancel rendering when doing initial synchronization.
* No more texture limit when using CPU render.
* Many fixes for new tiled rendering.
This patch switches from boost's filesystem v2 to v3.
This should be completely smooth due to filesystem v3 is pretty
old already.
Patch by Sven-Hendrik Haase (aka svenstaro), thanks!
