Progress towards 0.1.0
Progress Report, July 4th, 2022
While not yet functional, the edits are super fun to play with.
More details
We can remove these e-frames and add new ones, toggling between Placement and Realtime Preview:
With adding the directional parameter comes the need for adjustable strength and blending strength:
Progress Report, July 5th, 2022
Shader nodes organization, up to 8 edits
I've heavily refactored the shading side of this to be more organized - the front end for the user will now look like this:
In doing so, I've also added the ability for each edit to have an individual blend strength. As this renders the Blend Strength slider pointless, I've removed it. In the future, that slider will be re-implemented and correspond to the active edit.
Added object/UV coordinate switch.
Multi-edit eframe correspondence progress
After trying a few different things today and yesterday (all of them failing), I’ve come up with a new approach to the multiple edit challenge. Rather than storing multiple arrays- one per edit- I’ve decided to keep the system I’m already using which has just one large array for all frames. To distinguish correctly, I’m storing the active edit in an array when an eframe is added. This gives me an system where a[0] = b[0] = c[0] across the three fundamental arrays.
It makes sense to me in my head, I’m not good at explaining technical things, maybe this diagram will help:
The immediate question is what happens when you have something like this (I’ve simplified to a 1D vector instead of 3D for ease of reading):
empty_pos_array = [1,3,4, 2]
light_rot_array = [45,70,90, 60]
eframe_to_edit = [A, B, A, B]
On paper, it’s obvious- edit A should lerp between indices [0] and [2], and edit B should lerp between [1] and [3]. That may prove difficult to implement, however, I plan on avoiding complicated index ordering issues altogether by evaluating each edit discretely. That is to say, the execution of above would go as follows:
- All values that correspond to edit A in both arrays are pulled into a temporary working array.
- Lerping happens, as already implemented, with this array only.
- This array is cleared.
- This is repeated for Edit B.
This should work, at least theoretically. The more I type it out, the more sense it makes, which is the point of this thread anyway.
This is actually working well so far- I can filter out “working arrays” that have the correct values. I’m not doing anything with them yet, but they exist. One downside is that since the g.eframe_to_edit array isn’t being saved, I have to clear all the eframes whenever restarting the file or Blender to prevent array length errors.
Summary: I’ve found a way to make it work and I’m slowly implementing it.
Edits are associated, preview works on a one-by-one basis
Currently, you can set e-frames for a specific edit, and that specific edit will preview only those e-frames. Whichever edit is currently “active” is the one that previews. This isn’t ideal, but it’s huge multi-edit progress. I have 70% of the multi-edit functionality now, I just need to preview all of them at once.
However, this has re-introduced a lack of smoothness I don’t like. I’m assuming it’s a weight issue, so there’s a few things I can try there to troubleshoot.
Progress Report, July 6th, 2022
Fixed the symmetry issue, better blending, and a Mask parameter to allow precise control over the symmetry issue. I’ve also realized the Edits need Damped Track constraints to work properly, which has made a huge difference.
Added individual scale parameter to edits.
Fixed the (extremely annoying) jumping to origin bug. Added re-name functionality for edits. Significantly cleaned up code.
Progress Report, July 7th, 2022
Added a framework for dynamic edit creation. While it currently just consolidates and simplifies things, it opens up a huge realm of possibilities for better edit management.
Edit management will be the focus of release 0.2.0. The first public release will be 1.0.0, and it will be limited to beta testers.
Added warning messages where appropriate.
Added Rotate parameter. Added the Stretch parameter, which can either elongate or compress an edit. This is useful both for large swathes of shadow and extremely fine details- you can, in fact, create inner lines now with this method:
Mask parameter is individual now
