Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
|
|
Like seriously guys... twice within a few hours, compile full blender please
when you change APIs!
|
|
|
|
|
|
This moves background images out of the 3D viewport,
to be used only as camera reference images.
For 3D viewport references,
background images can be used, see: D2827
Some work is still needed
(background option isn't working at the moment).
|
|
|
|
Practically all access to enum data is read-only.
|
|
Engine is not stored in WorkSpaces. That defines the "context" engine, which
is used for the entire UI.
The engine used for the poll of nodes (add node menu, new nodes when "Use Nodes")
is obtained from context.
Introduce a ViewRender struct for viewport settings that are defined for
workspaces and scene. This struct will be populated with the hand-picked
settings that can be defined per workspace as per the 2.8 design.
* use_scene_settings
* properties editor: workshop + organize context path
Use Scene Settings
==================
For viewport drawing, Workspaces have an option to use the Scene render
settings (F12) instead of the viewport settings.
This way users can quickly preview the final render settings, engine and
View Layer. This will affect all the editors in that workspace, and it will be
clearly indicated in the top-bar.
Properties Editor: Add Workspace and organize context path
==========================================================
We now have the properties of:
Scene, Scene > Layer, Scene > World, Workspace
[Scene | Workspace] > Render Layer > Object
[Scene | Workspace] > Render Layer > Object > Data
(...)
Reviewers: Campbell Barton, Julian Eisel
Differential Revision: https://developer.blender.org/D2842
|
|
|
|
|
|
|
|
the same name
The issue was caused by render result identifier only consist of scene name,
which could indeed cause conflicts.
On the one hand, there are quite some areas in Blender where we need identifier
to be unique to properly address things. Usually this is required for sub-data
of IDs, like bones. On another hand, it's not that hard to support this
particular case and avoid possible frustration.
The idea is, we add library name to render identifier for linked scenes. We use
library name and not pointer so we preserve render results through undo stack.
Reviewers: campbellbarton, mont29, brecht
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D2836
|
|
|
|
A single manipulator could only assign a single operator to each part.
Now each part can have it's own.
Also modify 2D selection callback, 2D started at 1, 3D at 0.
Now use -1 for unset value, start both at 0.
|
|
|
|
|
|
|
|
- WM_manipulatorgrouptype_remove- > free
- WM_manipulator_group -> WM_manipulator_group_type
Naming here is still a bit confusing,
now at least free/remove are differentiated.
|
|
|
|
2.8x branch added bContext arg in many places,
pass eval-context instead since its not simple to reason about what
what nested functions do when they can access and change almost anything.
Also use const to prevent unexpected modifications.
This fixes crash loading files with shadows,
since off-screen buffers use a NULL context for rendering.
|
|
|
|
|
|
In some cases users may want to disable this option
to avoid changing other properties besides vertex locations.
|
|
Split up manipulator free & unlink, so freeing window data doesn't
run callbacks that might use freed data.
|
|
They weren't used anywhere,
both C & Py manipulators better assign to vars (no lookup needed).
|
|
|
|
|
|
Note that some little parts of code have been dissabled because eval_ctx
was not available there. This should be resolved once DerivedMesh is
replaced.
|
|
|
|
# Conflicts:
# source/blender/editors/transform/transform_snap_object.c
|
|
The only similarity between these functions is that both serve to snap.
However their codes are totally different from one another.
So by separating these functions, it:
- removes the need to put several conditions;
- simplifies and
- optimizes the code
|
|
|
|
Initial support for Python/Manipulator integration
from 'custom-manipulators' branch.
Supports:
- Registering custom manipulators & manipulator-groups.
- Modifying RNA properties, custom values via get/set callbacks,
or invoking an operator.
- Drawing shape presets for Python defined manipulators (arrow, circle, face-maps)
Limitations:
- Only float properties supported.
- Drawing only supported via shape presets.
(we'll likely want a way to define custom geometry or draw directly).
- When to refresh, recalculate manipulators will likely need
integration with notifier system.
Development will be continued in the 2.8 branch
|
|
|
|
@campbell Barton: Why is this declaration needed at all in stubs.c?
Further up the file collada.h is imported and that already decalres
the function and results in a duplicate declaration.
|
|
|
|
|
|
While this is work-in-progress from custom-manipulators branch
its stable so adding into 2.8 so we don't get too much out of sync.
- ManipulatorGroupType's are moved out of the manipulator-map and are now
global (like operators, panels etc) and added into spaces as needed.
Without this all operators that might ever use a manipulator in the 3D
view would be polling the viewport.
- Add optional get/set callbacks for non-RNA properties
Needed so re-usable manipulators can control values that
don't correspond to a single properly or need conversion.
- Fix divide by zero bug in arrow manipulator (when moving zero pixels).
|
|
|
|
Sync with custom-manipulators branch
- Use identifiers for properties.
- Property array index access.
- Remove operator from manipulators
(wasn't used and will likely add in a different way).
|
|
Also fixes some failing unit-tests for render-layers.
|
|
|
|
|
|
|
|
|
|
* Static strings aren't needed anymore, use stack memory.
* Fix obscure leak on failed macro registration.
* Use prefix for wrappers exported from bpy module.
|