| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Turns out PBVH drawing and normal mesh batches are not mutually
exclusive inside the draw cache; there are edge cases with modifiers
and instancing where you need both, and forcing one or the other
inside this function leads to memory corruption.
|
|
tmp
|
|
- Remove unused include
- Avoid repeating blender:: namespace
- Remove timer left in by mistake in previous commit
|
|
On a Ryzen 3700x I observed a 4ms improvement (from 5ms to 1ms)
on every redraw when sculpting with 88000 curves.
|
|
Error in c67e5628d22f8348492 which mistook clearing
the pointer for clearing the values in the struct.
|
|
Instead of allocating three separate ThreadMutex pointers,
just embed std::mutex into the struct directly.
|
|
This commit replaces the `Mesh_Runtime` struct embedded in `Mesh`
with `blender::bke::MeshRuntime`. This has quite a few benefits:
- It's possible to use C++ types like `std::mutex`, `Array`,
`BitVector`, etc. more easily
- Meshes saved in files are slightly smaller
- Copying and writing meshes is a bit more obvious without
clearing of runtime data, etc.
The first is by far the most important. It will allows us to avoid a
bunch of manual memory management boilerplate that is error-prone and
annoying. It should also simplify future CoW improvements for runtime
data.
This patch doesn't change anything besides changing `mesh.runtime.data`
to `mesh.runtime->data`. The cleanups above will happen separately.
Differential Revision: https://developer.blender.org/D16180
|
|
Allows improving performance with BLI_task.hh in draw extraction code.
Threading added in c15a63d21eae49ffd improved performance by 3-4x
for me, but didn't make a difference until now.
|
|
|
|
|
|
This adds the possibility to use the C++ API for other GPUTexture.
|
|
|
|
|
|
When image data exceeds half float ranges values are set to +/-
infinity that could lead to artifacts later on in the pipeline.
Color management for example.
This patch adds a utility function `IMB_gpu_clamp_half_float`
that clamps full float values to fit within the range of
half floats.
This fixes T98575 and T101601.
|
|
This change is part of a wider set of changes to implement Grid and Pixel
snapping in the UV Editor. This particular change adds a new third option,
`pixel grid`, to the previous grid options, `dynamic grid` and `fixed grid`.
Maniphest Tasks : T78391
Differential Revision: https://developer.blender.org/D16197
|
|
|
|
|
|
|
|
|
|
|
|
Use `inline constexpr` instead of `static const` to prevent these
variables from being duplicated in each translation unit that includes
the eevee_camera.hh header (was included into 17 different object files
with MSVC).
Differential Revision: https://developer.blender.org/D16200
|
|
The attribute node already allows accessing attributes associated
with objects and meshes, which allows changing the behavior of the
same material between different objects or instances. The same idea
can be extended to an even more global level of layers and scenes.
Currently view layers provide an option to replace all materials
with a different one. However, since the same material will be applied
to all objects in the layer, varying the behavior between layers while
preserving distinct materials requires duplicating objects.
Providing access to properties of layers and scenes via the attribute
node enables making materials with built-in switches or settings that
can be controlled globally at the view layer level. This is probably
most useful for complex NPR shading and compositing. Like with objects,
the node can also access built-in scene properties, like render resolution
or FOV of the active camera. Lookup is also attempted in World, similar
to how the Object mode checks the Mesh datablock.
In Cycles this mode is implemented by replacing the attribute node with
the attribute value during sync, allowing constant folding to take the
values into account. This means however that materials that use this
feature have to be re-synced upon any changes to scene, world or camera.
The Eevee version uses a new uniform buffer containing a sorted array
mapping name hashes to values, with binary search lookup. The array
is limited to 512 entries, which is effectively limitless even
considering it is shared by all materials in the scene; it is also
just 16KB of memory so no point trying to optimize further.
The buffer has to be rebuilt when new attributes are detected in a
material, so the draw engine keeps a table of recently seen attribute
names to minimize the chance of extra rebuilds mid-draw.
Differential Revision: https://developer.blender.org/D15941
|
|
|
|
|
|
This makes sense now that the struct only contains matrices.
|
|
This is part of the effor to simplify the View struct in order to implement
multiview rendering.
`mouse_pixel` is only use for debug purpose and will be reintroduced later.
`is_inverted` is moved to `draw::View`.
|
|
This is part of the effor to simplify the View struct in order to implement
multiview rendering.
|
|
This is part of the effor to simplify the View struct in order to implement
multiview rendering.
|
|
This is part of the effor to simplify the View struct in order to implement
multiview rendering.
|
|
This is part of the effor to simplify the View struct in order to implement
multiview rendering.
|
|
This is part of the effor to simplify the View struct in order to implement
multiview rendering.
|
|
These were only a normalized copy of the XY axes of the inverse viewmat.
But since the viewmatrix is always normalized we can use it directly.
|
|
This is part of the effor to simplify the View struct in order to implement
multiview rendering.
|
|
This avoid dependency with the draw view.
|
|
No functional change. `view_clipping_distances` is prefered as it is
auto masked.
|
|
This is part of the effor to simplify the View struct in order to implement
multiview rendering.
The viewvecs can easilly be replace by projection matrix operation.
Even if slightly more complex, there is no performance impact.
|
|
This is part of the effor to simplify the View struct in order to implement
multiview rendering.
The CameraTexCoFactors being only valid for a single view, and being only
used in very few places, it make sense to move it to the engine side.
|
|
This is in order to reduce the size of ViewInfos and support multi view
rendering.
|
|
|
|
Dyntopo PBVH draw was miscounting the number of triangles.
|
|
Bug introduced in rB6774cae3f25b.
This causes undefined behavior in `DRW_state_draw_support()` making
overlay depth drawing unpredictable.
|
|
|
|
|
|
|
|
Also remove unnecessary struct keywords in C++ files.
|
|
This also removes the need to compute the persmat and saves some memory
from the `ViewInfos` struct. This is needed to allow multiview support.
Initial testing found no major performance regression during vertex
heavy workload.
Test file: {F13610017}
Results:
| Platform | Master | Split Matrix|
| Linux + Mesa + AMD W6600 | 48 fps | 47 fps |
| Macbook Pro M1 | 50 fps | 51 fps |
| Linux + NVidia 1080Ti | 51 fps | 52 fps |
| Linux + Radeon Vega 64 | 25.6 fps | 26.7 fps |
Increased precision when far from origin:
{F13610024}
{F13610025}
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D16125
|
|
Differential Revision: https://developer.blender.org/D16134
|
|
|
|
Fix for T101438
Clamping the mip seems to always set it to 9.0.
I couldn't find an alternative way to avoid triggering the error (ie. min(mip, 9.0)).
In any case, the results with this patch applied look the same to the (correct) ones on AMD.
And, since clamping the max mip to a hardcoded value could result in resolution-depended behavior, I guess disabling the clamp should be ok anyway.
Reviewed By: fclem
Maniphest Tasks: T101438
Differential Revision: https://developer.blender.org/D16129
|
