This is larger topic than what is up for discussion there, and should be discussed by Blender in general, but large number of assets mentioned once again made me worry about versioning. How will we do that?
Let’s say I want to make changes to Grain asset after it’s added, only way now is to just upload entirely new .blend file with it, which contains no information about changes. No way to track them, compare them, or most importantly debug them. How do we handle reviews for them? Do we ask someone like Andy from Blender studio to go check every node one by one and see what is changed? How about changed values in existing nodes?
I’m worried this can lead to lot of orphaned assets inside Blender, or ones without good maintenance that look/act different in newer Blender versions for users, change their work and we can’t really know what caused it.
I would like to see discussion about that, and potential solutions before we move so heavily into built-in assets.
Assets will be node groups, so there are no plans to version them explicitly. As long as we don’t introduce breaking changes for blend files (which we rarely do), assets should continue to load fine, because the nodes underneath will be versioned as usual.
This can happen indeed but is not specific to assets. Any time we change a default value in Blender, starting the same project from scratch would look different in newer version. But loading an old file will behave the same.
We have the same situation for test files, existing assets, icons etc… More importantly, users are not affected at all (quite the opposite, they would get new assets ), so personally I don’t think this is a blocking issue
Perhaps I didn’t explain myself well. I don’t mean changes made to the system of assets, I mean adding stuff or changing to individual assets. This of course assumes asset embedding is in place, and placed node group assets in users projects get updated when changes are made “upstream”, i.e. in original asset files.
A couple of examples:
User wants to contribute to “Camera Shake” asset. They have a better “noise algorithm” that results in more realistic shakes. How do we add it?
Users find that value of some node (that is not exposed as input) is too large and want to change it. When doing that, all of the users who have calibrated their projects to that large value will get different look and will have to dial back.
Someone contributes changes to an asset that does something seemingly unimportant, like use Map Range instead of Color Ramp or something like that. How do we test that nothing is broken?
Do we just keep adding new nodes instead of changing old ones? Do we have tests for asset results?
That’s the opposite of how asset embedding is meant to work. The node group is stored “embedded” in the file. If the source is changed in the asset file, it won’t be deduplicated with the asset currently in the file because it’s changed and the ID hash reflects that.
Ah alright, I had wrong idea about it then, it’s good to know it won’t change existing projects for users (although it will probably introduce some confusions at first), but testing and version history, reviewing contributions are still important topics imo.
There is a blend2json.py script in the Blender repository that could help with blendfile asset review.
In general it would be useful to write a script that can inspect new extensions or compare between two extension versions. It could give an overview of the changes, and flag potential issues. Maybe reviewers from e.g. Superhive would be interested in contributing or using it.
Though this is probably not the right topic to discuss this, I’ll split it off into its own to avoid distracting from the user feedback about compositing.
I was also thinking JSON for node tree that stores all nodes and their values. It doesn’t matter much if it’s too large and not readable in itself, as long as changes can be tracked and compared. Writing script for generating JSON is easy, but I don’t know how that tool can be deployed in the review process.
I’m not sure what your review workflow is exactly, and what would work best.
For an extension submitted on extensions.blender.org, the script could take a URL as an argument, download the files and generate a report. If it’s a change in a git repository, it could take a git revision or a pull request number, and generate a report. Or it could just point to a directory or file.
I’m not sure how readable the blend file json is compared to something custom for nodes, I guess that would have to be checked.
Think we’re talking about different things here. In this case, I’m talking about versioning assets that will be shipped with Blender, not extensions. Basically .blend files in “blender-assets” repo.
That’s why I mentioned comparing git revisions or pull requests. I could imagine running a script locally to review a pull request, that shows me what exactly changed in the blend files. It’s even possible to configure git to convert the blend to json for git diff.
), so personally I don’t think this is a blocking issue