Hydra is a rendering architecture part of USD, designed to abstract the
host application from the renderer. A renderer implementing a Hydra
render delegate can run in any host application supporting Hydra, which
now includes Blender.
For external renderers this means less code to be written, and improved
performance due to a using a C++ API instead of a Python API.
Add-ons need to subclass bpy.types.HydraRenderEngine. See the example in
the Python API docs for details.
An add-on for Hydra Storm will be included as well. This is USD's
rasterizing renderer, used in other applications like usdview. For users
it can provide a preview of USD file export, and for developers it
serves a reference.
There are still limitations and missing features, especially around
materials. The remaining to do items are tracked in #110765.
This feature was contributed by AMD.
Ref #110765
Co-authored-by: Georgiy Markelov <georgiy.m.markelov@gmail.com>
Co-authored-by: Vasyl-Pidhirskyi <vpidhirskyi@gmail.com>
Co-authored-by: Brian Savery <brian.savery@gmail.com>
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/104712
Recently a user expressed interest in exporting baked animation
with B-Bone segments. Currently the python API already exposes
segment matrices via a PoseBone method, but there is no access
to the mapping of vertices to the segments.
Although currently the math is simple and easy to re-implement,
forcing Python add-ons to do that would cause a maintenance issue
if the mapping is ever changed later (it's quite dumb, ignoring
the rest pose curve, and there definitely is room for improvement).
This patch extracts the relevant math into a BKE function, and
exposes it in the python API as a new PoseBone method.
Pull Request: https://projects.blender.org/blender/blender/pulls/105419
A continuation of the previous change. It was not enough to
simply point the script to the new file, the actual parsing
needed to be updated as well.
This is a minimalistic change which converts the file to the
old C-style format, just to restore the working state of the
CI/CD.
It is a bit fragile, and surely a more future-proof solution
is possible to work on.
Pull Request: https://projects.blender.org/blender/blender/pulls/110536
The file bmesh_opdefines.c was recently converted to bmesh_opdefines.cc,
but the manual builder was not updated accordingly.
Also, update some comments in the code which were still mentioning the C
version of this file.
Pull Request: https://projects.blender.org/blender/blender/pulls/110532
The #109197 introduced the following error to the documentation
builders:
Error: context key 'grease_pencil' not found in context_type_map; update ../doc/python_api/sphinx_doc_gen.py
To reproduce the issue locally the following command could be
used:
```
./bin/Blender.app/Contents/MacOS/Blender \
--background \
--factory-startup \
-noaudio \
--python ../../blender/doc/python_api/sphinx_doc_gen.py -- \
--output ./sphinx/build_doc_api \
--api-changelog-generate \
--api-dump-index-path \
./sphinx/api_dump_index.json
```
Note that even after this fix the command from above would still
fail locally because the script expect information from previous
Blender version to be in the index. It is possible to bypass by
manually editing api_dump_index.json and adding 3.6 key.
Pull Request: https://projects.blender.org/blender/blender/pulls/109365
With the move to Gitea the URI for line numbers changed from `$1234` to `#L1234`.
The change also removes a superfluous space character from the generated RST syntax.
This commit implements described in the #104573.
The goal is to fix the confusion of the submodule hashes change, which are not
ideal for any of the supported git-module configuration (they are either always
visible causing confusion, or silently staged and committed, also causing
confusion).
This commit replaces submodules with a checkout of addons and addons_contrib,
covered by the .gitignore, and locale and developer tools are moved to the
main repository.
This also changes the paths:
- /release/scripts are moved to the /scripts
- /source/tools are moved to the /tools
- /release/datafiles/locale is moved to /locale
This is done to avoid conflicts when using bisect, and also allow buildbot to
automatically "recover" wgen building older or newer branches/patches.
Running `make update` will initialize the local checkout to the changed
repository configuration.
Another aspect of the change is that the make update will support Github style
of remote organization (origin remote pointing to thy fork, upstream remote
pointing to the upstream blender/blender.git).
Pull Request #104755
This reverts commit 19222627c6.
Something went wrong here, seems like this commit merged the main branch
into the release branch, which should never be done.
This reverts commit 68181c2560.
I merged 3.6 into 3.5 by mistake. Basically I had a PR against main,
then changed it in the last minute to be against 3.5 via the
web-interface unaware that I shouldn't do it without updating the
patch.
Original Pull Request: #104889
Note that the node group has its sockets names
translated, while the built-in nodes don't.
So we need to use data_ for the built-in nodes names,
and the sockets of the created node groups.
Pull Request #104889
- Correct broken link for undocumented modules.
Point to the contributing page, it seems #51062 was lost with the
GITEA task migration.
- Correct Blender Version link to the SHA1.
The bpy.types page was unreasonably long (over 17k lines).
Resolve by setting the `maxdepth` for this and the `bpy.ops` page too.
This problem showed up in v3.4 release and may be caused by changes
to Sphinx's default behavior as there doesn't seem to be any change
that would cause this in the generated docs.
An apostrophe should not be used because it is not a mark of plural,
even for initialisms. This involves mostly comments, but a few UI
messages are affected as well.
Differential Revision: https://developer.blender.org/D16749
The effect of CANCELLED on the undo stack is quite obscure, and
mistakenly using it after doing some changes causes confusing
behavior. It's better to describe it explicitly in the docs.
This diff improves the docs for bmesh by adding the default values to all methods. This is motivated by this issue https://github.com/nutti/fake-bpy-module/issues/118 in fake-bpy-module which generates a typed API for authoring Blender scripts and addons from the docs.
After this diff gets merged, the Blender docs get updated, and `fake-bpy-module` gets regenerated, the type signatures in `fake-bpy-module` will match the reality of Blender's API.
Here's a diff for the docs using the modified script:
https://gist.github.com/xixixao/1c83153adbcefbe0859f9cc9ba757d46
I "hardcoded" the defaults based on the types of the arguments, after some testing and consulting the Blender .c source for these APIs.
Here's a test script that verifies that the arguments with defaults added in this diff are indeed not required by Blender 3.3: https://gist.github.com/xixixao/adc4e5a076e80a63735bd60c7c9e7a0d
I made the minimum changes required to get this doc generation script fixed, but let me know if I should restructure this script more.
I also amended the comments of three args, 2 to align them with Python (NULL -> None) and one to mark it as optional (CurveProfile).
Reviewed By: Blendify
Differential Revision: https://developer.blender.org/D16400
When accessing certain structure fields from Python, they return
mathutils types instead of generic arrays (this is based on subtype).
This exposes this information in the Python API documentation.
Differential Revision: https://developer.blender.org/D16626
This commit reduces the amount of white space generated and keeps parameter documentation of a single line.
This makes the resulting rst files easier to read in the case of debugging.
This was useful while looking into T97464