HNHacker News
TopNewBestAskShowJobs

nosferalatu123

120 karma · joined April 6, 2023

submissionscomments
nosferalatu123··on Derivatives and Logarithms of 3D Transforms
It's using the three.js library and a bit of javascript I wrote.
nosferalatu123··on Derivatives and Logarithms of 3D Transforms
Yep!
nosferalatu123··on Derivatives and Logarithms of 3D Transforms
(author here) Be careful because (ignoring scale for to keep things simple) a transformation T can be decomposed into a translation and rotation, such that T=Rotation * Translation, but that translation is not along the axis of rotation. You probably want to instead interpolate with a screw motion, which is a rotation about an axis along with a translation along that axis (a helical curve; a curve along the outside of a cylinder). The screw motion is what you get when you interpolate with exp(log(T)*t).
nosferalatu123··on Laplacian Mesh Smoothing by Throwing Vertices
(author here) That's correct. The algorithm preserves topology because no new vertices or indices are created. It can result in self intersecting meshes, but one way that this can be used is what Substance Modeler does, which is continuously remesh.
nosferalatu123··on Don't "optimize" conditional moves in shaders with mix()+step()
A lot of the myth that "branches are slow on GPUs" is because, way back on the PlayStation 3, they were quite slow. NVIDIA's RSX GPU was on the PS3; it was documented that it was six cycles IIRC, but it always measured slower than that to me. That was for even a completely coherent branch, where all threads in the warp took the same path. Incoherent branches were slower because the IFEH instruction took six cycles, and the GPU would have to execute both sides of the branch. I believe that was the origin of the "branches are slow on GPUs" myth that continues to this day. Nowadays GPU branching is quite cheap especially coherent branches.
nosferalatu123··on Higher Order Derivatives of Transforms
Author here. My background is game development. Now I work on 3D modeling software. I wouldn't say I know "higher level math", because that seems like a very deep well...

What would be the best way to define "transform" here? What I mean is something that can be applied to a point, like a linear map. So translation, and/or rotation, and/or scaling, and/or skewing, are all things that can be done by this "transform" in 3D.

In computer graphics these are often expressed as 3x3 or 4x3 (or sometimes 4x4) matrices. But a "translation+quaternion" can also be a transform, or just a quaternion (a unit quaternion can be used to rotate points for example). So I'd be happy to use a better definition for "transform" than 'given a transform T that can be applied to a point' but I'm not quite sure what the best definition would be.

nosferalatu123··on Higher Order Derivatives of Transforms
I meant a "transform" as a linear map. I'm using the word as it is used in computer graphics (my background), so it's something that translates, rotates, scales, etc. other things (such as points). That is often a 3x3 or 4x4 matrix, although it can also be a vec3 translation and a quaternion, or just a quaternion. I think "Transform" is clear in the context of computer graphics, but I see what you mean about it being vaguely defined in my blog post.