Hello everyone! Or should I say, hello anyone? Is anyone out there? I have more I want to say about my math-ridden adventures in VR, but I need to interrupt my irregularly scheduled blogging broadcast to bring you urgent news! I have some time set aside to exclusively update Guppy Animation Tools. I expect this next release will have many breaking changes, so I’ve just released the last maintenance update to Guppy Animation Tools.
For this update I want to:
- Rewrite all GUI’s into QT (expect small tweaks to the UI’s nothing earth shattering).
- Remove features that are either replicated by Maya or don’t seem to be used by many people.
- Rewrite any code that makes me squint and question my own intelligence. (Guppy Animation Tools was written as I learned python. And it shows in some areas.)
What does this mean to you, my dear intrepid reader? It means, if you use a feature and want it to stay, have noticed a bug and want it fixed, or want a new feature, NOW is the time to tell me! For everyone else, as you were!
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.
It’s that time of year again. Update time. A quick review: since the last time I posted, I joined Dreamworks to work on their Oriental Dreamworks pipeline. Due to the constraints of the job, I felt that posting on this blog was not in my best interest. As a result, this website and my git repo languished. I worked with a lot of really awesome people there, but ultimately due to a number of reasons, I decided to leave and try other pursuits.
Pursuits in VR!
I set out with the rough goals:
- Learn about gaming.
- Learn about VR.
- Make a thing.
My first approach was to make a game with grid-snapping in Unreal Engine. I got my feet wet testing new ideas with unreal blueprints and I dusted off my c++ knowledge. My c++ knowledge turned out to be dusty indeed. I quickly ran afoul of Unreals macro system, which made it incredibly difficult to figure out if my particular problem was specific to unreal or not. (For those not in the know, unreal adds a reflection system to c++ via macros and a transpilation process. It’s all very magical.)
I quickly learned that moving code from blueprints to c++ and vice versa is a very manual and error-prone process. But, in the end, I did get my grid snapping system working. Of course, as soon as I did, I learned that zapping tables was way more fun!...continue?
Yes, I have in fact been doing work this past year! Lots of it, actually. A 45 hour standard work week doesn’t leave much time for anything else. Which is why this blog and Guppy Tools have sadly been neglected. Don’t get me wrong, Guppy Tools isn’t broken. I just haven’t been able to give it the love it needs to reflect my current skill level. I hope to change that soon though.
What’s my current skill level you ask? Well, it just so happens that I recently asked my supervisor at Luma Pictures if I could show off a little of what I’ve been doing. And luckily for both of us, I got the go ahead! May I proudly present: Close Contact, a C++ deformer I made solve to approximate collisions a few months ago.
You know how embarrassing and awkward it is getting back in touch with someone you haven’t talked to in a really long time? It usually goes something like this:
So. Umm, hi.
We used to hang out. And then we stopped talking a few years back.
I don’t remember why.
You know that one time when you were like “Oh, man, I totally owe you for that.”
Well, I have this favor that I need to ask…
I’ve finally updated my demo reel! It has my new smooth stretch algorithm front and center. If you didn’t quite understand some of the concepts of my previous posts, you should definitely look at the video. I think it makes the concept if not the math a lot easier to understand....continue?
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?
The particularly astute imaginary visitor will notice that I’ve uploaded Guppy Animation Tools to Github. This is the first repository I’ve put on Github related to Maya. It is a collection of animation scripts and plugins I’ve written in the past eight months or so.
In keeping with my original goal of getting my work to the masses, this collection includes both finished and unfinished works. Clever Keys, one of my most polished scripts, is in this repository. It is a much more recent version of Clever Keys than is on my website or creative crash, with several new bug fixes. Guppy Animation Tools also includes my newest and most untested animation script, Lock ‘n Hide. Lock ‘n Hide lets animators lock and or hide attributes on referenced nodes. Those are two of the six tools in this repository, so if you’re an animator in search of some fun tools go check it out! If you find a bug please report it!
subscribe via RSS