I'm still so hecking happy my selection code managed to reach real-time performance, even with this amount of polygons! :scwee: :acegikHeartShape: I'm doing selection on the GPU with compute shaders, entirely without acceleration structures too, while also taking into account not selecting faces that are obscured/hidden

implemented half-edge box selection in &half-edge !

I've done so many boring backend plumbing things with &half-edge of late so the only visually interesting thing I have done is having implemented camera zoom :pensivebread:

been experimenting with making a tabbed interface for &half-edge ! It's just the UI right now, but this is one of those things that would make it feel a lot more modern compared to the big established modeling tools, where every time you want to open a new model, you have to decide whether to save or discard whatever you already have open. tabs like this would let you work much more fluently in terms of UX, something I'm prioritizing a lot with this tool!

iterated a little more on the &half-edge logo! I kinda like this one!

after spending some more time in win32 hell the titlebar is now even more native feeling! I managed to get rid of the weird 6px spacing at the top titlebar, so now my UI goes all the way to the top, while still keeping windows native resize handles and all that! 🎉

got the standalone build of &half-edge looking fancy with a custom titlebar!! i had to go to win32 hell and back as some of you might've seen in #workspace, to support all the windows features, but it finally works well :SCWblushHEART:

okay I know using unity's UI system is like, the opposite vibe of handmade, but I'm really happy with the progress setting up the UI for &half-edge :heart_cat:
I finally tried their UITK, and it's actually pretty dang nice so far! It's very web-like, for better or worse, but it made me jump into that quick iteration web dev mode where you can just refresh and immediately see changes, which, I didn't think they'd pull off! maybe I had low expectations but, so far it's been nice! The big thing that remains to be seen is how well I can capture input and add all my custom handles into this, since all of that was done with the legacy IMGUI. ~~and also figuring out how to hook into win32 APIs from C# to get borderless windowed with proper resize controls and drop shadow when not full screen and all that which I'm not looking forward to :SCWWcrying: ~~

got trackball rotation for the rotation gizmo in &half-edge working now! lots of quaternion math today, which was fun!

there are a few things that made this an interesting case to implement:

1. all my handles cache the initial state when you start dragging, and then only add a delta. this is useful to prevent the kind of drifting/precision loss you sometimes see in certain gizmos when you only ever apply a per-frame delta, which will accumulate error. unreal's rotation gizmo had this issue, for example
2. in this case, unlike the per-axis rotation, I still do need a cumulative delta

given these constraints, there were lots of space transformation with quaternions I had to do which was kind fun to brush up on and finally grok more properly, so I wrote down some quaternion notes which might be useful to others too! my solution was basically:

• on start drag, cache the current world space quaternion rotation w
• the mouse pixel delta is divided by the radius (in pixels) of the gizmo, which makes it so that the distance you move the cursor, also corresponds to the radians you want to rotate by, thanks to radians being 1:1 with arc length (yay radians :heart_cat: )
• the magnitude of this scaled delta is the angle, and the axis of rotation is a perpendicular vector to this direction, which is a simple (-y,x) or (y,-x) swizzle
• from this, we can construct a quaternion representing a per-frame delta rotation, as a camera space quaternion
• this is then accumulated in another camera space quaternion, by composition delta = frameDelta * delta, the order here ensuring delta is applied in the extrinsic space (swapping them would apply the rotation in the frameDelta's own intrinsic axes, which is, not what we want)
• then, in order to calculate the final rotation, we need to transform our camera space rotation delta, and apply it to a world space rotation. In other words, we want to transform the delta rotation as an intrinsic rotation applied to the camera's rotation c, but as an extrinsic (world space) rotation.
• I did a bunch of math today, and basically it ends up being
  c * delta * c.conjugate(), which, as applied to our initial cached world space starting orientation w, we get
  c * delta * c.conjugate() * w, aaaand then it works!

thanks for coming to my ted talk :henlo:

got the rotation gizmo for &half-edge functional now! it uh, was a little broken bc I forgot to normalize a vector but now it's working c:

got linear drag actions in c: &half-edge

finally been able to do more work on the transform gizmo for &half-edge (really bad timing on that apartment move :SCWWcrying:). I've now got basic handle mouseover detection going, and migrated the handles to be less coupled with the IMGUI loop! the things up next are:

• adding interactivity, to drag these cones for linear movement
• adding the lines for the arrows, so it's not just arrowheads
• adding planar handles for xy/yz/zx movement, and their interactions
• optionally adding modifiers like precision movement, as well as camera-plane dragging!

I'm gonna make a transform gizmo for my 3D modeling tool (tentatively called &half-edge ) for wheel reinvention jam! as with most things in life, it always starts with working out the math for intersection testing a cone in the fragment shader of a quad

example basis! red is the input vector (X axis)

I was toying with an "get orthonormal Y and Z axes given an arbitrary normalized X axis" equation, and the distribution of Y (green) and Z (blue) axes turned out super pretty! :henlo:

I've also moved the mesher (the thing creating a 3D model from my custom geometry data structure) from single threaded to multithreading parallel processing, though, still on the CPU, and it's also bonkers fast now :scwee: I was going to move it to compute shaders as well but I might not even need to at this point. the table here is the process in optimizing what started out as a naive single threaded implementation

so I've been working on a 3D modeling tool!
lately I've been doing a huge overhaul of the entire selection system to be GPU based rather than (..single threaded) CPU-based, and it's been going,, uh, extremely well! almost all selection is now done GPU side with compute shaders. now it's running at real-time speeds even with >16,000 vertices, which means things like real-time selection previews etc are all viable~ :acegikMeow:

I did a talk about lerp smoothing the other day!

The animated interactive slides for this talk are all custom made with js/html/css :scwee:
https://www.youtube.com/watch?v=LSNQuFEDOyQ&t=0s

handmade normal maps :scwee: