@Moult thanks !
It is a complete re-factory from scratch focusing on workflow and fix known weakness.
Basically there is no more fixed workflow as you may alter anything while running, like alter pivot point and adaptive snap grid at any time, create virtual editable snap helpers (points lines and planes), change screen display modes and view direction / zoom.
It also was made to be extendable and archipack takes advantage of it when present as replacement for blender's native snap hack.
As long as you can read and are willing to (..) it may provide tool tips on screen to guide user at any transform operation step - and is "internationalization ready".
On code side :
I do rely on "separation of concern" paradigm for classes whenever possible, and stateless operations for everything but operators.
There are only 3 shaders (display, snap and images) working both in 2d and 3d space, by altering the view transformation matrix according, so most entity batches are in normalized coordinate [0-1] and static (the only dynamic one is rotation widget arcs).
Raster detect engine suffer from huge blow from blender 3.3+ as the new GPU module doesn't provide any other access to screen data but pixels anymore. So had to encode "primitive_id" in pixel colors rather than retrieving from gpu, and store entity data on python side (..). Snap buffer is now re-used so it is way more memory friendly.
Raycast detect engine now rely on object ray cast instead of scene ray cast for performance reasons (~20x faster on huge scenes), with a pretty cool side effect : i was able to provide support for snap to collection instances.
Both detect engines now are way more "lazy", starting by computing bounding rectangle for snap able entity, so only entity below mouse are taken into account when it does perform snap.
Grid engine now is "unit system" aware, providing a 12 sub steps when you are between feet and inches.
Transform engine now rely on gpu "previews" so blender's entity are transformed only once when you confirm and you are able to see result while transforming - and snap to source object. It does support a "pinhole" transformation model (beside move / rotate / scale) allowing to align x axis keeping y axis horizontal, and internally stacked transformations. It is flexible enough to be able to perform sub entity transformations (individual vertices) for projections. Scale operations now occurs in edit mode so base object rotation matrix will not anymore suffer from precision issues.
Comments
Amazing work by @stephen_l ! I had no idea how much work was being done in the background!
@Moult thanks !
It is a complete re-factory from scratch focusing on workflow and fix known weakness.
Basically there is no more fixed workflow as you may alter anything while running, like alter pivot point and adaptive snap grid at any time, create virtual editable snap helpers (points lines and planes), change screen display modes and view direction / zoom.
It also was made to be extendable and archipack takes advantage of it when present as replacement for blender's native snap hack.
As long as you can read and are willing to (..) it may provide tool tips on screen to guide user at any transform operation step - and is "internationalization ready".
On code side :
I do rely on "separation of concern" paradigm for classes whenever possible, and stateless operations for everything but operators.
There are only 3 shaders (display, snap and images) working both in 2d and 3d space, by altering the view transformation matrix according, so most entity batches are in normalized coordinate [0-1] and static (the only dynamic one is rotation widget arcs).
Raster detect engine suffer from huge blow from blender 3.3+ as the new GPU module doesn't provide any other access to screen data but pixels anymore. So had to encode "primitive_id" in pixel colors rather than retrieving from gpu, and store entity data on python side (..). Snap buffer is now re-used so it is way more memory friendly.
Raycast detect engine now rely on object ray cast instead of scene ray cast for performance reasons (~20x faster on huge scenes), with a pretty cool side effect : i was able to provide support for snap to collection instances.
Both detect engines now are way more "lazy", starting by computing bounding rectangle for snap able entity, so only entity below mouse are taken into account when it does perform snap.
Grid engine now is "unit system" aware, providing a 12 sub steps when you are between feet and inches.
Transform engine now rely on gpu "previews" so blender's entity are transformed only once when you confirm and you are able to see result while transforming - and snap to source object. It does support a "pinhole" transformation model (beside move / rotate / scale) allowing to align x axis keeping y axis horizontal, and internally stacked transformations. It is flexible enough to be able to perform sub entity transformations (individual vertices) for projections. Scale operations now occurs in edit mode so base object rotation matrix will not anymore suffer from precision issues.