| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Played with a more complex and more efficient version, but that made
things pretty complicated. Now this is a simple, but less optimized, solution.
|
|
|
|
|
|
|
|
|
|
This adds an initial (and already working), generic API for defining, handling and drawing of table UIs.
It supports two types of tables:
* Vertical flow: Rows are all in a vertical stack.
* Horizontal flow: Rows are stacked vertically, until some threshold height is reached. The table is then split into another vertical stack that is drawn next to the former one. Such drawing could be used for the file browser in non-thumbnail mode.
A table is built out of - guess what - rows and columns. The API allows defining new collumns (identified by an id-name) and inserting new rows at any point. When drawing, we draw a cell for each column/row combination, using a custom cell-drawing callback.
The uiTable API will probably get some support for drawing buttons (uiBut) into custom layouts (uiLayout).
The API is written with big data sets in mind. In future we may get a spreadsheet view where data like all vertices of a mesh is displayed. That would result in thousands of rows, the uiTable API should be ready for this.
|
|
This includes a few fixes in the MBC_ api.
The idea here is for this to be the only interface the render engines
will deal with for the meshes.
If we need to expose special options for sculpting engine we refactor
this accordingly. But for now we are shaping this in a per-case base.
Note:
* We still need to hook up to the depsgraph to force clear/update of
batch_cache when mesh changes
(I'm waiting for Sergey Sharybin's depsgraph update for this though)
* Also ideally we could/should use BMesh directly instead of
DerivedMesh, but this will do for now.
Note 2:
In the end I renamed the `BKE_mesh_render` functions to `static
mesh_render`. We can re-expose them as BKE_* later once we need it.
Reviewers: merwin
Subscribers: fclem
Differential Revision: https://developer.blender.org/D2476
|
|
|
|
|
|
features are not found
|
|
Now we have no remaining WITH_LEGACY_DEPSGRAPH in the code.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Required to have some crash fixes.
|
|
When a palette was renamed, the animation data was not changed.
This fix is related to commit 196520fe7d81
|
|
|
|
(docs.blender.org).
|
|
|
|
|
|
We started to run out of bits there, so now we separate flags
which came from __object_flags and which are either runtime or
coming from __shader_flags.
Rule now is: SD_OBJECT_* flags are to be tested against new
object_flags field of ShaderData, all the rest flags are to
be tested against flags field of ShaderData.
There should be no user-visible changes, and time difference
should be minimal. In fact, from tests here can only see hardly
measurable difference and sometimes the new code is somewhat
faster (all within a noise floor, so hard to tell for sure).
Reviewers: brecht, dingto, juicyfruit, lukasstockner97, maiself
Differential Revision: https://developer.blender.org/D2428
|
|
|
|
|
|
Similar thing to other areas where we mix Blender's char with OpenGL API.
|
|
No user visible changes, it was a typo in the name of the class.
Spotted by povmaniac in IRC, thanks!
|
|
|
|
Conflicts:
source/blender/editors/space_action/action_draw.c
|
|
Cycles add-on did not actually support reloading correctly.
When you want to correctly reload sub-modules (i.e. modules of an add-on
which is a package), you need to use importlib, a mere import will do
nothing with already loaded modules (RNA classes are sort of
pre-registered when they are evaluated, through the meta-class system).
|
|
stepsize = 0
A big thanks to Steffen Mortensen (stifan) for finding the root cause of this bug!
|
|
|
|
Reported by coverity scan.
|
|
Reported by coverity scan.
|
|
been correctly allocated.
Reported by coverity scan.
|
|
|
|
|
|
|
|
|
|
|
|
in BLI_string_utils.
|
|
New options to define the style of the animation paths in order to get
better visibility in complex scenes.
Now is possible define the color, thickness and several options relative
to the style of the lines used to draw motion path.
|
|
This way we can stop traversing BVH node early on.
Gives about 2-2.5x times render time improvement with 3 BVH steps.
Hopefully this gives no measurable performance loss for scenes with
single BVH step.
Traversal is currently only implemented for QBVH, meaning old CPUs
and GPU do not benefit from this change.
|
|
Similar to the previous commit, the statistics goes as:
BVH Steps Render time (sec) Memory usage (MB)
0 46 260
1 27 373
2 18 598
3 15 826
Scene used for the tests is the agent's body from one of the barber
shop scenes (no textures or anything, just a diffuse material).
Once again this is limited to regular (non-spatial split) BVH,
Support of spatial split to this feature will come later.
|
|
The idea is to create several smaller BVH nodes for each of the motion
curve primitives. This acts as a forced spatial split for the single
primitive.
This gives up render time speedup of motion blurred hair in the cost
of extra memory usage. The numbers goes as:
BVH Steps Render time (sec) Memory usage (MB)
0 258 191
1 123 278
2 69 453
3 43 627
Scene used for the tests is the agent's hair from one of the barber
shop scenes.
Currently it's only limited to scenes without spatial split enabled,
since the spatial split builder requires some changes to work properly
with motion steps coordinates.
|
