| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This is a big change that cleanup a lot of confusing code.
- The instancing/batching data buffer distribution in draw_instance_data.c.
- The selection & drawing code in draw_manager_exec.c
- Prety much every non-meshes object drawing (object_mode.c).
Most of the changes are just renaming but there still a chance a typo might
have sneek through.
The Batching/Instancing Shading groups are replace by DRWCallBuffers. This
is cleaner and conceptually more in line with what a DRWShadingGroup should
be.
There is still some little confusion in draw_common.c where some function
takes shgroup as input and some don't.
|
|
GPU_vertbuf_discard to clear buffer containers in place.
GPU_BATCH_UNUSED to tag batch that are cleared and not immediatly usable.
|
|
- Use int instead of uint for safety and less conversions.
- Add free callback
- Add cleared alloc option
|
|
This simplify the rendering logic.
|
|
|
|
|
|
This is in order to have VAO handled by thoses batches instead of using a
common VAO. Even if the VAO has no importance in these case using a batch
will help when transitioning to Vulkan.
|
|
|
|
|
|
Goal is still to simplify the draw manager.
|
|
|
|
|
|
This removes the need to pass the Material* all over the place in the draw
manager. Cleanup comming right after.
|
|
|
|
|
|
|
|
|
|
Since the view menu is redundant for people with a numpad,
add a preference for it to switch between gizmos instead.
|
|
It's common to load factory settings as a test without wanting to
overwrite your own settings on exit.
|
|
|
|
|
|
Tagging dirty was failing for UI scale, line width, hinting & others.
Checking for an update function means all update functions
need to tag preferences as dirty.
Since this check was added to prevent the active section marking the
preferences as dirty, only exclude this property.
|
|
|
|
|
|
|
|
|
|
|
|
Simplify code now that Cycles also has energy outside nodes.
|
|
The files operator property should not be remembered for next
operator executions, gives unexpected effects when using the
operator again.
|
|
|
|
This is necessary to correctly do low-level keyframe manipulation
in tweak mode, and the logic is complex enough that re-implementing
it in Python is impractical.
|
|
since own rB5d9d32fd1fa3 (mirror bbone scaling in editmode)
- bbone scaling in posemode was missing immediate updates
- bbone scaling in posemode could crash
This now properly supports mirroring in posemode as well.
note: for bbone scaling, I made both X-Axis-Mirror options (editmode
option as well as posemode option) valid.
Fixes T64091
Reviewers: brecht
Maniphest Tasks: T64091
Differential Revision: https://developer.blender.org/D4851
|
|
The most difficult part is handling parent-child relations correctly:
when a parent is applied, the children should be moved accordingly,
and when applying a child, it should not include transformation from
unapplied parents. All this requires walking bones as a tree, instead
of a flat list.
Limitation: Applying bones with non-uniform scaling without also applying
children will distort non-rest posing on said children for reasons related
to T54159 (basically, non-uniform scale plus rotation creates shear, and
Blender matrix decomposition utilities don't have tools to deal with it).
Reviewers: campbellbarton, brecht, mont29
Differential Revision: https://developer.blender.org/D3775
|
|
Give WM context to the shortcut, since this is more specific meaning
than usual 'shifting' one...
Part of T43295.
|
|
Part of T43295.
|
|
This one is usually a verb/action one in menus' labels,
hence we give it the Operator default context.
Part of T43295.
|
|
Not sure why driver would be affecting on the behavior, the actual
issue was caused by lack of proper relations built for lamps and
cameras.
|
|
Was missing copy-on-write tag since lamp itself has no geometry or
transform.
Now tagging for animation, and taking care of special case in the
dependency graph.
|
|
This makes it easier to set up materials with emission and transparency.
Importers/exporters and add-ons are recommended to now use these rather than
creating separate transparent BSDF and emission nodes.
|
|
Cycles lights now use strength and color properties of the light outside
of the shading nodes, just like Eevee. The shading nodes then act as a
multiplier on this, and become optional unless textures, fallof or other
effects are desired.
Backwards compatibility is not exact, as we can't be sure which renderer
the .blend was designed for or even if it was designed for a single one.
If the render engine in the active scene is set to Cycles, lights are
converted to ensure overall light strength remains the same, and removing
unnecessary shader node setups that only included a single emission node.
If the engine is set to Eevee, we increase strength to remove the automatic
100x multiplier that was there to match Cycles.
Differential Revision: https://developer.blender.org/D4588
|
|
Cycles now uses the color space on the image datablock, and uses OpenColorIO
to convert to scene linear as needed. Byte images do not take extra memory,
they are compressed in scene linear + sRGB transfer function which in common
cases is a no-op.
Eevee and workbench were changed to work similar. Float images are stored as
scene linear. Byte images are compressed as scene linear + sRGB and stored in
a GL_SRGB8_ALPHA8 texture. From the GLSL shader side this means they are read
as scene linear, simplifying the code and taking advantage of hardware support.
Further, OpenGL image textures are now all stored with premultiplied alpha.
Eevee texture sampling looks a little different now because interpolation
happens premultiplied and in scene linear space.
Overlays and grease pencil work in sRGB space so those now have an extra
conversion to sRGB after reading from image textures. This is not particularly
elegant but as long as engines use different conventions, one or the other
needs to do conversion.
This change breaks compatibility for cases where multiple image texture nodes
were using the same image with different color space node settings. However it
gives more predictable behavior for baking and texture painting if save, load
and image editing operations have a single color space to handle.
Differential Revision: https://developer.blender.org/D4807
|
|
|
|
Fixes issue with Eevee always using viewport curve resolution.
|
|
Curve function had two arguments:
- for_render, which was originally supposed to be used to control
whether viewport or render visibility for modifiers is to be
used.
- use_render_resolution, which sounds like it is supposed to control
whether viewport or render resolution for curves is to be used.
What is totally confusing is that those arguments were used
interchangeably: sometimes use_render_resolution would control
modifiers visibility.
This commit makes it so there is one single argument for this.
Reviewers: brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D4850
|
|
|
|
|
|
|
|
Broken in rB0ac3d5f7db67 last year...
|
|
|
