Age | Commit message (Collapse) | Author |
|
|
|
|
|
as valid).
|
|
|
|
Validate some cases using G_MAIN instead (I don't think we want to work
on any other Main than G.main one when registering/unregistering nodes
etc.).
And when freeing, all ID not in Main shall now be tagged accordingly, so
we *should* not need to do that stupi search over all ntrees in G.main
to check wether we have to free it ourself or not!
|
|
|
|
|
|
Use BLI_path_extension_* prefix.
|
|
crash.
Only fixing crash, proper handling (a.k.a remapping) of all
possible cases here, for all possible data layers, is rather involved...
|
|
This means the shader can now be used for procedural texturing. New
settings on the node are Samples, Inside, Local Only and Distance.
Original patch by Lukas with further changes by Brecht.
Differential Revision: https://developer.blender.org/D3479
|
|
|
|
Without these minor changes loading files from 2.8 will crash.
Manually applied edits from 26786a2b87a08
|
|
For grouped undo we should not skip the undo push, rather replace the
previous undo push. This way undo goes back to the state after the last
operation in the group.
|
|
|
|
Note that due to RNA get/setters issue, that one may actually add some
G.main usages to the total... But at least it's not hidden anymore in a
very low-level, dark corner of BKE pointcache code!
|
|
|
|
|
|
This is supposed to be handled by calling code! Henceforce, no need to
call BKE_sequencer_clear_scene_in_allseqs() here, and... no need for
that ugly G.main case. ;)
|
|
Avoid accidentally operating on the wrong region type.
|
|
This returns the first as a fallback, causing confusing usage.
Renamed and added a version of the function that doesn't.
|
|
|
|
Using G.main only to get main bled filepath, or built-in fonts, is OK.
So now using the 'valid' G_MAIN macro here instead.
|
|
|
|
The easy ones - there some much, much trickier to tackle there...
|
|
|
|
BKE_image was an ugly nest, could fix all but the ones from compositor,
so moved ugly G.main there, at least we know where the Evil is that way ;)
|
|
This commit actually adds some G.main... but at much, much higher level
than the ones it removes, so should still be better ;)
|
|
|
|
It has behavior which we expect, and silences strict compiler warning.
|
|
|
|
|
|
Sometimes one needs a *lot* of changes for a single G.main... :/
|
|
|
|
|
|
Regression in 481cdb08ed6f3
|
|
|
|
This helps making things clearer and cleaner. Func returning filepath of
G.main is separate, so that we can easily track its usages, and
hopefully deprecate it at some point. Though that usage of G.main is
likely the less evil one, you nearly always want current blendfile path
in those cases anyway.
|
|
Relying on evaluation to initialize data causes issues w/ 2.8.
|
|
|
|
|
|
This is really convenient for development. Either for profiling the
generated shaders or to check if the generated code is correct.
It writes the shaders to the temporary blender session folder.
(ported over from blender2.8)
|
|
|
|
Strip unindented comment blocks - mainly headers to avoid conflicts.
|
|
|
|
|
|
|
|
Had to add some G.main to modifiers, but in 2.8 we do not need that
anymore, so it's not that bad! ;)
|
|
|
|
Note that in some cases, this only moves the G.main case to somne other
places - in particular, RNA getters/setters are becoming annoying here...
|
|
This commit contains the minimum to make clang build/work with blender, asan and ninja build support is forthcoming
Things to note:
1) Builds and runs, and is able to pass all tests (except for the freestyle_stroke_material.blend test which was broken at that time for all platforms by the looks of it)
2) It's slightly faster than msvc when using cycles. (time in seconds, on an i7-3370)
victor_cpu
msvc:3099.51
clang:2796.43
pavillon_barcelona_cpu
msvc:1872.05
clang:1827.72
koro_cpu
msvc:1097.58
clang:1006.51
fishy_cat_cpu
msvc:815.37
clang:722.2
classroom_cpu
msvc:1705.39
clang:1575.43
bmw27_cpu
msvc:552.38
clang:561.53
barbershop_interior_cpu
msvc:2134.93
clang:1922.33
3) clang on windows uses a drop in replacement for the Microsoft cl.exe (takes some of the Microsoft parameters, but not all, and takes some of the clang parameters but not all) and uses ms headers + libraries + linker, so you still need visual studio installed and will use our existing vc14 svn libs.
4) X64 only currently, X86 builds but crashes on startup.
5) Tested with llvm/clang 6.0.0
6) Requires visual studio integration, available at https://github.com/LazyDodo/llvm-vs2017-integration
7) The Microsoft compiler spawns a few copies of cl in parallel to get faster build times, clang doesn't, so the build time is 3-4x slower than with msvc.
8) No openmp support yet. Have not looked at this much, the binary distribution of clang doesn't seem to include it on windows.
9) No ASAN support yet, some of the sanitizers can be made to work, but it was decided to leave support out of this commit.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D3304
|