OpenMfxForBlender
OpenMfxForBlender copied to clipboard
eliemichel
Reduce memory allocation
Point input to original blender's buffers rather than copying data in mfxCallback.c for:
- [x] point position
- [x] vertex-point indices
- [x] face counts
Also:
- [ ] Avoid allocating output data when changes can be performed in place (e.g. for deformers, in which case we could leverage on Blender's case for deformers). This is likely to be done through some property of an effect.
- [ ] In plugins, set attributes that are not changing to non owned and point them to the same buffer as input.
5722a23 make use of Blender's internal buffers to read input point positions
PR #23 uses already allocated data for vertex-point and face counts.
New note: In plugins, rather than copying data that does not change, it is already possible to set some attributes to non owned in output mesh, before allocating it, and make it point to the input attribute buffers. copyAttribute actually copies data, but in some cases like identity, we can just reuse the same buffer again.
I going to run performance test to see the improvements and to get a baseline to see if any future changes we make have any unintentional negative effects
I have been running performance tests and I haven't seen any memory improvements. I will continue to investigate.
Can you push the test procedure? Or at least publish results and process, so that it can be cross checked and reproduced later on?
With 3fd879f54b4 and 91c0b2086af it is using 11.6 Gb of memory according to visual studios. The file is too big to upload. Testing procedure. subdivision 6 quality 6 on default code. subdivision 3 quality 3 on default code. duplicate cube 3 times. join all the cubes into one object. add OpenMeshEffect modifier with mirror
b5c3ac75f6c
Did you run more performance tests to see if this actually made a difference
Mmh not really. At this point it'd mean undoing some part of the work to have a version that copies data like the old one used to do.