Blogs

Mayaseed 0.1.5 Release

Heres the latest version of Mayaseed, version 0.1.5, a few new features and bug fixes. The main feature this time is the ability to bake maya render nodes to textures for rendering in appleseed, enjoy!

Release notes

  • Added the option to convert maya shading nodes to exr textures
  • Colors are now normalised by default
  • A bug has been fixed that stopped the attribute editor from loading correctly due to a renamed function

Download for all platforms here

Mayaseed 0.1.4 Release

Heres the latest version of Mayaseed, version 0.1.4, this is a minor release fixing a small but that prevented the render from finishing in some scenes.

Release notes

  • A bug has been fixed that prevented the export from finishing due to a missing version string in ms_export.py

Download for all platforms here

Mayaseed 0.1.3 Release

Heres the latest version of Mayaseed, the link to download is below. As it's the first version I will substitute the release notes for a list of the main features.

Main features

  • Node based render settings
  • Create environments with the Appleseed Environment node
  • Automatic texture conversion to EXR
  • Simple Maya file based installer
  • Automatic generic shader translation of maya Lambert, Blinn, Phong and Surface shader
  • Per Maya shader translation attributes
  • Python module of useful commands

Download for all platforms here

Welcome to my blog

Hi there, welcome to my new blog. Its mainly a place for me to talk about Mayaseed and more importantly for me, a place for people to talk back.

So without further ado, Mayseed is an exporter to get your scenes and shaders from Maya into appleeed, I've recently finished rewriting it as a node based plugin and thought that it was time to get organised and make a blog. Like appleseed, Mayaseed is open source and licensed under the MIT licence so feel free to download it and do whatever you like with it. At the moment it's really a hobby but its not far from being usable. As it's a hobby and I'm not a professional developer by any stretch of the imagination there will be bugs and limitations, some of which I know about and will fix and some of which I dont, which is where you come in, if you guys report bugs I can fix them, and then everyone is happy

I will be posting releases on this blog but you can also download the latest version from github here

Also, I have a personal website here for anyone who's interested

www.jonathantopf.com

enjoy!

jt

Workaround for Visual Studio's infamous error C2719

In Visual Studio 2005, 2010 and possibly many other versions, whenever you try to store aligned data structures into a std::vector you'll get the following error:

error C2719: '_Val': formal parameter with __declspec(align('16')) won't be aligned

Here's a code snippet that triggers this error:

#include <vector>

struct __declspec(align(16)) S
{
    int x;
};

int main()
{
    std::vector<S> v;
    return 0;
}

This is a well known and well documented issue in Visual Studio's implementation of the STL library.

The common workaround seems to revolve around dropping std::vector in favor of some kind of custom container that doesn't have this problem.

I found another workaround that I didn't see mentioned elsewhere: templatize the data structure that requires alignment. Here is an example that compiles and appears to work correctly:

#include <vector>

template <typename>
struct __declspec(align(16)) S
{
    int x;
};

int main()
{
    std::vector<S<void>> v;
    return 0;
}

Obviously the template parameter isn't used and can be set to anything.

Update Feb. 22, 2012: It's not so simple. The dreaded C2719 error may appear again if the type (S<void>) was instantiated earlier in the translation unit, but this will also depend on the bitness (32-bit vs. 64-bit), the alignment value and probably the size of S<void>. To summarize:

Type instantiated earlier? Bitness Alignment Result
No Any Any OK
Yes 32-bit 16 bytes C2719
Yes 32-bit 32 bytes C2719
Yes 32-bit 64 bytes C2719
Yes 64-bit 16 bytes OK
Yes 64-bit 32 bytes OK
Yes 64-bit 64 bytes C2719

Yuck.

Update Feb. 23, 2012: I outlined a more robust solution in this post on StackOverflow.

DTrace in Rendering

I've grown to really enjoy Bryan Cantrill's way of doing talks and presentations. He's got an incredibly lively way of speaking and demoing stuff which invariably makes for an interesting show, pretty much regardless of the topic.

Most of Bryan's talks are about DTrace since it's what he spent most of his career building. DTrace is a very impressive tool that allows live introspection of software systems. Basically, the operating system (or any piece of software running on it, really) can be instrumented beforehand with so-called DTrace probes. These probes can be activated and queried at runtime in various ways using short programs called D scripts.

A key idea in DTrace's design is that these probes don't incur any performance penalty when they're not used (technically a probe is just a few bytes of no-ops that allow live-patching of the code later). So a software product can be built and shipped with a ton of probes: in normal production time they won't impact the performance of the system, but they'll allow debugging and deep introspection if the system starts to behave incorrectly or if performances drop, all this without having to take the system down.

Clearly this kind of deep performance introspection facility would be a great tool to form a precise idea of what is really going on under the hood of a renderer. For instance, it would allow querying the performances of the texture or geometry cache, measure the ray throughput, etc. It would be a fantastic tool to understand the complex behavior of the renderer, discover bottlenecks and debug performance problems.

How naive of me was it to think this was a novel idea! I quickly discovered that PBRT, the renderer described in Matt Pharr and Greg Humphreys' Physically Based Rendering book, already ships with several DTrace scripts.

I wish we had that in appleseed. Maybe an interesting project for someone whose interests are at the confluence of system programming and rendering performance!

Welcome to the arena, Mitsuba!

I learnt yesterday (in a post on the ompf forum) that Wenzel Jacob has just released Mitsuba, an impressive, feature-packed physically-based renderer. The full C++ source code is available.

Obviously Mitsuba has many more features than appleseed and, I believe, is generally more advanced. What strikes me though is the similarity, both in the philosophy and in the realization, between Mitsuba and appleseed. From what I could gather:

  • Both are large, platform-independent C++ frameworks aiming at supporting a variety of rendering algorithms (called "integrators" in Mitsuba, inheriting the term from PBRT).
  • Both are aiming at generality and robustness.
  • Both provide a Qt-based graphical user interface and a command line tool.
  • Both feature a scene description language based on XML (and Mitsuba also seems to use the heavy-duty Xerces-C XML parser that's also used in appleseed).

Massive congrats to Wenzel for pulling this off. I'm definitely looking forward to see where Mitsuba will be going in the future.