Like most of my personal projects, I fell into this math hole with a few (not so) simple items on my agenda. They eventually looked something like this:
- Learn OpenGL.
- Make a VR sculpting application.
- Write this using only C++ and small helper libraries. No big frameworks.
- Implement a signed distance renderer.
But I’m getting ahead of myself a bit. In the beginning, I discovered signed distance fields while doing research for a shader I was trying to write in Unreal Engine. I saw a bunch of cool examples, and wanted to dive right in and figure out how all this stuff worked! Unfortunately, all the examples I was looking at were written in GLSL. Learning a new complex subject and trying to translate that into Unreal’s shader system was more than I wanted to chew off. So, I opened up Unity for the first time, and started coding (that’s simpler, right?).
As it turns out, this WAS simpler. After learning the basics of how modern game engines were organized in Unreal, picking up a little Unity was a breeze. Coming from python/c++ background, C# was very straight forward as well, especially with the great IDE integration with Visual Studio Code. I really enjoyed learning C#. I wish this language had more adoption in the fields I normally work in.
To get started, I read a few signed distance field ray marching tutorials specifically for Unity. For more information, I inspected a number of shadertoy shaders. Then I dug in deeper, and got the whole thing to render in VR. My backwards approach to learning unity gave me a good laugh at the time. I started with learning the shader system, then how to integrate my shaders with C#/SteamVR, and only at that point did I learn how to spawn an object.
Excellent. Smooth stretch was solved. Another day, another math problem solved. I felt like a crime fighter who just beat this giant math monster back. Or was the math monster really solved? Wait, wait wait. Hold on a minute here! The whole reason of redoing this thing was that smooth stretch 2.0 didn’t work well in an IK/FK switch! If this new formula can’t help me solve that, then it’s no better than the old one. Oh crap!...continue?
As I was trying to say in my last post, two weeks ago I began my mathematical journey into smooth stretch. This time around I knew what I wanted to accomplish. I wanted a way to represent smooth stretch using just math. My Maya API chops had increased since my last attempt, so I could now wrap this math into a nice python/c++ node....continue?
My mathematical journey into the world of smooth stretch began two weeks ago. Or rather, it started a long time ago when I first learned about smooth stretch from Michael Hutchinson’s cool Elastik plugin. At that time I tried to replicate it using just sweat, blood, an XSI Blog post on the matter for some math insight and native Maya nodes.
Smooth stretch is actually on my latest (and now outdated) demo reel. That version was my second attempt at smooth stretch. Version 2.0. This was my third attempt. Version 3.0. There’s something magical about the third attempt of any problem. By then you know the real issues. You know what to concentrate on and the pitfalls to avoid. You have the time to concentrate on what’s really important. In short, the third attempt is where shit gets done....continue?
subscribe via RSS