This feature makes it possible to do a viewport render (a.k.a.
playblast) by only rendering those frames on which the selected objects
have a keyframe.
The frames to render are stored in a `BLI_bitmap`, which has a bit for
each frame set to 0 (skip) or 1 (render). An alternative approach would
be to construct a set of all keyframes to render, but that would make
both constructing the list and looking up frames in the list more
complex.
The only thing this feature does is skip OpenGL rendering of a frame. As
a result, 'skipped' frames are still included in the output, but just
use the render result of the last-rendered frame. This is exactly what's
described in T72229.
Differential Revision: https://developer.blender.org/D6443
Reviewed By: zeddb
Design task: T72229
The tooltip was static, so it was the same for viewport-rendering the
current frame and for the entire animation. It is now different for
those two.
The structure of `screen_opengl_render_description()` is such that it
allows for adding a new description for a soon-to-come feature (T72229).
Multisample buffers were used for smooth line drawing. As we now have
an algorithm that doesn't need the multisample buffers we can remove
them.
The user preference for viewport multi_sampling is replaced by single
toggle overlay `use_overlay_smooth_wire`. By default this setting is
enabled as the new drawing is really quick (<1ms) and uses zero hacks.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D6367
When using Render Viewport Animation the meta data
was only stamped when a float buffer was used. In recent changes it was
possible to use a char buffer for the result.
This commit will also support stamping of metadata using a char buffer.
When doing viewport rendering the color management happens on the CPU.
This has overhead in downloading a float texture from the gpu and
performing color management on the CPU.
Based on the scene fileformat bit depth the result will be rendered to
a byte texture where the colormanagement happens on the GPU or a float
texture where the colormanagement happens on the CPU.
This is only done during `Viewport Render Animation` in other
cases a float texture is being used.
Baseline (HD render of wanderer.blend workbench engine no samples) 15.688038 s
After changes: 9.412880s
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D6195
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
When exporting annotations using `bpy.ops.render.opengl` the annotations
where only correct in the first frame. In the second frame the
annotations was shifted by half the resolution.
This change will reset the GPU matrices when the annotations are
rendered.
Was very easy to reproduce by rendering sequencer with sound strip.
Need to use evaluated scene to open movie handle, since that is the only
scene which has proper sound handle with everything else attached to it.
When rendering the Sequencer using viewport rendering the annotations
were not scaled to respect the scene render size. This was because the
matrices were calculated based on the output size and not the actual
rendersize.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D5032
When rendering viewport to an offscreen buffer the buffer was
constructed for non anti aliasing (0 samples). This made the objects
that are drawn by the `object_mode` including `wireframe` draw type
non-anti-aliased.
The offscreen buffers will be constructed based on the user setting for
viewport multisampling (`U.ogl_multisamples`). The same setting will
also be used when previewing scene strips in the sequencer. For now
this only improves wireframe drawing in the scene strips. To improve the
Anti aliasing in the scene strips we need to get finer control in the
draw manager. This will be part of a different patch I am preparing.
Please note that this patch also cleansup some unused code in the offscreen rendering (FSAA code was still existing, but never called)
Reviewed By: brecht
Maniphest Tasks: T64849
Differential Revision: https://developer.blender.org/D4907
- Add `render_aa` and `viewport_aa` sampling setting for workbench. 0
samples means no AA, 1 sample uses FXAA and more samples will use
TAA.
The viewport `gpu_viewport_quality` can still limit viewport anti-aliasing
method.
- Use TAA when rendering images. (this used to be CPU based FSAA)
- Removed `R_OSA` related settings.
Reviewers: fclem, brecht
Maniphest Tasks: T60847
Differential Revision: https://developer.blender.org/D4773
- Merged SEQ_OFSDRAW with V3D_OFSDRAW and define in the
DNA_view3d_types: Due to this FSAA always kicked in making the
rendering slow.
- Removed `Texture Solid` and `DOF`.
- Now when chosing Solid rendering the settings
of the original scene is used.
- Added a global override to use scene specific shading. In the
Future we will need to enhanced this so user can change the
settings.
- Added support for LookDev. LookDev crashed as it needed the
`evil_C` what was not set
- LookDev mode will always show the scene + world lights.
Reviewed By: brecht, fclem
Maniphest Tasks: T62517
Differential Revision: https://developer.blender.org/D4738
Patch by Shinsuke Irie.
* * *
Note from reviewer/committer (dfelinto):
OpenGL render from the VSE preview window is working, while the VSE
preview window itself does not show stereo.
That said the patch is ok, and I was able to test that the VSE preview
OpenGL still works. I will tackle VSE preview itself separately myself.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
That kind of implicit includes should really only be done when totally,
absolutely necessary, and ideally only with rather simple 'second-level'
headers.
Otherwise not being explicit with includes always end up biting in
unexpected ways...
Since we now have an Opengl "render engine", it is misleading to have this
operator still called "OpenGL Render" when all it does is take a snapshot
of the viewport.
This commit merge the full development done in greasepencil-object branch and include mainly the following features.
- New grease pencil object.
- New drawing engine.
- New grease pencil modes Draw/Sculpt/Edit and Weight Paint.
- New brushes for grease pencil.
- New modifiers for grease pencil.
- New shaders FX.
- New material system (replace old palettes and colors).
- Split of annotations (old grease pencil) and new grease pencil object.
- UI adapted to blender 2.8.
You can get more info here:
https://code.blender.org/2017/12/drawing-2d-animation-in-blender-2-8/https://code.blender.org/2018/07/grease-pencil-status-update/
This is the result of nearly two years of development and I want thanks firstly the other members of the grease pencil team: Daniel M. Lara, Matias Mendiola and Joshua Leung for their support, ideas and to keep working in the project all the time, without them this project had been impossible.
Also, I want thanks other Blender developers for their help, advices and to be there always to help me, and specially to Clément Foucault, Dalai Felinto, Pablo Vázquez and Campbell Barton.
This translates the gl calls to the new GPU_ wrappers from D3501.
Given it's tedious and repetitive work, this patch does as much as it can with search + replace, the remainder of the gl calls will need to be manually dealt with on a case by case basis.
This fixes 13 of the 28 failing editors when building without opengl.
For the list of substitutions see D3502
Reviewers: brecht
Differential Revision: https://developer.blender.org/D3502
Both the scene and workspace had an active view layer, and it was confusing
which settings were being used or displayed where. Now we always have one,
so there is no mismatch.
The "View Layers" tab in the properties editor is now "View Layer", no longer
showing a list of layers. Instead view layers can be added and removed with
the workspace view layer selector. They are also listed and selectable in the
outliner.
Single layer rendering uses the active view layer from the workspace.
This fixes bugs where the wrong active view layer was used, but more places
remain that are wrong and are now using the first view layer in the scene.
These are all marked with BKE_view_layer_context_active_PLACEHOLDER.
Brecht authored this commit, but he gave me the honours to actually
do it. Here it goes; Blender Internal. Bye bye, you did great!
* Point density, voxel data, ocean, environment map textures were removed,
as these only worked within BI rendering. Note that the ocean modifier
and the Cycles point density shader node continue to work.
* Dynamic paint using material shading was removed, as this only worked
with BI. If we ever wanted to support this again probably it should go
through the baking API.
* GPU shader export through the Python API was removed. This only worked
for the old BI GLSL shaders, which no longer exists. Doing something
similar for Eevee would be significantly more complicated because it
uses a lot of multiplass rendering and logic outside the shader, it's
probably impractical.
* Collada material import / export code is mostly gone, as it only worked
for BI materials. We need to add Cycles / Eevee material support at some
point.
* The mesh noise operator was removed since it only worked with BI
material texture slots. A displacement modifier can be used instead.
* The delete texture paint slot operator was removed since it only worked
for BI material texture slots. Could be added back with node support.
* Not all legacy viewport features are supported in the new viewport, but
their code was removed. If we need to bring anything back we can look at
older git revisions.
* There is some legacy viewport code that I could not remove yet, and some
that I probably missed.
* Shader node execution code was left mostly intact, even though it is not
used anywhere now. We may eventually use this to replace the texture
nodes with Cycles / Eevee shader nodes.
* The Cycles Bake panel now includes settings for baking multires normal
and displacement maps. The underlying code needs to be merged properly,
and we plan to add back support for multires AO baking and add support
to Cycles baking for features like vertex color, displacement, and other
missing baking features.
* This commit removes DNA and the Python API for BI material, lamp, world
and scene settings. This breaks a lot of addons.
* There is more DNA that can be removed or renamed, where Cycles or Eevee
are reusing some old BI properties but the names are not really correct
anymore.
* Texture slots for materials, lamps and world were removed. They remain
for brushes, particles and freestyle linestyles.
* 'BLENDER_RENDER' remains in the COMPAT_ENGINES of UI panels. Cycles and
other renderers use this to find all panels to show, minus a few panels
that they have their own replacement for.
ViewRender was removed, which means we can't get the render engine for files
saved in 2.8. We assume that any files saved in 2.8 were intended to use Eevee
and set the engine to that.
A fix included with this is that .blend thumbails now draw with Clay mode,
and never Eevee or Cycles. These were drawn with solid mode in 2.7, and should
be very fast and not e.g. load heavy image textures.
Differential Revision: https://developer.blender.org/D3156
The depsgraph was always created within a fixed evaluation context. Passing
both risks the depsgraph and evaluation context not matching, and it
complicates the Python API where we'd have to expose both which is not so
easy to understand.
This also removes the global evaluation context in main, which assumed there
to be a single active scene and view layer.
Differential Revision: https://developer.blender.org/D3152
This was only used for viewport rendering, where we can just pass the engine
type directly. There is no technical reason why we can't draw the same depsgrpah
with different render engines.
It also led to some weird things like requiring a render engine for snapping
and raycast API functions.
Differential Revision: https://developer.blender.org/D3145
This module has no use now with the new DrawManager and DrawEngines and it
is using deprecated paths.
Moving gpu_shader_fullscreen_vert.glsl
to draw/modes/shaders/common_fullscreen_vert.glsl
This separate context allows two things:
- It allows viewports in multi-windows configuration.
- F12 render can use this context in a separate thread and do a non-blocking render.
The downside is that the context cannot be used while rendering so a request to refresh a viewport will lock the UI. This is something that will be adressed in the future.
Under the hood what does that mean:
- Not adding more mess with VAOs management in gawain.
- Doing depth only draw for operators / selection needs to be done in an offscreen buffer.
- The 3D cursor "autodis" operator is still reading the backbuffer so we need to copy the result to it.
- All FBOs needed by the drawmanager must to be created/destroyed with its context active.
- We cannot use batches created for UI in the DRW context and vice-versa. There is a clear separation of resources that enables the use of safe multi-threading.
