Note: I had to add an epsilon on top of the threshould for SIMVERT_NORMAL.
Otherwise I was getting differences such as 0.000000something when comparing
supposed-to-be-identical normals.
The way I see it, the Threshold option is a user feature, where users can
control more or less what they want selected. While the epsilon is a
non-negotiable requirement for our float comparison here.
This includes support for:
* SIMVERT_NORMAL
* SIMVERT_FACE
* SIMVERT_EDGE
Not included and currently not supported/disabled:
* SIMVERT_VGROUP
* SIMEDGE_*
* SIMFACE_*
While we are working on this, we prevent users from using the non-ported modes.
Note: the bmo_similar.c file is still around, to be removed in the near future.
Everyone: Please fell free to jump in and help tackling the missing modes.
For details on the implementation discussion:
https://developer.blender.org/D3674
Also minor changes:
- Remove unused headers.
- rename SimpleExprParseState -> ExprParseState
- rename max_ops -> ops_count_alloc
Was misleading since maximums are often limits which can't be exceeded.
Simple isn't a good prefix for library names since
lots of unrelated modules could be called 'simple'.
Include 'py' in module name since this is a subset of Python,
one of the main motivations for this is to be Python like/compatible.
- Pass in the snap distance
(to avoid comparisons in the multi-object version).
- Loop directly over BMLoop's (without using the iterator).
- Use squared distance instead of manhattan.
The thing is that the quality is something a bit subjective regarding this
option value.
A more precise trace will have more noise so quality is also diminished in
a way. I believe that using "Precision" is more correct than "Quality" in
this case.
Also tested the straighten option and it is working-ish.
That said, I think straighten should take all the meshes vertices to determine
the line you want to use as reference. However we would need a different way to
determine the first and last uvs to use as reference for the line.
The first time setup screen only has the interaction preset currently, some
more work is needed to be able to set e.g. the language or compute device
here as in the mockups.
The splash screen stayed the same for now, to make room for the templates
most of the links are now in the Help menu. If there are no recent files yet
the links still show.
The splash screen buttons implementation was fully moved to Python, in the
WM_MT_splash menu.
These can now be acessed from the File > New, Ctrl+N, or the splash screen.
Since these are application templates, users can save a separate startup.blend
for each. User preferences are shared between these templates though.
This also fixes some issues in the default startup.blend (triangulated cube..).
Differential Revision: https://developer.blender.org/D3690
The goal here is to make app templates usable for default templates
that we can ship with Blender. These only have a custom startup.blend
currently and so are quite limited compared to app templates that fully
customize Blender.
But still it seems like the same kind of concept where we should be
sharing the code and UI. It is useful to be able to save a startup.blend
per template, and I can imagine some scripting being useful in the future
as well.
Changes made:
* File > New and Ctrl+N now list the templates, replacing a separate
Application Templates menu that was not as easy to discover.
* File menu now shows name of active template above Save Startup File
and Load Factory Settings to indicate these are saved/loaded per
template.
* The "Default" template was renamed to "General".
* Workspaces can now be added from any of the template startup.blend
files when clicking the (+) button in the topbar.
* User preferences are now fully shared between app templates, unless
the template includes a custom userpref.blend. I think this will be
useful in general, not all app templates need their own keymaps for
example.
* Previously Save User Preferences would save the current app template
and then Blender would start using that template by default. I've
disabled this, to me it seems it was unintentional, or at least not
clear at all that saving user preferences also makes the current
Differential Revision: https://developer.blender.org/D3690
This makes it so coordinates and normals for CCG are calculated
with mutires displacement taken into account. This solves issues
with multires displacement being lost when entering sculpt mode.
The missing part is averaging of normals along grid boundaries.
But even then sculpting shows decent results.
The plan to solve that would be to introduce function to stitch
grids, which can also be used by Smooth brush which requires
this.
This happens on NVidia GPUs, using more textures than the maximum allowed
by the gl will NOT trigger a linking issue (maybe because of bindless
texture implementation?).
So in this case we manually count the number of samplers per shader stage
and compare it against the GL limit. We discard the shader if the sampler
count is too high. This shows the user something is wrong with the shader.
Recently @sergey found that hard-coding evaluation of certain very
common driver expressions without calling the Python interpreter
produces a 30-40% performance improvement. Since hard-coding is
obviously not suitable for production, I implemented a proper
parser and interpreter for simple arithmetic expressions in C.
The evaluator supports +, -, *, /, (), ==, !=, <, <=, >, >=,
and, or, not, ternary if; driver variables, frame, pi, True, False,
and a subset of standard math functions that seem most useful.
Booleans are represented as numbers, since within the supported
operation set it seems to be impossible to distinguish True/False
from 1.0/0.0. Boolean operations properly implement lazy evaluation
with jumps, and comparisons support chaining like 'a < b < c...'.
Expressions are parsed into a very simple stack machine program
that can then be safely evaluated in multiple threads.
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D3698
This partially solves ASAN report about unfreed memory. There is still
something in the report, need to have a closer look with debug version
of OpenEXE library.
