Snapping Branch
@andybak snapping discussion continued...
PThe idea behind this looks right to me.
PIs there anyone here that has a good understanding of the transformation stack? My first guess is that App.Scene.Pos is not the thing we want.
PWhat is the transformation that changes when you scale/rotate the whole scene?
PSeems to be SceneScript->Main Canvas->stuff and when I change the scale rotation in the app it applies the change to the SceneParent (SceneScript)
A(link to start of discussion in entirely the wrong channel: https://discord.com/channels/783806589991780412/884503906703528038/889986531945742346 )
AApp.Pose appears is defined as Coords.AsGlobal[transform] on SceneScript
A
Athe root of unity's scene graph we call "global space"so that sounds wrong. we don't want to work in the unity scene space - we want the canvas space
A"canvas space" = the user's artwork. Typically there's just a single Canvas whose pose is the same as the Scene pose (it's a direct child of the scene, with identity localTransform). But when you have a selection or groups, those are additional Canvas instances
AHowever - this sounds like canvas space == global space == scene pose
ABut when you have a selection or groups, those are additional Canvas instancesMy initial thought is that we can ignore this as we're working ON a selection and not IN a selection but I might be wrong.
AIf I'm right then this should be a no-op. I'm transforming from global space to canvas space.
AI'm curious to separately test canvas translation, rotation and scale to see which ones mess with the grid snapping. That might be a clue. Bit tricky to do manually. I guess I need to write some tests.
AMoat implemented grid snapping for drawing: https://github.com/moatdd/open-brush/commit/e8884ab629853019b5f2a3bbd978f16bb55b5c69#diff-e9f29b3b0bf0aeb63aa1b06e01596135252707616aa98b874daf5123b9b26f8dR31
AO frabjous day! I nicked Moat's snapping code and it worked
AAand then just:
A@moat9195 - thank you
Poh nice!
PApp.ActiveCanvas ftw
PI do wonder why he chose to use worldToLocalMatrix rather than just inverse. They should be equivalent.
PPerhaps that reads better...
�oh lovely
�I forget why I didn't just use transform.InverseTransformPoint() and transform.TransformPoint()
�it should probably work just fine
�bonks head teehee
P
Good stuff. How does the whole ActiveCanvas thing work?�afaik, there's really only ONE canvas in OB
�but I think if you wanted to, you could instantiate multiple canvases, like having separate layers
�and a canvas is a 3D VR canvas, not a 2D thingy
�so the canvas stores all your brush strokes
PIIRC, I tried App.MainCanvas and this didn't work
�and when you perform view manipulations (by pinch-zooming and shoving it around) you are manipulating the canvas, which is a gameobject that acts as the parent for all the brush strokes
�the user does not get scaled, nor do they move around during a view operation
�yeah, I dunno about MainCanvas, but ActiveCanvas worked
PI see view manipulations changing the SceneParent transform. Is that related to the canvas? I assumed the term canvas would correspond to the "Main Canvas" object.
ANow I need to figure out how to unify the UI for the 3 types of snapping: Snapping while drawing, snapping selections (and other widgets) - and snapping procedural geometry creation (currently just my polyhedra but I have plans for this functionality)
AMoat used the canvas zoom level to determine the snapping grid. I kinda like the economy of this approach but I'd have to use it in anger to get a sense of whether it wasn't one overload too far. I used a "snap settings" panel which is clunky but explicit. I don't love it but it works in a "nobody ever got fired for choosing IBM" way (if that strained metaphor makes sense to anyone other than myself)
AThree related issues:
- How to turn grid/angle snapping on and off
- How to set the snap angle and grid size
- How to visualize the grid
Pfor #3, I was thinking there would be a volumetric sphere (radius can vary) around the brush hand where the lines would fade out toward the edge. So maybe a penumbra, umbra sort of thing.
ACheck out Moat's approach. It's not that far off this (but I'd like to make it less psychedelic)
PHmmm, I was thinking of having grid lines drawn on the empty space, not on the object. Perhaps it's useful to both or only 1?
PMoat's visualization looks like it's a custom shader that branches from the normal code to his based on whether it's in the sphere. Or maybe an additional shader pass that bails out if it's not in the sphere.
PI could check out the code but it's so much easier to speculate 
�it's a custom unlit blend shader applied to a sphere
�it reads the depth buffer and uses the camera's position to figure out the world position of each fragment
�and then tints each fragment based its position
�I applied it just to the sphere because I wanted people to be able to preview their scene with the effect off just by moving the sphere out of the way, and i felt that the grid was only necessary to see within close proximity to the brush
�I think I fed the camera's world position into the shader's global parameters
�there may be nicer ways to ascertain a fragment's world position than what I used