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
2022-07-21Cleanup: formatCampbell Barton
2022-07-20Cleanup: Remove unused functionHans Goudey
2022-07-09Weight & Vertex Paint: always respect edit mode hiding on faces.Alexander Gavrilov
In some cases it is mandatory to be able to hide parts of the mesh in order to paint certain areas. The Mask modifier doesn't work in weight paint, and edit mode hiding requires using selection, which is not always convenient. This makes the weight and vertex paint modes always respect edit mode hiding like sculpt mode. The change in behavior affects drawing and building paint PBVH. Thus it affects brushes, but not menu operators like Smooth or Normalize. In addition, this makes the Alt-H shortcut available even without any selection enabled, and implements Hide for vertex selection. Differential Revision: https://developer.blender.org/D14163
2022-05-30Cleanup: Clang tidyHans Goudey
Mostly duplicate includes, also use nullptr, and using default member initializers.
2022-05-24EEVEE: support Curves attributes renderingKévin Dietrich
This adds support to render Curves attributes in EEVEE. Each attribute is stored in a texture derived from a VBO. As the shading group needs the textures to be valid upon creation, the attributes are created and setup during its very creation, instead of doing it lazily via create_requested which we cannot rely on anyway as contrary to the mesh batch, we do cannot really tell if attributes need to be updated or else via some `DRW_batch_requested`. Since point attributes need refinement, and since attributes are all cast to vec4/float4 to account for differences in type conversions between Blender and OpenGL, the refinement shader for points is used as is. The point attributes are stored for each subdivision level in CurvesEvalFinalCache. Each subdivision level also keeps track of the attributes already in use so they are properly updated when needed. Some basic garbage collection was added similar to what is done for meshes: if the attributes used over time have been different from the currently used attributes for too long, then the buffers are freed, ensuring that stale attributesare removed. This adds `CurvesInfos` to the shader creation info, which stores the scope in which the attributes are defined. Scopes are stored as booleans, in an array indexed by attribute loading order which is also the order in which the attributes were added to the material. A mapping is necessary between the indices used for the scoping, and the ones used in the Curves cache, as this may contain stale attributes which have not been garbage collected yet. Common utilities with the mesh code for handling requested attributes were moved to a separate file. Differential Revision: https://developer.blender.org/D14916
2022-05-13Cleanup: spelling in comments, capitalize tagsCampbell Barton
Also add missing task-ID reference & remove colon after \note as it doesn't render properly in doxygen.
2022-05-11Cleanup: use '_num' / '_count' suffix instead of '_ct'Campbell Barton
Use num & count (for counters), in drawing code, see: T85728.
2022-05-10DrawManager: Hide lock acquire behind experimental feature.Jeroen Bakker
The acquire locking of the draw manager introduced other issues. The current implementation was a hacky solution as we know that the final solution is something totally different {T98016}. Related issues: * {T97988} * {T97600}
2022-04-29Fix rendering of wire curves when used as custom bone objectsSebastian Parborg
In the current code we do not render any curves if they have not been converted to meshes. This change makes the custom bone drawing try to render mesh objects first and then falls back to curve objects if there is no mesh data available. Reviewed By: Clement Differential Revision: http://developer.blender.org/D14804
2022-04-22Curves: Further split of curves draw code from particlesHans Goudey
Extends the changes started in f31c3f8114616bb to completely separate much of the DRW curves code from the particle hair drawing. In the short term this increases duplication, but the idea is to simplify development by making it easier to do larger changes to the new code, and the new system will replace the particle hair at some point. After this, only the shaders themselves are shared. Differential Revision: https://developer.blender.org/D14699
2022-04-19GPU: Replace `GPUMaterialVolumeGrid` by `GPUMaterialAttribute`Clément Foucault
This is to make the codegen and shading nodes object type agnostic. This is essential for flexibility of the engine to use the nodetree as it see fits. The essential volume attributes struct properties are moved to the `GPUMaterialAttribute` which see its final input name set on creation. The binding process is centralized into `draw_volume.cc` to avoid duplicating the code between multiple engines. It mimics the hair attributes process. Volume object grid transforms and other per object uniforms are packed into one UBO per object. The grid transform is now based on object which simplify the matrix preparations. This also gets rid of the double transforms and use object info orco factors for volume objects. Tagging @brecht because he did the initial implementation of Volume Grids.
2022-04-19DRW: Centralize smoke domain texture managementClément Foucault
This code was duplicated in multiple engines. Now it is the draw manager responsability to manage the throwaway fluid textures.
2022-04-15GPU: Make viewport not acquireable during renderingClément Foucault
This is a partial fix to the fact that rendering with EEVEE or other GL render engines is currently blocking the whole UI when asking to redraw a viewport. This patch just bypasses the viewport bind (containing the Draw Context lock) and the following drawing. There is an update tagging to not loose a viewport update if there was one asked. Other queries other than view redraw (such as selection depth drawing or offscreen drawing) will still block the whole UI as they need immediate data feedback. Ping @Severin for the change in `WM_draw_region_viewport_bind()`. I'm assuming this is not an issue because it's highly unlikely to bring up this operator during rendering. But in this case, it would just lock as usual. The bypassing in `DRW_notify_view_update` might be a bit overparanoid.
2022-04-08Curves edit mode: show dots for pointsKévin Dietrich
This adds support to show dots for the curves points when in edit mode, using a specific overlay. This also adds `DRW_curves_batch_cache_create_requested` which for now only creates the point buffer for the newly added `edit_points` batch. In the future, this will also handle other edit mode overlays, and probably also replace the current curves batch cache creation. Maniphest Tasks: T95770 Differential Revision: https://developer.blender.org/D14262
2022-03-30Metal: Adding alternative support for GPU_PRIM_TRI_FAN/LINE_LOOP For Metal ↵Jason Fielder
backend. - Metal uniform array compatibility in DRW module. - Guard OpenGL-specific workarounds and flushes behind GPU_type_matches_ex API guard. Add further render boundaries for render paths called outside of the main loop. Authored by Apple: Michael Parkin-White Ref: T96261 Reviewed By: fclem Differential Revision: https://developer.blender.org/D14438
2022-03-20DRW: Make use of shader shared headerClément Foucault
# Conflicts: # source/blender/draw/intern/draw_manager.h # source/blender/draw/intern/draw_manager_exec.c # source/blender/draw/intern/draw_shader_shared.h
2022-03-18EEVEE: Add new experimental "EEVEE Next" optionClément Foucault
This is supposed to hold the latest improvement from the EEVEE rewrite branch. Note that a restart is necessary in order for the engine to appear. The registration code is a bit convoluted as it needs to be after the WM_init.
2022-02-18Cleanup: Rename original curve object type enumHans Goudey
This commit renames enums related the "Curve" object type and ID type to add `_LEGACY` to the end. The idea is to make our aspirations clearer in the code and to avoid ambiguities between `CURVE` and `CURVES`. Ref T95355 To summarize for the record, the plans are: - In the short/medium term, replace the `Curve` object data type with `Curves` - In the longer term (no immediate plans), use a proper data block for 3D text and surfaces. Differential Revision: https://developer.blender.org/D14114
2022-02-11Merge branch 'blender-v3.1-release'Peter Kim
2022-02-11Fix excessive re-creation of VR viewport texturesPeter Kim
Due to the freeing and re-creation of textures performed when binding offscreen viewports, VR viewport textures would be needlessly re-created every drawing iteration, leading to a negative impact on VR frame rate. This was brought to light by 6738ecb64e8b, which introduced an additional texture clear operation on initialization and was prohibitively costly on some systems when performed every frame. Now, the textures for VR viewports will not be always re-created during offscreen binding, but only when necessary using a pre-drawing step (`wm_xr_session_surface_offscreen_ensure()`). Reviewed By: jbakker, fclem Differential Revision: https://developer.blender.org/D14059
2022-02-11File headers: SPDX License migrationCampbell Barton
Use a shorter/simpler license convention, stops the header taking so much space. Follow the SPDX license specification: https://spdx.org/licenses - C/C++/objc/objc++ - Python - Shell Scripts - CMake, GNUmakefile While most of the source tree has been included - `./extern/` was left out. - `./intern/cycles` & `./intern/atomic` are also excluded because they use different header conventions. doc/license/SPDX-license-identifiers.txt has been added to list SPDX all used identifiers. See P2788 for the script that automated these edits. Reviewed By: brecht, mont29, sergey Ref D14069
2022-02-07Curves: Rename "Hair" types, variables, and functions to "Curves"Hans Goudey
Based on discussions from T95355 and T94193, the plan is to use the name "Curves" to describe the data-block container for multiple curves. Eventually this will replace the existing "Curve" data-block. However, it will be a while before the curve data-block can be replaced so in order to distinguish the two curve types in the UI, "Hair Curves" will be used, but eventually changed back to "Curves". This patch renames "hair-related" files, functions, types, and variable names to this convention. A deep rename is preferred to keep code consistent and to avoid any "hair" terminology from leaking, since the new data-block is meant for all curve types, not just hair use cases. The downside of this naming is that the difference between "Curve" and "Curves" has become important. That was considered during design discussons and deemed acceptable, especially given the non-permanent nature of the somewhat common conflict. Some points of interest: - All DNA compatibility is lost, just like rBf59767ff9729. - I renamed `ID_HA` to `ID_CV` so there is no complete mismatch. - `hair_curves` is used where necessary to distinguish from the existing "curves" plural. - I didn't rename any of the cycles/rendering code function names, since that is also used by the old hair particle system. Differential Revision: https://developer.blender.org/D14007
2022-01-28Cleanup: spelling in commentsCampbell Barton
Also minor wording improvements.
2022-01-25Fix depsgraphs sharing IDs via evaluated edit meshSergey Sharybin
The evaluated mesh is a result of evaluated modifiers, and referencing other evaluated IDs such as materials. It can not be stored in the EditMesh structure which is intended to be re-used by many areas. Such sharing was causing ownership errors causing bugs like T93855: Cycles crash with edit mode and simultaneous viewport and final render The proposed solution is to store the evaluated edit mesh and its cage in the object's runtime field. The motivation goes as following: - It allows to avoid ownership problems like the ones in the linked report. - Object level is chosen over mesh level is because the evaluated mesh is affected by modifiers, which are on the object level. This patch allows to have modifier stack of an object which shares mesh with an object which is in edit mode to be properly taken into account (before the change the modifier stack from the active object will be used for all objects which share the mesh). There is a change in the way how copy-on-write is handled in the edit mode to allow proper state update when changing active scene (or having two windows with different scenes). Previously, the copt-on-write would have been ignored by skipping tagging CoW component. Now it is ignored from within the CoW operation callback. This allows to update edit pointers for objects which are not from the current depsgraph and where the edit_mesh was never assigned in the case when the depsgraph was evaluated prior the active depsgraph. There is no user level changes changes expected with the CoW handling changes: should not affect on neither performance, nor memory consumption. Tested scenarios: - Various modifiers configurations of objects sharing mesh and be part of the same scene. - Steps from the reports: T93855, T82952, T77359 This also fixes T76609, T72733 and perhaps other reports. Differential Revision: https://developer.blender.org/D13824
2022-01-17Revert "Revert "GPUShaderCreateInfo for interface abstraction""Jeroen Bakker
This reverts commit edee5a947b7ea3e1324aa334a22c7c9bbf47f5f7. Fixes compilation error (Missing file BLI_float2.hh)
2022-01-17Revert "GPUShaderCreateInfo for interface abstraction"Jeroen Bakker
This reverts commit 8fb2ff458ba579dba08bfdf57d043ad158b5db07. Missing some files.
2022-01-17GPUShaderCreateInfo for interface abstractionJeroen Bakker
This is a first part of the Shader Create Info system could be. A shader create info provides a way to define shader structure, resources and interfaces. This makes for a quick way to provide backend agnostic binding informations while also making shader variations easy to declare. - Clear source input (only one file). Cleans up the GPU api since we can create a shader from one descriptor - Resources and interfaces are generated by the backend (much simpler than parsing). - Bindings are explicit from position in the array. - GPUShaderInterface becomes a trivial translation of enums and string copy. - No external dependency to third party lib. - Cleaner code, less fragmentation of resources in several libs. - Easy to modify / extend at runtime. - no parser involve, very easy to code. - Does not hold any data, can be static and kept on disc. - Could hold precompiled bytecode for static shaders. This also includes a new global dependency system. GLSL shaders can include other sources by using #pragma BLENDER_REQUIRE(...). This patch already migrated several builtin shaders. Other shaders should be migrated one at a time, and could be done inside master. There is a new compile directive `WITH_GPU_SHADER_BUILDER` this is an optional directive for linting shaders to increase turn around time. What is remaining: - pyGPU API {T94975} - Migration of other shaders. This could be a community effort. Reviewed By: jbakker Maniphest Tasks: T94975 Differential Revision: https://developer.blender.org/D13360
2022-01-11Fix T94728: Auto Depth problem with Cliping RegionGermano Cavalcante
Issue introduced in rB1d49293b80446b89b5b12fa0eeefaf14e5051e48 `drw_manager_init` must be called after `drw_context_state_init` as `DST.draw_ctx.sh_cfg` (indicating when the view is clipped) must be set first. Differential Revision: https://developer.blender.org/D13795
2022-01-11Cleanup: remove unnecessary 'use_opengl_context' parameterGermano Cavalcante
The argument passed is always false.
2022-01-10Cleanup: typos in comments, remove libnumaapi referenceCampbell Barton
2022-01-07Fix T94078: Wrong Bound Box calculated for curvesGermano Cavalcante
`DEG_OBJECT_ITER_FOR_RENDER_ENGINE_BEGIN` creates temporary objects that correspond to duplicates or instances. These temporary objects can share same pointers with the original object as in the case of Bounding Box. Bound Box of temporary objects is marked dirty in `BKE_object_replace_data_on_shallow_copy` since `ob->data` is different. This causes the original Bounding Box, calculated for the evaluated geometry, to be lost. The solution in this commit is to change the boundbox reference of the temporary objects, so the boundbox of the non-temporary object (with the data curve) is not marked dirty. Differential Revision: https://developer.blender.org/D13581
2022-01-06Cleanup: spelling in commentsCampbell Barton
2021-12-27OpenSubDiv: add support for an OpenGL evaluatorKévin Dietrich
This evaluator is used in order to evaluate subdivision at render time, allowing for faster renders of meshes with a subdivision surface modifier placed at the last position in the modifier list. When evaluating the subsurf modifier, we detect whether we can delegate evaluation to the draw code. If so, the subdivision is first evaluated on the GPU using our own custom evaluator (only the coarse data needs to be initially sent to the GPU), then, buffers for the final `MeshBufferCache` are filled on the GPU using a set of compute shaders. However, some buffers are still filled on the CPU side, if doing so on the GPU is impractical (e.g. the line adjacency buffer used for x-ray, whose logic is hardly GPU compatible). This is done at the mesh buffer extraction level so that the result can be readily used in the various OpenGL engines, without having to write custom geometry or tesselation shaders. We use our own subdivision evaluation shaders, instead of OpenSubDiv's vanilla one, in order to control the data layout, and interpolation. For example, we store vertex colors as compressed 16-bit integers, while OpenSubDiv's default evaluator only work for float types. In order to still access the modified geometry on the CPU side, for use in modifiers or transform operators, a dedicated wrapper type is added `MESH_WRAPPER_TYPE_SUBD`. Subdivision will be lazily evaluated via `BKE_object_get_evaluated_mesh` which will create such a wrapper if possible. If the final subdivision surface is not needed on the CPU side, `BKE_object_get_evaluated_mesh_no_subsurf` should be used. Enabling or disabling GPU subdivision can be done through the user preferences (under Viewport -> Subdivision). See patch description for benchmarks. Reviewed By: campbellbarton, jbakker, fclem, brecht, #eevee_viewport Differential Revision: https://developer.blender.org/D12406
2021-12-14Cleanup: correct unbalanced doxygen groupsCampbell Barton
Also add groups in some files.
2021-12-08Cleanup: move public doc-strings into headers for 'draw'Campbell Barton
Ref T92709
2021-12-02Fix T93525: Crash with curve/text armature bone gizmoHans Goudey
The problem is that drw_batch_cache_generate_requested_delayed is called on the object, which uses the original object data type to choose which data type to get info for. So for curves and text it uses the incorrect type (not the evaluated mesh like we hardcoded in the armature overlay code). To fix this I hardcoded the "delayed" generation to only use the evaluated mesh. Luckily it wasn't use elsewhere besides this armature overlay system. That seems like the simplest fix for 3.0. A proper solution should rewrite this whole area anyway. Differential Revision: https://developer.blender.org/D13439
2021-11-24Cleanup: use lowercase in private functions.Jeroen Bakker
2021-11-24Cleanup: Silent compilation warning in draw_manager.Jeroen Bakker
2021-11-23Fix T89204: slow repeated rendering with GPUOffscreen.draw_view3d.Christian Stolze
Reviewed By: fclem Differential Revision: D13235
2021-10-18Fix T92250 EEVEE: Render crash with Motion Blur and OverscanClément Foucault
This was caused by `DRW_view_data_texture_list_size_validate` which now delete everything from the render engine. This might change in the future but for now we just avoid calling it from the render loop (when using DRW_cache_restart).
2021-10-12Fix T91981: Crash when using operators that needs scene depthClément Foucault
There was a double lock in the object depth drawing function. Also the texture read was not reading the texture with the right format. Now it needs a conversion. Fix T91981 Particle Edit make Blender Crash Fix T92006 Light spot interactively point can't use
2021-10-12XR Controller Support Step 4: Controller DrawingPeter Kim
Addresses T77127 (Controller Drawing). Adds VR controller visualization and custom drawing via draw handlers. Add-ons can draw to the XR surface (headset display) and mirror window by adding a View3D draw handler of region type 'XR' and draw type 'POST_VIEW'. Controller drawing and custom overlays can be toggled individually as XR session options, which will be added in a future update to the VR Scene Inspection add-on. For the actual drawing, the OpenXR XR_MSFT_controller_model extension is used to load a glTF model provided by the XR runtime. The model's vertex data is then used to create a GPUBatch in the XR session state. Finally, this batch is drawn via the XR surface draw handler mentioned above. For runtimes that do not support the controller model extension, a a simple fallback shape (sphere) is drawn instead. Reviewed By: Severin, fclem Differential Revision: https://developer.blender.org/D10948
2021-10-06Cleanup: spelling in commentsCampbell Barton
2021-10-05Fix memory leak when running test cases.Jeroen Bakker
Issue is that test cases re-uses draw manager. The new `DRWRegisteredDrawEngine` struct is only freed when a valid opengl context was found. what isn't the case when running test cases. Also made sure that re-using draw manager would use re-inited values.
2021-10-05DRW: Move buffer & temp textures & framebuffer management to DrawManagerClément Foucault
This is a necessary step for EEVEE's new arch. This moves more data to the draw manager. This makes it easier to have the render or draw engines manage their own data. This makes more sense and cleans-up what the GPUViewport holds Also rewrites the Texture pool manager to be in C++. This also move the DefaultFramebuffer/TextureList and the engine related data to a new `DRWViewData` struct. This struct manages the per view (as in stereo view) engine data. There is a bit of cleanup in the way the draw manager is setup. We now use a temporary DRWData instead of creating a dummy viewport. Development: fclem, jbakker Differential Revision: https://developer.blender.org/D11966
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-09-13Fix T91311: incorrect batch generation for instancesJacques Lucke
This was a mistake in {rB5a9a16334c573c4566dc9b2a314cf0d0ccdcb54f}.
2021-09-08Asset: Dropping Material assets on material slot under mouse cursor.Jeroen Bakker
This patch allows dropping material assets from material slot under the mouse cursor. Before this change the material slot had to be hand-picked from the properties panel. For consistency it is chosen to do this in any shading mode as the tooltip shows what is exactly going to happen during release. The feature also works for other object types than Meshes as it uses the drawn surface on the GPU to detect the material slots. Performance of this patch has been tested with AMD GCN3.0 cards and are very responsive. Reviewed By: fclem, Severin Differential Revision: https://developer.blender.org/D12190
2021-09-06Geometry Nodes: support for geometry instancingJacques Lucke
Previously, the Point Instance node in geometry nodes could only instance existing objects or collections. The reason was that large parts of Blender worked under the assumption that objects are the main unit of instancing. Now we also want to instance geometry within an object, so a slightly larger refactor was necessary. This should not affect files that do not use the new kind of instances. The main change is a redefinition of what "instanced data" is. Now, an instances is a cow-object + object-data (the geometry). This can be nicely seen in `struct DupliObject`. This allows the same object to generate multiple geometries of different types which can be instanced individually. A nice side effect of this refactor is that having multiple geometry components is not a special case in the depsgraph object iterator anymore, because those components are integrated with the `DupliObject` system. Unfortunately, different systems that work with instances in Blender (e.g. render engines and exporters) often work under the assumption that objects are the main unit of instancing. So those have to be updated as well to be able to handle the new instances. This patch updates Cycles, EEVEE and other viewport engines. Exporters have not been updated yet. Some minimal (not master-ready) changes to update the obj and alembic exporters can be found in P2336 and P2335. Different file formats may want to handle these new instances in different ways. For users, the only thing that changed is that the Point Instance node now has a geometry mode. This also fixes T88454. Differential Revision: https://developer.blender.org/D11841
2021-08-31Cleanup: DRW color management seperated in multiple functions.Jeroen Bakker