Update 3D meshes when painting #1
Comments
Addresses #1 TODO: - clear mesh caches for modified blocks - (de-)serialize modified blocks - trigger re-rendering of all affected meshes when solution is propagated to level
addresses first bullet point in #1
Addresses serialization bullet point of #1
|
The remaining points (automatically clear and trigger) are not crucial and might not even be desired. We should at least think about considering this complete. |
|
For now, do not automatically refresh (affected) meshes. I will make a PR once all other itmes are addressed. If it becomes desirable at some point to have this behavior (maybe have a switch to enable/disable), re-open this issue. This should probably not happen before we have imglib2-caches with |
|
The same holds true for the second bullet point
This is too drastic and only the affected blocks (and potentially their neighbors) should be cleared. Again, this is only possible once All other bullet points are checked and I will create a PR (but not merge immediately). |
…lution An assumption was made that there is always at least one VISIBLE block in a subtree of the REMOVED node. However, this assumption was too strong and it's not always true: for example, consider the following block tree: REMOVED #1 -> REMOVED #2 -> VISIBLE #3. For example, in the next scene update the VISIBLE block #3 goes outside the screen so it's excluded from the requested tree, while it's neighboring block #4 with the same parent node #2 that was outside the screen is now inside, so it's added as a new leaf node in the PENDING state. The updated block tree becomes: REMOVED #1 -> REMOVED #2 -> PENDING #4. Then in the next scene update the resolution needs to decrease, so that the root block #1 now becomes the leaf of the requested tree, and its state is set to PENDING. The algorithm needs to keep all VISIBLE leaf nodes and its ancestors in the subtree of this block #1, and it mistakenly keeps the block #2 under the incorrect assumption mentioned above (assuming that there is a VISIBLE block somewhere below in the subtree), while there is only the PENDING block #4. Then the PENDING block #4 is excluded from the new configuration because it's not needed anymore, and the REMOVED block #2 ends up being the leaf node which is an inconsistent state. With this fix, the block #2 will be excluded from the updated block tree configuration as well because there are no VISIBLE blocks in its subtree, and all the resulting states will be valid.
Currently, painting does not update 3D meshes. This is a continuation of and the last remaining open task in saalfeldlab/bigcat#22
Update:
Finally, I was able to address this issue starting with 413638e on update-meshes-on-paint. Remaining tasks:
automatically clear mesh caches for modified blocksautomatically trigger re-rendering of all affected meshes when solution is propagated to level of meshThe text was updated successfully, but these errors were encountered: