Planet Tech Art
Last update: March 18, 2017 04:00 AM
March 16, 2017

Developer Tooling, a week in

So I switched job role from graphics to developer tooling / build engineering about 10 days ago. You won’t believe what happened next! Click to find out!

Quitting Graphics

I wrote about the change right before GDC on purpose - wanted to see reactions from people I know. Most of them were along what I expected, going around “build systems? why?!” theme (my answer: between “why not” and ¯\_(ツ)_/¯). I went to the gathering of rendering people one evening, and the “what are you doing here, you’re no longer graphics” joke that everyone was doing was funny at first, but I gotta say it to you guys: hearing it 40 times over is not that exciting.

At work, I left all the graphics related Slack channels (a lot of them), and wow the sense of freedom feels good. I think the number of Slack messages I do per week should go down from a thousand to a hundred or so; big improvement (for me, anyway).

A pleasant surprise: me doing that and stopping to answer the questions, doing graphics related code reviews and writing graphics code did not set the world on fire! Which means that my “importance” in that area was totally imaginary, both in my & in some other people’s heads. Awesome! Maybe some years ago that would have bothered me, but I think I’m past the need of wanting to “feel important”.

Not being important is liberating. Highly recommended!

Though I have stopped doing graphics related work at work, I am still kinda following various graphics research & advances happening in the world overall.

Developer Tooling

The “developer tools” team that I joined is six people today, and the “mission” is various internal tools that the rest of R&D uses. Mostly the code build system, but also parts of version control, systems for handing 3rd party software packages, various helper tools (e.g. Slack bots), and random other things (e.g. “upgrade from VS2010 to VS2015/2017” that is happening as we speak).

So far I’ve been in the build system land. Some of the things I noticed:

  • Wow it’s super easy to save hundreds of milliseconds from build time. This is not a big deal for a clean build (if it takes 20 minutes, for example), but for an incremental build add 100s of milliseconds enough times and we’re talking some real “developer flow” improvements. Nice!
  • Turns out, a lot of things are outdated or obsolete in the build scripts or the dependency graph. Here, we are generating some config headers for the web player deployment (but we have dropped web player a long time ago). There, we are always building this small little tool, that turns out is not used by anythign whatsoever. Over here, tons of build graph setup done for platforms we no longer support. Or this often changing auto-generated header file, is included into way too many source files. And so on and so forth.
  • There’s plenty of little annoyances that everyone has about the build process or IDE integrations. None of them are blocking anyone, and very often do not get fixed. However I think they add up, and that leads to developers being much less happy than they could be.
  • Having an actual, statically typed, language for the build scripts is really nice. Which brings me to the next point…

C#

Our build scripts today are written in C#. At this very moment, it’s this strange beast we call “JamSharp” (primarily work of @lucasmeijer). It is JamPlus, but with an embedded .NET runtime (Mono), and so the build scripts and rules are written in C# instead of the not-very-pleasant Jam language.

Once the dependency graph is constructed, today it is still executed by Jam itself, but we are in the process of replacing it with our own, C# based build graph execution engine.

Anyway. C# is really nice!

I was supposed to kinda know this already, but I only occasionally dabbled in C# before, with most of my work being in C++.

In a week I’ve learned these things:

  • JetBrains Rider is a really nice IDE, especially on a Mac where the likes of VisualStudio + Resharper do not exist.
  • Most of C# 6 additions are not rocket surgery, but make things so much nicer. Auto-properties, expression bodies on properties, “using static”, string interpolation are all under “syntax sugar” category, but each of them makes things just a little bit nicer. Small “quality of life” improvements is what I like a lot.
  • Perhaps this is a sign of me getting old, but e.g. if I look at new features added to C++ versions, my reaction to most of them is “okay this probably makes sense, but also makes my head spin. such. complexity.“. Whereas with C# 6 (and 7 too), almost all of them are “oh, sweet!”.

So how are things?

One week in, pretty good! Got a very vague grasp of the area & the problem. Learned a few neat things about C#. Did already land two pull requests to mainline (small improvements and warning fixes), with another improvements batch waiting for code reviews. Spent two days in Copenhagen discussing/planning next few months of work and talking to people.

Is very nice!

by at March 16, 2017 06:42 PM


March 14, 2017

Maya C++ Plugin Environment on Mac OSX

This is just a quick guide for all the Mac users out there that are trying to build Maya plugins in C++.

I learned a lot about CMake and compiling for maya from Chad Vernon's series, if you have a bit of time on your hands, I definitely recommend going through this as it will be very detailed.

For this example I also used Chad Vernon's BlendNode that he was so nice to share.





What we want to end up with basically being able to press Ctrl+B in Sublime Text and having the plugin built and copied into the maya folder so all we have to do is fire it up in maya.

The first thing is to install cmake. Once you have done that, you need to create a good file structure.

Mine looks like this


  • PROJECTS
    • __MODULES
    • PROJECT A
      • build (folder where the binaries will end up after compiling)
      • __MAKE.sh (the file to run for building the makefile) 
      • __BUILD.sh (the file we use to compile the plugin and copy to the maya dir)
      • CMakeLists.txt (cmake settings file)
      • src (the folder containing our .cpp and .h files
        • plugin.cpp
        • plugin.h
        • CMakeLists.txt (more cmake settings)
    • PROJECT B
      • etc...

Download the FindMaya.cmake file and place it in the right folder. Next up we place the .cpp and .h in the src subdirectory. Once we have that in place, lets create the CMakeLists.txt.

The CMakeList in the root directory of the project will look like this:
The one in the subdirectory "src" will look like this. Just be sure to change the filenames in the first two lines to yours

Ok now we add the two bash scripts:

__MAKE.sh


__BUILD.sh





You can now double click __MAKE.sh which will create the build for you and will hopefully look like this.










You can now compile by double clicking __BUILD.sh or you can setup a simple build script for SublimeText.

In Sublime go to Tools -> Build System and New Build System.
This will open a new file. The build command we will create will basically just walk up one folder from where its run and run the __BUILD.sh.








Paste this into the file, save it and close it

Great, now simply go to your .cpp file in sublime and hit ctrl+B, it should compile and copy the plugin into your maya directory.

GG! Now fire up maya and load the plugin!

by Marcus Krautwurst (noreply@blogger.com) at March 14, 2017 08:46 AM


March 12, 2017

Pose Space Reader

I'am alive and well, thanks for asking!

I know it has been quiet here, I haven't been showing any progress for a while. I am slowly getting back into a habit of learning new things and sharing them here. After a huge learning experience digging into the Maya API I am calling this project done, at least for now while I move on to other things😊

I present to you my first maya plugin. Pose space nodes are most commonly used to hook up corrective blendshapes to a mesh, but can be used for anything you want really. To hook it up you can select a joint and add the pose space reader node to it. It will also create a locator along with it, which will be used as the target node.

The pose space reader node will then output a float between 0-1 depending on how close the locator is to the center of the cone. There is a length attribute for visualisation purposes on it but the cone used for the calculations is in deed infinitely long.

I can only recommend writing this, especially if you want to get better at trigonometry! All in all, a really fun project that made me pick up my pen and get to the bottom of some things I always wanted to know.

Now enough talk, enjoy the video

Thank you hippydrome.com for providing the model

by Marcus Krautwurst (noreply@blogger.com) at March 12, 2017 08:29 PM


The Wizard Of Cos

I never worked on a demo before and had the pleasure to help PandaCube out with some rigging and animation. It won the 3rd prize in the PC compo at Revision 2014. Hope you like it.

by Marcus Krautwurst (noreply@blogger.com) at March 12, 2017 08:26 PM