| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
Nearly all byte-color functions use 'uchar'
causing casts when then colors were passed in.
Declare as uchar to remove the need for casts.
|
|
|
|
Previous commit wasn't nearly covering all of them.
|
|
|
|
Changing the global state would obviously cause issues for async
execution. This is the simplest solution for a simple problem.
Reviewers: fclem, brecht
Differential Revision: https://developer.blender.org/D5413
|
|
Avoids expensive context switches.
|
|
|
|
|
|
T68035 by @luzpaz
|
|
|
|
This change ensures that operators which needs access to evaluated data
first makes sure there is a dependency graph.
Other accesses to the dependency graph made it more explicit about
whether they just need a valid dependency graph pointer or whether they
expect the graph to be already evaluated.
This replaces OPTYPE_USE_EVAL_DATA which is now removed.
Some general rules about usage of accessors:
- Drawing is expected to happen from a fully evaluated dependency graph.
There is now a function to access it, which will in the future control
that dependency graph is actually evaluated.
This check is not yet done because there are some things to be taken
care about first: for example, post-update hooks might leave scene in
a state where something is still tagged for update.
- All operators which needs to access evaluated state must use
CTX_data_ensure_evaluated_depsgraph().
This function replaces OPTYPE_USE_EVAL_DATA.
The call is generally to be done in the very beginning of the
operator, prior other logic (unless this is some comprehensive
operator which might or might not need access to an evaluated state).
This call is never to be used from a loop.
If some utility function requires evaluated state of dependency graph
the graph is to be passed as an explicit argument. This way it is
clear that no evaluation happens in a loop or something like this.
- All cases which needs to know dependency graph pointer, but which
doesn't want to actually evaluate it can use old-style function
CTX_data_depsgraph_pointer(), assuming that underlying code will
ensure dependency graph is evaluated prior to accessing it.
- The new functions are replacing OPTYPE_USE_EVAL_DATA, so now it is
explicit and local about where dependency graph is being ensured.
This commit also contains some fixes of wrong usage of evaluation
functions on original objects. Ideally should be split out, but in
reality with all the APIs being renamed is quite tricky.
Fixes T67454: Blender crash on rapid undo and select
Speculation here is that sometimes undo and selection operators are
sometimes handled in the same event loop iteration, which leaves
non-evaluated dependency graph.
Fixes T67973: Crash on Fix Deforms operator
Fixes T67902: Crash when undo a loop cut
Reviewers: brecht
Reviewed By: brecht
Subscribers: lichtwerk
Maniphest Tasks: T67454
Differential Revision: https://developer.blender.org/D5343
|
|
|
|
|
|
Setting the 3D view cursor on startup could crash because the
viewport hasn't been assigned to the region.
|
|
Spawns a separate thread to do any VR session drawing on. There are
four reasons for this:
* VR session doesn't need the usual main loop procedure for drawing.
With the drawing on a separate thread, the session doesn't have the
overhead of the other parts of the main loop.
* OpenXR performs thread blocking operations to synchronize rendering
with the device refresh rate. This would conflict with the rest of
Blender, causing lags on event handling, drawing, etc.
* With an own thread, we can keep a single OpenGL context alive,
avoiding expensive context switches. This should improve performance
significantly.
* With a bit more work, viewports can draw entirely in parallel (at
least the CPU side of it), pushing performance even further.
Drawing the viewport on a separate thread shouldn't be much of an
issue. The draw-manager is already thread safe (mutex guarded). Not much
seems needed to get it entirely concurrent, allowing viewport drawing
from separate threads without any synchronization (i.e. only one at a
time).
I had to create an own depsgraph for the VR draw thread so the viewport
gets its own buffers for its own OpenGL context.
Right now this is utterly broken, but at least an empty viewport is
drawn for the VR session in a separate thread. Issues are:
* VR viewport doesn't draw any objects, just background + overlays
(apparently the VR session depsgraph isn't built correctly).
* OpenGL context of the main thread seems messed up when drawing the VR
view. Result is drawing glitches and eventually Blender crashes.
* Exiting the VR session causes failed assertions and memory leaks.
|
|
This commit moves the API of selecting faces, vertices and edges to a DRW manager engine.
Reviewers: campbellbarton, fclem
Subscribers: jbakker, brecht
Differential Revision: https://developer.blender.org/D5090
|
|
This way we avoid the big overhead of context switches. Makes frames
render about twice as fast here. For heavy Spring scenes I'm getting
around 20 FPS here, classroom scene is at 50 FPS.
This is great given that drawing itself still isn't optimized for dual
eye rendering.
|
|
We want to include this for 2.80
|
|
|
|
Regression from 2.7x caused by 28dfc47cf0b06
|
|
|
|
disabled
|
|
to crash
This was caused by an instancing batch not being initialized correctly.
|
|
|
|
|
|
Follow up for T66747 fix, active color didn't contrast enough.
|
|
|
|
Differential Revision: https://developer.blender.org/D5218
|
|
The check was for the whole object instead of individual particle system.
|
|
|
|
Init the scene of the draw context when selecting. When using face dot selection on
when the subsurf modifier is active on the cage, the scene needs to be
valid. It is read from the context in the
`DRW_mesh_batch_cache_create_requested` and used in the `isDisabled`
method of the SubSurfModifier.
Reviewers: fclem, sergey
Differential Revision: https://developer.blender.org/D5214
|
|
|
|
|
|
Previously in 2.79 we were using a specialized drawing using derivedMesh.
Now the subsurf modifier tag each center vertex as facedot and let the
DRWManager pick it up.
Some modifiers (deforming ones) do not clear the tag so we can use this
technique even if there is deforming modifiers after subsurf modifiers.
|
|
|
|
|
|
Following the advices of @Germano Cavalcante (mano-wii) , I have exposed as a workaround the free function to be called from draw manager for selection.
Now, the free function is not called for selection inside gpencil draw_scene, but it's called from draw_manager.c.
The real fix would be create a new Scene_finish callback in draw manager, but as the release of 2.80 is almost here, we fix this with a workaround that must be removed when new callback is in place.
Differential Revision: http://developer.blender.org/D5193
|
|
|
|
32d3bce1ea27c changed behavior when it shouldn't have.
|
|
Introduced by previous commit
|
|
When doing image rendering with grease pencil, it reused the view of
workbench or EEVEE. These views might be offsetted due to TAA.
This shifted the view a tiny bit. We will not reset the view in between
render engines.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D5171
|
|
|
|
|
|
Finally: This makes it possible to render a viewport to an HMD via
OpenXR. Pure OpenGL rendering will need some more tweaks to work.
To my great delight, performance is quite good for reasonably sized
scenes.
Had to do some hacks and marked some TODOs. Nothing too bad though.
Here are a couple of notes:
* Current initial pose is pretty useless, think it just looks downwards
from world origin. Will change that soon.
* The rendered viewport has some issues: Too dark (bad lighting?), grid
doesn't show up even though I told it to, lighting seems to change with
view position/rotation, etc. Needs some polish.
* Ideally we'd just use the D3D11 Texture given to us via the OpenXR
swapchain and blit the OpenGL framebuffer into that. However the
NV_DX_interop extension fails doing this. Seems like this is a NVidia
Optimus only issue, but I'm missing the hardware to confirm.
So instead, we blit into the D3D11 back buffer first and then into the
Texture.
* The draw-manager uses its own offscreen context so we have to get the
render result from the draw-manager context to the VR session's
context first. Luckily I've already added code to support blitting from
one OpenGL context into another. But it requires blitting twice.
Blitting should be very cheap, but still...
Draw-manager could get a context to use passed instead.
|
|
This can happen if the viewport is not redrawn before calling an operator
(frequent in python scripting).
Related to T64805
|
|
|
