Another one of those assert crashes when passing values != than 1 and 0
(in this case the value is -1)
Notes from reviewer:
--------------------
These should really be enums. since valid values are KM_ANY,
KM_MOD_FIRST, KM_MOD_SECOND.
But can see at some point this was changed from an enum so... I guess
this is the only way.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D1227
Not much to say, this is pretty straightforward.
We just have to add current locale to thumbnails 'signature', so that
previews get re-generated when we change locale...
Tested with Japanese and French.
Btw, I do not really understand why using BLF in ImBuf is badlevel... :/
BLF_lang_get() shall return 'default' Blender locale (en_US) when translations
are completely disabled!
Also, add BLF_translate() and BLF_translate_do() to allow translating some strings
outside of label/tip context, but still only when i18n global flag is enabled.
(Partial) backport from asset-experiments branch.
Reorganization: previously we could recompute name/path of thumb file two or three times,
now added lower-level internal functions that take those as parameters, so in most case
they are computed only once. Very minor optimization, but simple too.
Also, path of file to preview is now decoupled from path used to generate its URI
(and hence thumbnail path). In asset-experiments branch this is needed because
we also handle datablock previews in/as thumbnails (file_path is .blend path,
URI is .blend path + datablock 'path').
Here this will be needed for same kind of reason - once translated, font thumbnails
need to be re-generated when we change current language...
This commit fixes two different issues actually:
* When view name is unknown/irrelevant, you should pass a NULL str pointer to
`RE_RenderLayerGetPass()`, not an empty string!
* `render_result_rescale()` would unconditionnaly free re->result (at the end),
even if it did not replaced it at all, leading to freed memory access later.
This is only a partial fix though, "CacheBuffer" (i.e. saving tiles in EXR files)
shall not be used in 3DView rendering, and yet it is here...
This was causing glitches when switching from/to fullscreen modes (e.g.,
side by side to anaglyph).
As for the quadbuffer errors this is part of a more complete solution to
be committed later.
That was really crappy indeed. Now we have a separate API
for low level OpenGL programs, plus a nice interface for GPU, also
removes some GL calls from main code as a plus :)
The source for the programs is also moved to nice external .glsl files
(not sure which extension convention GPU assemply uses)
Trying to access rl's from full samples in non-full-OSA context (with uninitialized
sample index even :P ).
Caused by rBd5f1b9c2, probably a copy/paste typo or so.
Issue here is simple and has been fixed in other places such as
texpainting: Basically if face has different winding, do not calculate
it as adjucent to the other face, even if UV is identical.
This allows us to stack islands of symmetrical closed meshes on top of
one another and still be able to select the two identical island halfs
(provided the normals are correct of course).
On windows empty dirs are completely empty - no par or current entries
are listed either, in those cases artificially add those.
Furthermore, stat on UNC paths do not support current/parent 'shortcuts'
(i.e. things like '\\SERVER\foo\bar\..' do not work), so we have to hack
around that mess...
This should ensure us we always do have valid parrent entry...
The issue was introduced in rB4b685e1 and it appears some crazy area still
accesses particles for render after deleting it's render data, which broke
viewport/render behavior.
This commit restores previous G.is_rendering logic and adds corresponding
checks to cache construction, so counting is all consistent.
Goes to the TODO list to either replace G.is_rendering with eval_ctx or to
make it so psys->renderdata always exists during render sync.
The issue was caused by bevel object being automatically added to the scene graph
by dag_get_node() and had no incoming relations, even form the scene. This confused
scene update flush logic.
Now there'll be a scene relation added to such nodes, so they're always reachable
from the root node.
Issue was caused by MSVC not being able to optimize some code out in the same
way as GCC/Clang does, so now that parts of code are explicitly unfolded in
order to help compilers out.
This makes speed loss much less drastic on my laptop. That's probably as good
as we can do with MSVC without investing infinite amount of time looking trying
to workaround the optimizer.
Dalai Felinto
Bastien Montagne
Campbell Barton
Sergey Sharybin
Antonis Ryakiotakis
Tamito Kajiyama