Welcome to mirror list, hosted at ThFree Co, Russian Federation.

git.blender.org/blender.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-10-26Cycles: remove prefix from source code file namesBrecht Van Lommel
Remove prefix of filenames that is the same as the folder name. This used to help when #includes were using individual files, but now they are always relative to the cycles root directory and so the prefixes are redundant. For patches and branches, git merge and rebase should be able to detect the renames and move over code to the right file.
2021-10-26Cycles: changes to source code folders structureBrecht Van Lommel
* Split render/ into scene/ and session/. The scene/ folder now contains the scene and its nodes. The session/ folder contains the render session and associated data structures like drivers and render buffers. * Move top level kernel headers into new folders kernel/camera/, kernel/film/, kernel/light/, kernel/sample/, kernel/util/ * Move integrator related kernel headers into kernel/integrator/ * Move OSL shaders from kernel/shaders/ to kernel/osl/shaders/ For patches and branches, git merge and rebase should be able to detect the renames and move over code to the right file.
2021-10-06Cycles: fully decouple triangle and curve primitive storage from BVH2Brecht Van Lommel
Previously the storage here was optimized to avoid indirections in BVH2 traversal. This helps improve performance a bit, but makes performance and memory usage of Embree and OptiX BVHs a bit worse also. It also adds code complexity in other parts of the code. Now decouple triangle and curve primitive storage from BVH2. * Reduced peak memory usage on all devices * Bit better performance for OptiX and Embree * Bit worse performance for CUDA * Simplified code: ** Intersection.prim/object now matches ShaderData.prim/object ** No more offset manipulation for mesh displacement before a BVH is built ** Remove primitive packing code and flags for Embree and OptiX ** Curve segments are now stored in a KernelCurve struct * Also happens to fix a bug in baking with incorrect prim/object Fixes T91968, T91770, T91902 Differential Revision: https://developer.blender.org/D12766
2021-09-21Cycles: merge of cycles-x branch, a major update to the rendererBrecht Van Lommel
This includes much improved GPU rendering performance, viewport interactivity, new shadow catcher, revamped sampling settings, subsurface scattering anisotropy, new GPU volume sampling, improved PMJ sampling pattern, and more. Some features have also been removed or changed, breaking backwards compatibility. Including the removal of the OpenCL backend, for which alternatives are under development. Release notes and code docs: https://wiki.blender.org/wiki/Reference/Release_Notes/3.0/Cycles https://wiki.blender.org/wiki/Source/Render/Cycles Credits: * Sergey Sharybin * Brecht Van Lommel * Patrick Mours (OptiX backend) * Christophe Hery (subsurface scattering anisotropy) * William Leeson (PMJ sampling pattern) * Alaska (various fixes and tweaks) * Thomas Dinges (various fixes) For the full commit history, see the cycles-x branch. This squashes together all the changes since intermediate changes would often fail building or tests. Ref T87839, T87837, T87836 Fixes T90734, T89353, T80267, T80267, T77185, T69800
2021-02-17Cycles: add utility functions for zero float2/float3/float4/transformBrecht Van Lommel
Ref D8237, T78710
2021-02-17Cycles: refactor intrinsic functions implementationBrecht Van Lommel
* Add processor independent fallbacks * Use uint32_t and uint64_t types * Remove unused functions * Better comments and less indentation Ref D8237, T78710
2021-02-05Cleanup: correct spelling in commentsCampbell Barton
2020-11-04Cycles API: encapsulate Node socket membersKévin Dietrich
This encapsulates Node socket members behind a set of specific methods; as such it is no longer possible to directly access Node class members from exporters and parts of Cycles. The methods are defined via the NODE_SOCKET_API macros in `graph/ node.h`, and are for getting or setting a specific socket's value, as well as querying or modifying the state of its update flag. The setters will check whether the value has changed and tag the socket as modified appropriately. This will let us know how a Node has changed and what to update, which is the first concrete step toward a more granular scene update system. Since the setters will tag the Node sockets as modified when passed different data, this patch also removes the various modified methods on Nodes in favor of Node::is_modified which checks the sockets' update flags status. Reviewed By: brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D8544
2020-10-27Revert "Cycles API: encapsulate Node socket members"Brecht Van Lommel
This reverts commit 527f8b32b32187f754e5b176db6377736f9cb8ff. It is causing motion blur test failures and crashes in some renders, reverting until this is fixed.
2020-10-27Cycles API: encapsulate Node socket membersKévin Dietrich
This encapsulates Node socket members behind a set of specific methods; as such it is no longer possible to directly access Node class members from exporters and parts of Cycles. The methods are defined via the NODE_SOCKET_API macros in `graph/ node.h`, and are for getting or setting a specific socket's value, as well as querying or modifying the state of its update flag. The setters will check whether the value has changed and tag the socket as modified appropriately. This will let us know how a Node has changed and what to update, which is the first concrete step toward a more granular scene update system. Since the setters will tag the Node sockets as modified when passed different data, this patch also removes the various `modified` methods on Nodes in favor of `Node::is_modified` which checks the sockets' update flags status. Reviewed By: brecht Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D8544
2020-08-19Cycles : add a Volume Geometry NodeKévin Dietrich
This splits the volume related data (properties for rendering and attributes) of the Mesh node into a new `Volume` node type. This `Volume` node derives from the `Mesh` class since we generate a mesh for the bounds of the volume, as such we can safely work on `Volumes` as if they were `Meshes`, e.g. for BVH creation. However such code should still check for the geometry type of the object to be `MESH` or `VOLUME` which may be bug prone if this is forgotten. This is part of T79131. Reviewed By: brecht Maniphest Tasks: T79131 Differential Revision: https://developer.blender.org/D8538
2020-06-22Cycles: internal refactoring to make thick/ribbon curve separate primitivesBrecht Van Lommel
Also removing the curve system manager which only stored a few curve intersection settings. These are all changes towards making shape and subdivision settings per-object instead of per-scene, but there is more work to do here. Ref T73778 Depends on D8013 Maniphest Tasks: T73778 Differential Revision: https://developer.blender.org/D8014
2020-06-22Cycles: use TBB for task pools and task schedulerBrecht Van Lommel
No significant performance improvement is expected, but it means we have a single thread pool throughout Blender. And it should make adding more parallellization in the future easier. After previous refactoring commits this is basically a drop-in replacement. One difference is that the task pool had a mechanism for scheduling tasks to the front of the queue to minimize memory usage. TBB has a smarter algorithm to balance depth-first and breadth-first scheduling of tasks and we assume that removes the need to manually provide hints to the scheduler. Fixes T77533
2020-06-22Cleanup: use lambdas instead of functors for task pools, remove threadidBrecht Van Lommel
2020-06-22Cycles: make TBB a required library dependency, and use in a few placesBrecht Van Lommel
Now that the rest of Blender also relies on TBB, no point in maintaining custom code for paraller_for and thread local storage.
2020-06-04Cleanup: remove unused flagBrecht Van Lommel
2020-03-19Cleanup: `make format` after SortedIncludes changeDalai Felinto
2020-02-07Cleanup: split Cycles Hair and Mesh classes, with Geometry base classBrecht Van Lommel
2019-04-17ClangFormat: apply to source, most of internCampbell Barton
Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2018-01-19Cycles: Remove unneeded include statementsSergey Sharybin
Also try to move them from headers to implementation files as much as possible.
2017-10-18Cycles: Fix wrong shading when some mesh triangle has non-finite coordinateSergey Sharybin
This is fully unpredictable for artists when one damaged object makes the whole scene to render incorrectly. This involves two main changes: - It is not enough to check triangle bounds to be valid when building BVH. This is because triangle might have some finite vertices and some non-finite. - We shouldn't add non-finite triangle area to the overall area for MIS.
2017-08-31Cycles: Fix typo in commentSergey Sharybin
2017-08-23Cycles: Add maximum depth stat to bvh builderMai Lavelle
2017-08-14Cycles: Guard memcpy to potentially re-allocating memory with lockSergey Sharybin
Basically, make re-alloc and memcpy from the same lock, otherwise one thread might be re-allocating thread while another one is trying to copy data there. Reported by Mohamed Sakr in IRC, thanks!
2017-08-10Cycles: Fix instanced shadow catcher objects influencing each otherSergey Sharybin
2017-04-13Cycles: Header cleanup in BVH: move self header to be the first oneSergey Sharybin
This makes us more sure that header files are more self-sufficient.
2017-03-29Cycles: Cleanup, don't use m_ prefix for public propertiesSergey Sharybin
2017-03-29Cycles: Make all #include statements relative to cycles source directorySergey 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
2017-02-25Fix build error with macOS / clang / c++11.Brecht Van Lommel
2017-02-15Cycles: Don't calculate primitive time if BVH motion steps are not usedSergey Sharybin
Solves memory regression by the default configuration.
2017-02-15Cycles: Fix wrong hair render results when using BVH motion stepsSergey Sharybin
The issue here was mainly coming from minimal pixel width feature which is quite commonly enabled in production shots. This feature will use some probabilistic heuristic in the curve intersection function to check whether we need to return intersection or not. This probability is calculated for every intersection check. Now, when we use multiple BVH nodes for curve primitives we increase probability of that primitive to be considered a good intersection for us. This is similar to increasing minimal width of curve. What is worst here is that change in the intersection probability fully depends on exact layout of BVH, meaning probability might change differently depending on a view angle, the way how builder binned the primitives and such. This makes it impossible to do simple check like dividing probability by number of BVH steps. Other solution might have been to split BVH into fully independent trees, but that will increase memory usage of all the static objects in the scenes, which is also not something desirable. For now used most simple but robust approach: store BVH primitives time and test it in curve intersection functions. This solves the regression, but has two downsides: - Uses more memory. which isn't surprising, and ANY solution to this problem will use more memory. What we still have to do is to avoid this memory increase for cases when we don't use BVH motion steps. - Reduces number of maximum available textures on pre-kepler cards. There is not much we can do here, hardware gets old but we need to move forward on more modern hardware..
2017-01-24Cycles: Don't rely on indirectly included algorithmSergey Sharybin
2017-01-20Cycles: Use more const qualifiers to avoid possible issuesSergey Sharybin
2017-01-20Cycles: Cleanup, split one gigantic function into two smaller onesSergey Sharybin
2017-01-20Cycles: Store time in BVH nodesSergey Sharybin
This way we can stop traversing BVH node early on. Gives about 2-2.5x times render time improvement with 3 BVH steps. Hopefully this gives no measurable performance loss for scenes with single BVH step. Traversal is currently only implemented for QBVH, meaning old CPUs and GPU do not benefit from this change.
2017-01-20Cycles: Add option to split triangle motion primitives by time stepsSergey Sharybin
Similar to the previous commit, the statistics goes as: BVH Steps Render time (sec) Memory usage (MB) 0 46 260 1 27 373 2 18 598 3 15 826 Scene used for the tests is the agent's body from one of the barber shop scenes (no textures or anything, just a diffuse material). Once again this is limited to regular (non-spatial split) BVH, Support of spatial split to this feature will come later.
2017-01-20Cycles: Add option to split curve motion primitives by time stepsSergey Sharybin
The idea is to create several smaller BVH nodes for each of the motion curve primitives. This acts as a forced spatial split for the single primitive. This gives up render time speedup of motion blurred hair in the cost of extra memory usage. The numbers goes as: BVH Steps Render time (sec) Memory usage (MB) 0 258 191 1 123 278 2 69 453 3 43 627 Scene used for the tests is the agent's hair from one of the barber shop scenes. Currently it's only limited to scenes without spatial split enabled, since the spatial split builder requires some changes to work properly with motion steps coordinates.
2017-01-20Cycles: Cleanup, trailing whitespaceSergey Sharybin
2017-01-20Cycles: Cleanup, better variable nameSergey Sharybin
2017-01-16Cycles: Cleanup, spellingSergey Sharybin
2017-01-16Cycles: Cleanup, avoid shadowingSergey Sharybin
2017-01-13Cycles: Simplify some code in Curve BVH reference fillSergey Sharybin
makes code slightly shorter and uses idea of const qualifiers.
2017-01-13Cycles: Avoid shadowing in BVH codeSergey Sharybin
Run into some nasty bugs while trying various things here. Wouldn't mind enabling -Wshadow for Cycles actually..
2017-01-12Cycles: Use separate limit for motion primitives for BVH node limitsSergey Sharybin
This way we can have different limits for regular and motion curves which we'll do in one of the upcoming commits in order to gain some percents of speedup. The reasoning here is that motion curves are usually intersecting lots of others bounding boxes, which makes it inefficient to have single primitive in the leaf node.
2017-01-12Cycles: Change confusing logic of max leaf size checkSergey Sharybin
Maximal number of elements is supposed to be inclusive. That is what it was always meant in this file and what @brecht considered still the case in 6974b69c6172. In fact, the commit message to that change mentions that we allowed up to 2 curve primitives per leaf while in fact it was doing up to 1 curve primitive. Making it real 2 primitives at a max gives about 5% slowdown for the koro.blend scene. This is a reason why BVHParams.max_curve_leaf_size was changed to 1 by this change.
2016-10-24Cycles: Fix uninitialized variable from the previous commitSergey Sharybin
2016-10-24Fix T49818: Crash when rendering with motion blurSergey Sharybin
It was possible to have non-initialized unaligned BVH split to be used when regular BVH split SAH was inf. Now we ensure that unaligned splitter is only used when it's really initialized. It's a regression and should be in 2.78a.
2016-10-24Cycles: Cleanup, spacesSergey Sharybin
2016-08-18Cycles: Fix wrong allocator used for spatial builderSergey Sharybin
2016-07-07Cycles: Implement unaligned nodes BVH builderSergey Sharybin
This is a special builder type which is allowed to orient nodes to strands direction, hence minimizing their surface area in comparison with axis-aligned nodes. Such nodes are much more efficient for hair rendering. Implementation of BVH builder is based on Embree, and generally idea there is to calculate axis-aligned SAH and oriented SAH and if SAH of oriented node is smaller than axis-aligned SAH we create unaligned node. We store both aligned and unaligned nodes in the same tree (which seems to be different from what Embree is doing) so we don't have any any extra calculations needed to set up hair ray for BVH traversal, hence avoiding any possible negative effect of this new BVH nodes type. This new builder is currently not in use, still need to make BVH traversal code aware of unaligned nodes.