git.blender.org/blender.git - Unnamed repository; edit this file 'description' to name the repository.

Age	Commit message (Collapse)	Author
2017-03-29	Cycles: Make all #include statements relative to cycles source directory	Sergey Sharybin
	The idea is to make include statements more explicit and obvious where the file is coming from, additionally reducing chance of wrong header being picked up. For example, it was not obvious whether bvh.h was refferring to builder or traversal, whenter node.h is a generic graph node or a shader node and cases like that. Surely this might look obvious for the active developers, but after some time of not touching the code it becomes less obvious where file is coming from. This was briefly mentioned in T50824 and seems @brecht is fine with such explicitness, but need to agree with all active developers before committing this. Please note that this patch is lacking changes related on GPU/OpenCL support. This will be solved if/when we all agree this is a good idea to move forward. Reviewers: brecht, lukasstockner97, maiself, nirved, dingto, juicyfruit, swerner Reviewed By: lukasstockner97, maiself, nirved, dingto Subscribers: brecht Differential Revision: https://developer.blender.org/D2586
2016-05-11	Cycles: Use explicit qualifier for single-argument constructors	Sergey Sharybin
	Almost in all cases we want such constructors to be explicit, there are exceptions but only in few places.
2016-04-04	Cycles: Log overall time spent on building object's BVH	Sergey Sharybin
	We had per-tree statistics already, but it's a bit tricky to see overall time because trees could be building in parallel. In fact, we can now print statistics for any TaskPool.
2016-04-01	Cycles: Report thread ID from worker thread to callbacks	Sergey Sharybin
	Main use case of this ID will be to emulate TLS which otherwise would require having some platform-specific implementations which is not always really optimal. See notes about the argument in util_task.h.
2016-02-12	Cycles: Always use guarded allocator of vectors	Sergey Sharybin
	We don't have vectors re-allocation happening multiple times from inside a loop anymore, so we can safely switch to a memory guarded allocator for vectors and keep track on the memory usage at various stages of rendering. Additionally, when building from inside Blender repository, Cycles will use Blender's guarded allocator, so actual memory usage will be displayed in the Space Info header. There are couple of tricky aspects of the patch: - TaskScheduler::exit() now explicitly frees memory used by `threads`. This is needed because `threads` is a static member which destructor isn't getting called on Blender's exit which caused memory leak print to happen. This shouldn't give any measurable speed issues, reallocation of that vector is only one of fewzillion other allocations happening during synchronization. - Use regular guarded malloc (not aligned one). No idea why it was made to be aligned in the first place. Perhaps some corner case tests or so. Vector was never expected to be aligned anyway. Let's see if we'll have actual bugs with this. Reviewers: dingto, lukasstockner97, juicyfruit, brecht Reviewed By: brecht Differential Revision: https://developer.blender.org/D1774
2015-03-29	Optionally use c++11 stuff instead of boost in cycles where possible. We do ↵	Martijn Berger
	and continue to depend on boost though Reviewers: dingto, sergey Reviewed By: sergey Subscribers: #cycles Differential Revision: https://developer.blender.org/D1185
2014-12-25	Cleanup: Fix Cycles Apache header.	Thomas Dinges
	This was already mixed a bit, but the dot belongs there.
2013-10-26	spelling: use American spelling for canceled	Campbell Barton

2013-08-31	Fix #36137: cycles render not using all GPU's when the number of GPU's is larger	Brecht Van Lommel
	than the number of CPU threads
2013-08-18	Cycles: relicense GNU GPL source code to Apache version 2.0.	Brecht Van Lommel
	More information in this post: http://code.blender.org/ Thanks to all contributes for giving their permission!
2013-07-20	Cycles / CPU Rendering:	Thomas Dinges
	* "Auto Detect" now again uses the umber of cores, instead number of cores + 1. This was added before we had Tile rendering and benchmarks on several systems showed that there is no gain with this now. There might be some slight difference (0.5% or so) slower/faster depending on the scene, but this is negligible.
2013-01-25	Fix cycles crash that happened with mesh emission and diffuse/glossy ray	Brecht Van Lommel
	visibility disabled on some objects.
2012-11-08	Fix #33107: cycles fixed threads 1 was still having two cores do work,	Brecht Van Lommel
	because main thread works as well.
2012-10-22	Fix related to #32929: update list of available devices for cycles rendering	Brecht Van Lommel
	while Blender is running, not only on load. It might help a case when Blender is started before the CUDA driver is fully initialized.
2012-05-11	Cycles: reviewed the task scheduler code and fixed (hopefully all) windows ↵	Brecht Van Lommel
	threading problems.
2012-05-05	Cycles: threading optimizations	Brecht Van Lommel
	* Multithreaded image loading, each thread can load a separate image. * Better multithreading for multiple instanced meshes, different threads can now build BVH's for different meshes, rather than all cooperating on the same mesh. Especially noticeable for dynamic BVH building for the viewport, gave about 2x faster build on 8 core in fairly complex scene with many objects. * The main thread waiting for worker threads can now also work itself, so (num_cores + 1) threads will be working, this supposedly gives better performance on some operating systems, but did not measure performance for this very detailed yet.
2012-04-28	Cycles: merging features from tomato branch.	Brecht Van Lommel
	=== 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.