Here it is in action:

SO_CubicBezierCurve in action

Here’s what it looks like in the ICE tree:

SO_CubicBezierCurve node in an ICE tree

Here’s the formal description from the source code:

 SO Cubic Bezier Curve is an ICE node for Autodesk Softimage 2011 SAP and above that computes a position on a Bezier curve, where the curve is defined by four input control points (P0, P1, P2, P3), and the distance along the curve is controlled using a parametric input parameter “S.”

It’s possible to replicate this functionality using nothing more than the basic ICE math nodes, but my tests showed that the performance in that case is unacceptably slow; typical results were 500 milliseconds per evaluation for the native math nodes compared to 20 milliseconds for the C++ implementation.

And finally, the binaries:

• SO_CubicBezierCurve-v1.0-32-bit.zip
• SO_CubicBezierCurve-v1.0-64-bit.zip

And a simple test scene:

• BezierCurvePlugin-DemoScene.scn.zip

And the source code:

• https://bitbucket.org/shaderop/so_cubicbeziercurve

I’m unable to provide a Linux build since I don’t have access to Softimage on that platform, but building from the source code provided above should be simple.

Sorry for being rather terse and short on the details, but I imagine this plug-in to be of interest to technical directors for the most part, and I’m assuming that the information provided here is good enough for that audience. But do contact me if you need any help.

A final thought

It’s expected for a custom C++ ICE node to perform better than an equivalent ICE compound, but the one order of magnitude performance advantage is a bit puzzling. The only thing I can conclude is that there’s a certain fixed overhead incurred during the evaluation of every ICE node. And this overhead adds up quickly when evaluating many simple, interconnected ICE nodes.

tl;dr: A single, monolithic ICE node >> a complex ICE compound.

Version 3.0.9 of 3Delight for Softimage was released a little while ago, and it introduced a better, more robust way to distribute customs shaders. But that also meant that my hacks no longer worked.

Fortunately it turned out that the fix was easy to implement. So without further ado, here’s the improved, 3.0.9-compatible glossy reflection and refraction shaders for 3Delight for Softimage:

SO_3DelightShaders_v0.3.xsiaddon.zip

Someone also asked me if I could provide a demo scene that shows these shaders in action. And I’m glad to oblige:

CornellBox-3Delight-Glossy-Refraction.scn.zip

Enjoy.

So to make things easier, I made a few icons to help me tell them apart. Here’s what my taskbar looks like at the moment:

I’m not sure how many microseconds I’ll be saving every day because of those shortcuts, but at least it looks better than two identical icons next to each other.

Here are the icons for Softimage 2010, 2011.5, and 2012 in case someone else wants to use them:

SI2010.ico

SI2011SAP.ico

SI2012.ico

Enjoy!

Softimage already has a robust set of built-in user interface controls that should be adequate for most scenarios, but sometimes it would make sense to build a richer UI, like in the case of integrating external pipeline tools. And since Python is something of a de facto standard in the VFX industry, wxPython and PyQT are often the libraries of choice for such tasks.

The only problem is… Well, you better see for yourself. This is what happened when I tried to import the wxPython module in the script editor inside Softimage:

An instant, albeit orderly crash to desktop.

Here’s the issue as far as I understand it: On Windows operating systems, every process that has a window (i.e. any none-console application) also has a message loop, and each process can only have one message loop. The problem with PyQT and wxPython is that they will try to create their own message loops inside the Softimage process, which somehow leads to the whole process shutting down. I don’t know Linux that well, but the same issue should arise there.

It turns out that the solution to this is to run wxPython or PyQT on their own separate threads, so that both message loops will run in isolation from each other.

Apparently Houdini 9.5 had the same thing happening with PyQT, and its documentation contains a code sample that addresses this issue. All I had to do was repackage it inside a Softimage plug-in, although I used wxPython instead of PyQT because I’m more familiar with it. But it should be trivial to change the code to use PyQT instead.

So, without further ado, here’s the code:

# By Mohammad "ShaderOp" Abdulfatah
#
# This little sample demonstrates how to use wxPython to display
# a dialog box inside Autodesk Softimage. It attached an item
# to the "Window" menu named "WxSceneInfo", which executes a
# a command that shows a wxPython dialog box with a labed and
# two buttons. One button adpats the label with the number
# of top-level objects in the current scne, and the other creates
# a polygonal cube.
#
# Modifying this code to work wiht PyQT should be trivial.
#
# For questions, comments, and feedback, you can reach me
# through my website at http://shaderop.com/contact/
 
import win32com.client
from win32com.client import constants
import threading
 
# This will be used to ensure that only one copy of the dialog
# is running.
is_dialog_running_event = threading.Event()
 
def XSILoadPlugin(in_reg):
  in_reg.Author = "Mohammad Abdulfatah"
  in_reg.Name = "WxSceneInfoPlugin"
  in_reg.Major = 1
  in_reg.Minor = 0
 
  in_reg.RegisterCommand("WxSceneInfo","WxSceneInfo")
  in_reg.RegisterMenu(constants.siMenuMainWindowID,
    "WxSceneInfo_Menu",
    False,
    False)
 
  #RegistrationInsertionPoint - do not remove this line
 
  return True
 
def XSIUnloadPlugin(in_reg):
  strPluginName = in_reg.Name
  return True
 
def WxSceneInfo_Init(in_ctxt):
  oCmd = in_ctxt.Source
  oCmd.Description = "Wx Scene Info"
  oCmd.ReturnValue = True
 
  return True
 
def WxSceneInfo_Execute():
  # only launch the dialog if it's not already running.
  if is_dialog_running_event.is_set() == False:
    __queueCommand(runDialog)
  else:
    # It's probably a good idea to somehow notify the user that
    # the dialog is already running.
    pass
 
  return True
 
def WxSceneInfo_Menu_Init( in_ctxt ):
  oMenu = in_ctxt.Source
  oMenu.AddCommandItem("WxSceneInfo","WxSceneInfo")
  return True
 
def runDialog():
  # Any attempt to import the wx module on the main application thread
  # will cause Softiamge to crash and burn, but since this method runs
  # on a separate thread and has its own message loop, importing wx
  # will work here.
  import wx	
 
  # Now go to town
  class MyFrame(wx.Frame):
    def __init__(self, title):
      wx.Frame.__init__(self,
        None,
        size=(400,300),
        style=wx.DEFAULT_FRAME_STYLE,
        title=title)
 
      # set background color to SI's signature desert gray.
      self.SetBackgroundColour(wx.Color(171, 168, 166))
      self.Bind(wx.EVT_CLOSE, self.OnClose)
 
      self.objectCountLabel = wx.StaticText(self,
        label="Number of objects in scene:",
        pos = (10, 10),
        size = (300, -1))
      self.refreshButton = wx.Button(self, label = "Refresh",
                                     pos = (310, 10))
      self.Bind(wx.EVT_BUTTON, self.OnRefresh, self.refreshButton)
 
      self.createCubeButton = wx.Button(self,
                                      label="Create cube",
                                      pos=(310, 50))
      self.Bind(wx.EVT_BUTTON, self.OnCreateCube, self.createCubeButton)
 
    def OnRefresh(self, event):
      count = Application.ActiveSceneRoot.Children.Count
      label = "Number of objects in scene: {0}".format(count)
      self.objectCountLabel.SetLabel(label)
 
    def OnCreateCube(self, event):
      Application.ActiveSceneRoot.AddGeometry('Cube', 'MeshSurface')
 
    def OnClose(self, event):
      self.Destroy()
      # IMPORTANT: Must release the event once the windows is closed,
      # else the dialog won't launch again until after SI is restarted
      global is_dialog_running_event
      is_dialog_running_event.clear()
 
  app = __getApplication()
  frame = MyFrame("Hello World")
  frame.Show(True)
  is_dialog_running_event.set()
  app.MainLoop()
 
# Following code is copied almost verbatim from Houdini 9.5 sample
# code at http://www.sidefx.com/docs/houdini9.5/hom/cookbook/pyqt/
 
__command_queue = []
__command_queue_lock = threading.RLock()
__command_queue_event = threading.Event()
 
__wx_thread = None
 
def __queueCommand(callable, arguments=()):
  global __wx_thread
 
  if __wx_thread is None:
    __wx_thread = threading.Thread(target=__wxThreadMain,
                                   name="wxThread")
    __wx_thread.start()
 
  __command_queue_lock.acquire()
  __command_queue.append((callable, arguments))
  __command_queue_lock.release()
 
  __command_queue_event.set()
 
def __wxThreadMain():
  while True:
    __command_queue_event.wait()
    __command_queue_lock.acquire()
    command = __command_queue.pop()
    __command_queue_event.clear()
    __command_queue_lock.release()
 
    command[0].__call__(*command[1])
 
__wx_app = None
 
def __getApplication():
  import wx
  global __wx_app
  if __wx_app is None:
    __wx_app = wx.App(False)
  return __wx_app

Here’s what it looks like inside Softimage:

And here’s the link to the Github gist:

https://gist.github.com/911265

Hope this helps.

Attractive section of content. I just stumbled upon your website and in accession capital to assert that I get in fact enjoyed account your blog posts. Anyway I’ll be subscribing to your augment and even I achievement you access consistently rapidly.

I hope they’re not selling dictionaries.

Download:
SO_3DelightShaders_v0.2.xsiaddon.zip

Enjoy!

Update (July 5th 2011):
This version of the plug-in does not work with 3Delight v3.0.9 and later. If you are using that or a later version of 3Delight then you need to Grab the updated plug-in from here.

So I came up with an idea for a little animated ultra-short movie about accessibility. Since my current employer cares a lot about this subject and is known to engage in advocacy for the rights of persons with special needs from time to time, I was hoping that they would be interested in sponsoring this little project of mine. I would get to practice my favorite hobby and learn something along the way, and they would get a little animated clip they they could use on the web or in TV ads. Win-win all around.

To help sell the idea better I tried to mimic the pros as best as I can by making a storyboard.

I pitched it around to different stakeholders, but there were no takers. So, I thought I would post the storyboard here instead of letting it collect e-dust on my hard desk.

And scene.

Maybe I’ll get them next time.

For me it was an eye-opening experience. I don’t have any formal artistic training to speak of, and yet after watching the training videos and spending a few hours with a Wacom Intuos tablet and Sketchbook Pro, this came out:

For me this a personal best, and it’s miles ahead of anything I have ever attempted to paint in my whole life. I’m specially proud of the fact that I didn’t use any reference images.

Thank you Mr. Page!

This post presents a possible implementation for such a messaging system. To avoid confusion with inter-process or network messaging, I’ll refer to “messages” as “events” from now on, which is a less loaded and more accurate term.

But first, let’s introduce the hero.

Saving the world from nine to five

We’ll be building a console-based, non-interactive game that depicts a normal day in the life of a superhero. And please don’t take the phrase “normal day in the life of a superhero” to be some sort of cynical commentary about the state of contemporary story telling or the human condition on my part.

Our hero’s day consists of six main events: waking up, driving to work, checking in, checking out, driving back, arriving home, and going to bed. Here’s one possible way to present his entire miserable existence in code:

class Hero
{
private:
    int m_clockTicks;

public:
    Hero(): m_clockTicks(0) {}

    void Update()
    {
        switch (m_clockTicks++ % 6)
        {
        case 0:
            std::cout << "Hero: Yaaaaawn!" << std::endl;
            break;
        case 1:
            std::cout << "Hero: Getting into the Hero Mobile(tm)."
                      << std::endl;
            break;
        case 2:
            std::cout << "Hero: Punching into the Hero Cave(tm)."
                      << std::endl;
            break;
        case 3:
            std::cout << "Hero: Phew! Finally going home."
                      << std::endl;
            break;
        case 4:
            std::cout << "Hero: Honey! I'm home!"
                      << std::endl;
            break;
        case 5:
            std::cout << "Hero: Zzzzzzz..." << std::endl;
            break;
        default:
            break;
        }
    }
};

int main(int argc, char** argv)
{
    Hero theHero;

    for (int i = 0; i < 12; ++i)
    {
        theHero.Update();
    }
    return 0;
}

The program iterates over just two days of the hero’s life (hence the 12 in the for loop), and produces the following output:

Hero: Yaaaaawn!
Hero: Getting into the Hero Mobile(tm).
Hero: Punching into the Hero Cave(tm).
Hero: Phew! Finally going home.
Hero: Honey! I'm home!
Hero: Zzzzzzz...
Hero: Yaaaaawn!
Hero: Getting into the Hero Mobile(tm).
Hero: Punching into the Hero Cave(tm).
Hero: Phew! Finally going home.
Hero: Honey! I'm home!
Hero: Zzzzzzz...

Certain species of plankton probably lead more exciting lives, but that’s beside the point.

This game, as awesome as it is already, is missing something. Something that would turn it into a classic. Something that would make it stand shoulder to shoulder next to Fallout 3, Fable II, and Torchlight. It needs a pet.

Like any good, faithful companion, the pet will greet our hero every time he comes back from work. So, we’ll need a way to communicate that event to the pet and any other interested parties (like, say, the Mad Scientist’s advanced abduction and extraction team).

There are many ways to go about implementing this, but for the purpose of maximum decoupling between components it would probably be best to use some sort of event bus, where any object can send an event to the bus, which in turn takes care of relaying the events to all objects interested in receiving them.

After some false starts and dead ends, I ended up with a solution composed of the following components:

• TypeIdentifer<T>: discussed at length in a previous post.
• Event: The base case for all events sent and received in the system.
• IReceiver: An interface to be implemented by event receivers.
• IEventBus: The interface for the event bus.
• EventBus: A concrete implementation of IEventBus.

What follows is a closer look at some of these components.

The Event class

This one is ridiculously simple:

namespace Events
{
    class Event
    {
    public:
        virtual ~Event() {}
    };
}

It’s just a marker interface that does nothing on its own.

Our game will have just one event, HeroMovedEvent, defined as follows:

class HeroMovedEvent : public Events::Event
{
public:
    enum Locations { HOME, WORK, ROAD };
private:
    Locations m_location;
public:
    explicit HeroMovedEvent(Locations location)
        : m_location(location)
    {
    }

    Locations Location() const
    {
        return m_location;
    }
};

We’ll see how to use it a bit later.

The IReceiver interface

Which declares a single virtual method:

namespace Events
{
    class IReceiver
    {
    public:
        virtual void Receive(unsigned int eventId, Event* e) = 0;
        virtual ~IReceiver() {};
    };
}

A partial implementation of the Hero’s pet would look like this:

class HerosPet: public Events::IReceiver
{
    /* Some detailed omitted */
public:

    void Receive(unsigned int eventId, Events::Event* e)
    {
        if (eventId == Events::TypeIdentifier<HeroMovedEvent>::id())
        {
            HeroMovedEvent* e_ = static_cast<HeroMovedEvent*>(e);
            OnHeroMoved(e_);
        }
    }

    void OnHeroMoved(HeroMovedEvent* e)
    {
        if (e->Location() == HeroMovedEvent::HOME)
        {
            std::cout << "Pet:  Woof! Woof!" << std::endl;
        }
    }
};

We’ll add the missing details in just a bit.

The IEventBus interface

Defined thusly:

namespace Events
{
    class IEventBus
    {
    public:
        virtual void Register(unsigned int eventId, IReceiver* receiver) = 0;
        virtual void Unregister(unsigned int eventId, IReceiver* receiver) = 0;
        virtual void Unregister(IReceiver* receiver) = 0;
        virtual void Broadcast(unsigned int eventId, Event* event) = 0;
        virtual ~IEventBus() {}
    };
}

Any class that wants to be notified of events registers itself with the bus by passing the event id (obtained through TypeIdentifier<T>::id method) and itself to the Register method. The reverse operation is done by passing the same arguments to the Unregister method. The second version of Unregister is just a convenience method that unsubscribes a receiver from all events.

I provided an implementation for this interface in a class named EventBus, the details of which aren’t very interesting, so I won’t go over them here.

The Revised Game

Using the components above, the Hero class changes to this:

class Hero
{
private:
    int m_clockTicks;
    Events::IEventBus* m_eventBus;
public:
    explicit Hero(Events::IEventBus* eventBus)
        : m_clockTicks(0), m_eventBus(eventBus) {}

    void Update()
    {
        switch (m_clockTicks++ % 6)
        {
        case 0:
            {
                std::cout << "Hero: Yaaaaawn!" << std::endl;
                break;
            }
        case 1:
            {
                std::cout << "Hero: Getting into the Hero Mobile(tm)."
                          << std::endl;
                HeroMovedEvent e(HeroMovedEvent::ROAD);
                m_eventBus->Broadcast
                    ( Events::TypeIdentifier<HeroMovedEvent>::id()
                    , &e
                    );
                break;
            }
        case 2:
            {
                std::cout << "Hero: Punching into the Hero Cave(tm)."
                          << std::endl;
                HeroMovedEvent e(HeroMovedEvent::WORK);
                m_eventBus->Broadcast
                    ( Events::TypeIdentifier<HeroMovedEvent>::id()
                    , &e
                    );
                break;
            }
        case 3:
            {
                std::cout << "Hero: Phew! Finally going home."
                          << std::endl;
                HeroMovedEvent e(HeroMovedEvent::ROAD);
                m_eventBus->Broadcast
                    ( Events::TypeIdentifier<HeroMovedEvent>::id()
                    , &e
                    );
                break;
            }
        case 4:
            {
                std::cout << "Hero: Honey! I'm home!"
                          << std::endl;
                HeroMovedEvent e(HeroMovedEvent::HOME);
                m_eventBus->Broadcast
                    ( Events::TypeIdentifier<HeroMovedEvent>::id()
                    , &e
                    );
                break;
            }
        case 5:
            {
                std::cout << "Hero: Zzzzzzz..." << std::endl;
                break;
            }
        default:
            break;
        }
    }
};

Nothing fancy here. The Hero class raises a HeroMovedEvent whenever the Hero changes locations.

And here’s the full implementation of the HerosPet class presented earlier:

class HerosPet: public Events::IReceiver
{
private:
    Events::IEventBus* m_eventBus;
public:
    explicit HerosPet(Events::IEventBus* eventBus)
        : m_eventBus(eventBus)
    {
        m_eventBus->Register
            ( Events::TypeIdentifier<HeroMovedEvent>::id()
            , this
            );
    }

    ~HerosPet()
    {
        m_eventBus->Unregister(this);
    }

    void Receive(unsigned int eventId, Events::Event* e)
    {
        if (eventId == Events::TypeIdentifier<HeroMovedEvent>::id())
        {
            HeroMovedEvent* e_ = static_cast<HeroMovedEvent*>(e);
            OnHeroMoved(e_);
        }
    }

    void OnHeroMoved(HeroMovedEvent* e)
    {
        if (e->Location() == HeroMovedEvent::HOME)
        {
            std::cout << "Pet:  Woof! Woof!" << std::endl;
        }
    }
};

And here’s the main method that wires all the components together:

int main(int argc, char** argv)
{
    Events::EventBus theBus;
    Hero theHero(&theBus);
    HerosPet thePet(&theBus);

    for (int i = 0; i < 12; ++i)
    {
        theHero.Update();
    }
    return 0;
}

And here’s the output:

Hero: Yaaaaawn!
Hero: Getting into the Hero Mobile(tm).
Hero: Punching into the Hero Cave(tm).
Hero: Phew! Finally going home.
Hero: Honey! I'm home!
Pet:  Woof! Woof!
Hero: Zzzzzzz...
Hero: Yaaaaawn!
Hero: Getting into the Hero Mobile(tm).
Hero: Punching into the Hero Cave(tm).
Hero: Phew! Finally going home.
Hero: Honey! I'm home!
Pet:  Woof! Woof!
Hero: Zzzzzzz...

This works nicely. The sender and receiver only need to know about the IEventBus interface and the type of the events they wants to exchange. But there’s one problem, and that is the Receive method in HerosPet:

    void Receive(unsigned int eventId, Events::Event* e)
    {
        if (eventId == Events::TypeIdentifier<HeroMovedEvent>::id())
        {
            HeroMovedEvent* e_ = static_cast<HeroMovedEvent*>(e);
            OnHeroMoved(e_);
        }
    }

This is fine for now, but as the number of events increases, the Receive method will grow into a series of ugly if-else statements, reminiscent of the Windows message loop.

Ideally, this should be made easier by using something like event tables in wxWidgets or message maps in WTL, preferably without using any pre-processor hacks. And I’ll try do just that in the next post. So I’ll defer providing the full source code until then.

For example, Chapter 2 has a subsection about adding inter-object messaging capabilities to the sample presented in that chapter. The author proposes using enums to identify each message type that the system can send or receive. So somewhere in the program there should be one (possibly huge) header with the following:

enum message_type
{
    Msg_HeroMoved,
    Msg_WeaponFired,
    Msg_BulletHit,
    .
    .
};

There’s also a corresponding message class for each message_type enum that holds information related to the message, like the new location of the hero in case of a Msg_HeroMoved message, or the type of projectile fired in the case of a Msg_WeaponFired message.

I happen to think that using unique IDs for each message is actually a good idea because if its simplicity. I just have a problem with how it’s implemented. Maintaining both a long list of message IDs and the corresponding message classes feels redundant and error-prone to me.

One could move the ID to the message classes, like so:

class HeroMovedMessage
    : public MessageBase
{
    /* Some details omitted ... */

public:
    static unsigned int TypeId();
    Point Location() const;
}

But that leads to more potential issues. It’s not possible to force every message class to include a static TypeId method, and ensuring that the IDs don’t collide becomes a burden requiring the code author to either maintain a list of IDs externally or check all other message classes manually before adding a new ID.

I can think of a few ways that could make the process less tiresome, but the added complications make the original enum list solution look simple and elegant in comparison.

Something simpler is needed.

Back to the drawing board

What I would like to have is a method that looks like this:

template <typename T> unsigned int TypeId()
{
    // Should return a unique value for each T...
}

If such a method can be implemented, then it would become trivial to identify any message class (or any class in the system for that matter) like so:

class A{};

int main(int argc, char** argv)
{
    unsigned int id = TypeId<A>();

    return 0;
}

This would also work nicely in an ID-based messaging system, since both sender and receiver already know about the message classes they care about and can directly identify them using their type IDs. Message passing could look like the following code:

class HeroMovedMessage
    : public MessageBase
{
    /* some details omitted ... */
public:
    Point Location() const;
};

class Hero
{
private:
    void SendMessage(unsigned int messageId, Message* msg)
    {
        // ...
    }
public:
    void Update()
    {
        HeroMovedMessage msg = HeroMovedMessage(x_, y_);
        SendMessage(TypeId<HeroMovedMessage>(), &msg);
    }
};

class HerosPet
{
public:
    void ReceiveMessage(unsigned int messageId, Message* msg)
    {
        if (messageId == TypeId<HeroMovedMessage>())
        {
            Message* msg_ = static_cast<HeroMovedMessage>(msg);
            // ...
        }
    }
};

So, yes, a working TypeId function would actually work pretty well in this particular case. Now all that is left is an implementation for it. For that, I’ll need two ingredients:

1. A way to obtain the name of a class as a string.
2. A hashing algorithm that will produce a unique ID from said string.

Item number two is a solved problem. As discussed at length in the post titled “Hashing Algorithms,” a CRC32 checksum or a SHA-1 or MD5 digest of the name of the class should give a unique ID for any reasonably-sized set of classes. I’ll be using CRC32 for this example because it’s already implemented in Boost.

Item number one requires more effort.

Getting the type name through RTTI

The closest thing to reflection in C++ is Run-Time Type Information (RTTI). The bits I’ll need are the typeid operator and the type_info class. Extracting a class name this was is a breeze:

// Forward declaration
int GenerateCrcChecksum(const char* data);

template <typename T> unsigned int TypeId()
{
    return GenerateCrcChecksum(typeid(T).name());
}

The name method returns the fully qualified name of the class, including the namespace and template parameters (if any). And since it’s part of the standard it should be portable across all compilers.

But we’re not quite done yet. RTTI has a bit of a reputation for being slow. How slow it is is a subject of long and lengthy debates, but I would rather err on the side of mature optimization and avoid RTTI altogether if possible.

Fortunately, there is a way.

Getting some help from the preprocessor

After some furious head scratching I ended up looking through the Microsoft Visual C++ predefined macros for help. The most promising one was the nonstandard __FUNCTION__ macro, described thusly:

Valid only within a function and returns the undecorated name of the enclosing function (as a string). __FUNCTION__ is not expanded if you use the /EP or /P compiler option.

The initial test was disappointing. Here’s the code:

class A{};

template <typename T> void WhatsMyName()
{
    std::cout << __FUNCTION__ << std::endl;
}

int main(int argc, char** argv)
{
    WhatsMyName<A>();
    return 0;
}

And here’s the output

WhatsMyName

Which not useful at all since there’s no mention of the template type used to invoke the function.

I took a shot in the dark and tried using a static member function instead of a free standing one:

class A{};

template <typename T> class WhatsMyName
{
public:
    static void Name()
    {
        std::cout << __FUNCTION__ << std::endl;
    }
};

int main(int argc, char** argv)
{
    WhatsMyName<A>::Name();
    return 0;
}

Here’s the output:

WhatsMyName<class A>::Name

Which is just perfect. I don’t even need to trim the resulting string to extract only the name of the class. I only need to have the fully qualified name somewhere inside the string since all the other text around it is fixed. I have also tested this method with templates and namespaces, and it still works.

GCC has a similar macro called __PRETTY_FUNCTION__ that works along the same lines. Since MSVC and GCC are the only two compilers that I care about, I can fall back to the RTTI method for other compilers.

So the new implementation for TypeId (or TypeIdentifier as it’s now called) becomes:

#include "GenerateTypeId.h"

template<typename T> class TypeIdentifier
{
public:
    static unsigned int id()
    {
        #if defined (_MSC_VER)
            return GenerateTypeId(__FUNCTION__);
        #elif defined(__GNUC__)
            return GenerateTypeId(__PRETTY_FUNCTION__);
        #else
            return GenerateTypeId(typeid(T).name());
        #endif
    }
private:
    TypeIdentifier();
};

I have moved the actual generation of the CRC checksum to a separate function in a different file and added a bit of caching and some checking for duplicate IDs while I was at it. The full source code is provided at the end of this post.

Final thoughts

One caveat here is that I would be very careful about using IDs generated this way for persistence or for sending objects across the wire. CRC checksums are deterministic, but the data used to generate them in this case is not the same across different compilers or possibly different versions of the same compiler. So caveat emptor there.

The other issue is that the IDs might collide given a large set of classes (or a particularly unlucky choice of names). But that problem is easy to detect early on in debug builds, which is what I opted to do in my code. And if that problem does occur then switching from CRC32 to SHA-1 or MD5 or simply renaming one of the two offending classes should take care of it.

Now I’ll leave you with the code. I tested it with Visual C++ 2010, but it should compile on G++ with C++0x extensions enabled.