It is disabled by default, so should not affect existing configurations.
Main benefits of this goes as:
- Linux distros can use that to avoid libraries duplication and link
blender package against gflags package from the system.
- It it easier to test whether Blender works with updated version of
Gflags prior to re-bundling the library.
Before now it lived in source/blender/gpu for convenience. Only a few files in the gpu module use Gawain directly.
Tested on Mac, time to push and test on Windows.
Todo: some CMake magic to make it easy to
#include "gawain/some_header.h"
from any C or H file. Main problem here is the many editors that include GPU_immediate.h which includes Gawain's immediate.h -- is there a way to avoid changing every editor's CMakeLists?
Initial work by Clément Foucault with contributions from Dalai Felinto
(mainly per-collection engine settings logic, and depsgraph iterator placeholder).
This makes Blender require OpenGL 3.3. Which means Intel graphic card
and OSX will break. Disable CLAY_ENGINE in CMake in those cases.
This is a prototype render engine intended to help the design of real
render engines. This is mainly an engine with enphasis in matcap and
ambient occlusion.
Implemented Features
--------------------
* Clay Render Engine, following the new API, to be used as reference for
future engines
* A more complete Matcap customization with more options
* Per-Collection render engine settings
* New Ground Truth AO - not enabled
Missing Features
----------------
* Finish object edit mode
- Fix shaders to use new matrix
- Fix artifacts when edge does off screen
- Fix depth issue
- Selection sillhouette
- Mesh wires
- Use mesh normals (for higher quality matcap)
- Non-Mesh objects drawing
- Widget drawing
- Performance issues
* Finish mesh edit mode
- Derived-Mesh-less edit mode API (mesh_rende.c)
* General edit mode
- Per-collection edit mode settings
* General engines
- Per-collection engine settings
(they are their, but they still need to be flushed by depsgraph, and
used by the drawing code)
Design Documents
----------------
* https://wiki.blender.org/index.php/Dev:2.8/Source/Layers
* https://wiki.blender.org/index.php/Dev:2.8/Source/DataDesignRevised
User Commit Log
---------------
* New Layer and Collection system to replace render layers and viewport layers.
* A layer is a set of collections of objects (and their drawing options) required for specific tasks.
* A collection is a set of objects, equivalent of the old layers in Blender. A collection can be shared across multiple layers.
* All Scenes have a master collection that all other collections are children of.
* New collection "context" tab (in Properties Editor)
* New temporary viewport "collections" panel to control per-collection
visibility
Missing User Features
---------------------
* Collection "Filter"
Option to add objects based on their names
* Collection Manager operators
The existing buttons are placeholders
* Collection Manager drawing
The editor main region is empty
* Collection Override
* Per-Collection engine settings
This will come as a separate commit, as part of the clay-engine branch
Dev Commit Log
--------------
* New DNA file (DNA_layer_types.h) with the new structs
We are replacing Base by a new extended Base while keeping it backward
compatible with some legacy settings (i.e., lay, flag_legacy).
Renamed all Base to BaseLegacy to make it clear the areas of code that
still need to be converted
Note: manual changes were required on - deg_builder_nodes.h, rna_object.c, KX_Light.cpp
* Unittesting for main syncronization requirements
- read, write, add/copy/remove objects, copy scene, collection
link/unlinking, context)
* New Editor: Collection Manager
Based on patch by Julian Eisel
This is extracted from the layer-manager branch. With the following changes:
- Renamed references of layer manager to collections manager
- I doesn't include the editors/space_collections/ draw and util files
- The drawing code itself will be implemented separately by Julian
* Base / Object:
A little note about them. Original Blender code would try to keep them
in sync through the code, juggling flags back and forth. This will now
be handled by Depsgraph, keeping Object and Bases more separated
throughout the non-rendering code.
Scene.base is being cleared in doversion, and the old viewport drawing
code was poorly converted to use the new bases while the new viewport
code doesn't get merged and replace the old one.
Python API Changes
------------------
```
- scene.layers
+ # no longer exists
- scene.objects
+ scene.scene_layers.active.objects
- scene.objects.active
+ scene.render_layers.active.objects.active
- bpy.context.scene.objects.link()
+ bpy.context.scene_collection.objects.link()
- bpy_extras.object_utils.object_data_add(context, obdata, operator=None, use_active_layer=True, name=None)
+ bpy_extras.object_utils.object_data_add(context, obdata, operator=None, name=None)
- bpy.context.object.select
+ bpy.context.object.select = True
+ bpy.context.object.select = False
+ bpy.context.object.select_get()
+ bpy.context.object.select_set(action='SELECT')
+ bpy.context.object.select_set(action='DESELECT')
-AddObjectHelper.layers
+ # no longer exists
```
Currently the tests don't run on windows for the following reasons
1) render_graph_finalize has an linking issue due missing a bunch of libraries (not sure why this is not an issue for linux)
2) This one is more interesting, in test/python/cmakelists.txt ${TEST_BLENDER_EXE_BARE} and ${TEST_BLENDER_EXE} are flat out wrong, but for some reason this doesn't matter for most tests, cause ctest will actually go out and look for the executable and fix the path for you *BUT* only for the command, if you use them in any of the parameters it'll happily pass on the wrong path.
3) on linux you can just run a .py file, windows is not as awesome and needs to be told to run it with pyton.
4) had to use the NAME/COMMAND long form of add_test otherwise $<TARGET_FILE:blender> doesn't get expanded, why? beats me.
5) missing idiff.exe for msvc2015/x64 in the libs folder.
This patch addresses 1-4 , but given I have no working Linux build environment, I'm unsure if it'll break anything there
5 has been fixed in rBL61751
Reviewers: juicyfruit, brecht, sergey
Reviewed By: sergey
Subscribers: Blendify
Tags: #cycles, #automated_testing
Differential Revision: https://developer.blender.org/D2367
Seems CMake will rearrange and copy libraries which are passed to the linker
when some of the libraries is listed twice (for example, -lz from png libraries
and -l for blender itself). This was causing libopenimageio to be added somewhere
at the end of linking flags without -ldl followed after which was causing linking
issues.
The option is controlled with the WITH_WINDOWS_CODESIGN option and needs:
- Signtool must be found on the system, the standard windows sdk folders will be searched for it.
- The path to the pfx file (WINDOWS_CODESIGN_PFX)
- The password for the pfx , this can either be set by the WINDOWS_CODESIGN_PFX_PASSWORD variable but given that ends up in CMakeCache.txt (which might be undesirable) there is a backup option of setting the PFXPASSWORD environment variable on the system.
Reviewers: sergey, juicyfruit
Reviewed By: juicyfruit
Tags: #bf_blender, #platform:_windows
Differential Revision: https://developer.blender.org/D2182
All in all, this patch adds an Alembic importer, an Alembic exporter,
and a new CacheFile data block which, for now, wraps around an Alembic
archive. This data block is made available through a new modifier ("Mesh
Sequence Cache") as well as a new constraint ("Transform Cache") to
somewhat properly support respectively geometric and transformation data
streaming from alembic caches.
A more in-depth documentation is to be found on the wiki, as well as a
guide to compile alembic: https://wiki.blender.org/index.php/
User:Kevindietrich/AlembicBasicIo.
Many thanks to everyone involved in this little project, and huge shout
out to "cgstrive" for the thorough testings with Maya, 3ds Max, Houdini
and Realflow as well as @fjuhec, @jensverwiebe and @jasperge for the
custom builds and compile fixes.
Reviewers: sergey, campbellbarton, mont29
Reviewed By: sergey, campbellbarton, mont29
Differential Revision: https://developer.blender.org/D2060
We recently added delay-loading of the openmp dll's so we no longer had to use
the stub loader, we however put these linker flags on the global linker flags
causing any sub projects not using openmp to spit linker warning 4199 while building,
```
Warning LNK4199 /DELAYLOAD:vcomp140.dll ignored; no imports found from vcomp140.dll datatoc k:\BlenderGit\build_windows_2015a\source\blender\datatoc\LINK 1
```
This patch makes the delay-load only apply to the blender project.
Reviewers: sergey
Subscribers: sergey
Tags: #bf_blender
Differential Revision: https://developer.blender.org/D2092
Applying cflags globally can be problematic especially with extern, intern libs.
Now flags from target named will be used when defined,
allowing for developers to define flags for modules they maintain.
Convention is CMAKE_CFLAGS_${UPPERCASE_TARGET_NAME}, (CXXFLAGS for C++).
eg: CMAKE_CFLAGS_BF_BLENDER, CMAKE_CFLAGS_MAKESDNA, CMAKE_CXXFLAGS_CYCLES_KERNEL
On Linux run `make help` for full list of names, MSVC shows these in the solution.
You can capture and stream video in the BGE using the DeckLink video
cards from Black Magic Design. You need a card and Desktop Video software
version 10.4 or above to use these features in the BGE.
Many thanks to Nuno Estanquiero who tested the patch extensively
on a variety of Decklink products, it wouldn't have been possible without
his help.
You can find a brief summary of the decklink features here: https://wiki.blender.org/index.php/Dev:Source/GameEngine/Decklink
The full API details and samples are in the Python API documentation.
bge.texture.VideoDeckLink(format, capture=0):
Use this object to capture a video stream. the format argument describes
the video and pixel formats and the capture argument the card number.
This object can be used as a source for bge.texture.Texture so that the frame
is sent to the GPU, or by itself using the new refresh method to get the video
frame in a buffer.
The frames are usually not in RGB but in YUV format (8bit or 10bit); they
require a shader to extract the RGB components in the GPU. Details and sample
shaders in the documentation.
3D video capture is supported: the frames are double height with left and right
eyes in top-bottom order. The 'eye' uniform (see setUniformEyef) can be used to
sample the 3D frame when the BGE is also in stereo mode. This allows to composite
a 3D video stream with a 3D scene and render it in stereo.
In Windows, and if you have a nVidia Quadro GPU, you can benefit of an additional
performance boost by using 'GPUDirect': a method to send a video frame to the GPU
without going through the OGL driver. The 'pinned memory' OGL extension is also
supported (only on high-end AMD GPU) with the same effect.
bge.texture.DeckLink(cardIdx=0, format=""):
Use this object to send video frame to a DeckLink card. Only the immediate mode
is supported, the scheduled mode is not implemented.
This object is similar to bge.texture.Texture: you need to attach a image source
and call refresh() to compute and send the frame to the card.
This object is best suited for video keying: a video stream (not captured) flows
through the card and the frame you send to the card are displayed above it (the
card does the compositing automatically based on the alpha channel).
At the time of this commit, 3D video keying is supported in the BGE but not in the
DeckLink card due to a color space issue.
Was using O(n^2) lookup on ID's with undo.
This caused undo to hang with 1000's of data-blocks
(especially with heavy scenes & outliner-space, which doesn't even need to be visible to cause a slow-down).
Internally this uses a ghash per id-type, which is lazy-initialized.
Each key uses the name and library since there may be name collisions between libraries.
Developer Notes:
- Adds small `BKE_main_idmap_*` API.
- Needed to change linking order for this to build.
Since version 6 G++ switched to C++11 by default, which breaks some logic
around WITH_CXX11 checks in out CMake files, leading to compilation errors.
This is easy to solve by explicitly enabling older C++ standard when C++11
was not explicitly enabled by CMake options.
However, G++-6 will also use new ABI by default even if older standard was
specified in the compiler options. This is being addressed by a special
define flag.
This tricks made it possible to use new G++-6 without need to recompile
any of pre-compiled libraries.
However, this might break compilation with existing system libraries, which
might already be using new ABI. We can't address this automatically, so
now we simply default WITH_C11 and WITH_CXX11 options to whatever defaults
of the current compiler are. This means, for G++-6 we'll set WITH_CXX11 to
truth. This should make linking with system libraries working just fine,
but to make pre-compiled libraries we still might need to disable CXX11.
This should work fine work for a new environments with G++-6 and install_deps
script run from scratch there, because C++ standard will be the same for
both Blender dependencies and Blender itself.
This mainly touches extern libraries and few debug-only places in intern.
Some summary:
- External libraries are not strict at all about missing declarations,
so we can rather safely remove such warning together with other strict
flags.
- Bullet has some static functions which are not used.
Those were commented out.
- Carve now has some unused debug-only functions commented out as well.
While we're on the way of getting rid of Carve, it makes sense to make
things a bit cleaner for the time being.
- In LZMA we have some parts disabled which gives some set but unused
variables which is rather correct.
- Elbeem had quite some variables set and never used because their usage
is inside of debug-only code which is commented out.
Note about patching upstream libraries: surely one might say that we
have to make local patchset against this, but own experience says it
only gives extra work trying to merge such tweaks to a new upstream
version and usually it's just faster to re-apply such fixes again after
bundling new upstream library.
This will be used for calculating bezier curves from freehand drawing,
may be used for other areas too.
Original code from GraphicsGems, 1990 (FitCurve.c),
with updates from OpenToonz, under 3 clause BSD license.
with own minor modifications for integration with Blender:
- support adding extra custom-data.
- improved handle clamping.
simulations.
This commits implements OpenVDB as an extra cache format in the Point
Cache system for smoke simulations. Compilation with the library is
turned off by default for now, and shall be enabled when the library is
present.
A documentation of its doings is available here: http://
wiki.blender.org/index.php/User:Kevindietrich/OpenVDBSmokeExport.
A guide to compile OpenVDB can be found here (Linux): http://
wiki.blender.org/index.php?title=Dev:Doc/Building_Blender/Linux/
Dependencies_From_Source#OpenVDB
Reviewers: sergey, lukastoenne, brecht, campbellbarton
Reviewed By: brecht, campbellbarton
Subscribers: galenb, Blendify, robocyte, Lapineige, bliblubli,
jtheninja, lukasstockner97, dingto, brecht
Differential Revision: https://developer.blender.org/D1721
The main purpose of such linking is to make Blender compatible with
NVidia's debuggers and profilers which are doing some LD_PRELOAD
magic to intercept some function calls. Such magic conflicts with
our CUDA wrangler magic and causes segmentation faults.
The option is disabled by default, so there's no affect on any of
artists.
In order to make Blender linked directly against CUDA library use
the WITH_CUDA_DYNLOAD CMake option (it's marked as advanced).
The idea is to split them into two separate targets and have dedicated include
directories list for each of them in order to avoid some annoying include header
modifications in comparison with upstream.
Reviewers: campbellbarton, juicyfruit
Differential Revision: https://developer.blender.org/D1706
While SCons building system was serving us really good for ages it's no longer
having much attention by the developers and started to become quite a difficult
task to maintain.
What's even worse -- there started to be quite serious divergence between SCons
and CMake which was only accumulating over the releases now. The fact that none
of the active developers are really using SCons and that our main studio is also
using CMake spotting bugs in the SCons builds became quite a difficult task and
we aren't always spotting them in time.
Meanwhile CMake became really mature building system which is available on every
platform we support and arguably it's also easier and more robust to use.
This commit includes:
- Removal of actual SCons building system
- Removal of SCons git submodule
- Removal of documentation which is stored in the sources and covers SCons
- Tweaks to the buildbot master to stop using SCons submodule
(this change requires deploying to the server)
- Tweaks to the install dependencies script to skip installing or mentioning
SCons building system
- Tweaks to various helper scripts to avoid mention of SCons folders/files
as well
Reviewers: mont29, dingto, dfelinto, lukastoenne, lukasstockner97, brecht, Severin, merwin, aligorith, psy-fi, campbellbarton, juicyfruit
Reviewed By: campbellbarton, juicyfruit
Differential Revision: https://developer.blender.org/D1680
This is so called "seems to work in dry tests" commit which is aimed to switch
linux release environment to CMake.
Some notes:
- There's no special handle of libstdc++, but it wasn't really static for quite
some time in SCons configuration and nobody really complained.
- It was quite tricky to get OpenMP linked statically with just using some
configuration so we went ahead and added a special option to CMake now which is
only exist on Linux and advertised as shouldn't be used.
- Packing is happening manually in slave_pack.py. This is because we have to add
some really special files to the archive (mesa libraries for example) which we
can't really handle from CMake/CPack in a nice generic way.
Don't think it's bad approach, at least crappynness is localized and it's not
_that_ crappy anyway.
- Windows buildbot should keep working, but needs doublechecing. It's just a
build folder changed, but you never know what it might imply.
- Some further tweaks are likely needed to ensure all builders are working.
Thanks Campbell for assistance in this patch!
- Add blentranslation `BLT_*` module.
- moved & split `BLF_translation.h` into (`BLT_translation.h`, `BLT_lang.h`).
- moved `BLF_*_unifont` functions from `blf_translation.c` to new source file `blf_font_i18n.c`.
- rename WITH_EXTERNAL_AUDASPACE to WITH_SYSTEM_AUDASPACE.
- rename C/PYAUDASPACE to AUDASPACE_C/PY
- simplifying cmake defines and includes.
- fixing include paths and enabling WITH_SYSTEM_AUDASPACE for windows.
- fixing scons building.
- other minor build system fixes.
