|
Every journey has
a beginning, and for us, the journey of integrating 3DS Max and .NET tools began
when a level editor needed to be built. The requirements for this new level
editor, which became known as APPLE (Authoring Plugin for Placing Level
Entities), were ambitious. Our level editor had to be platform-independent,
genre-independent, and we had to
have a functional system up and running in less than six months.
The requirements
for this new level authoring tool were driven by the culture at Vicarious
Visions. Vicarious Visions develops handheld and console games on a regular
basis, and many of our level designers move between the various platforms. We
wanted to provide a unified level tool for designers so they could move between
projects without having to learn new applications.
We researched
many possibilities for building a level construction tool, and this article will document
what those options were and why we decided to move forward with a .NET/3DS Max
hybrid solution.
Our goal is to demonstrate how .NET applications and 3DS Max can
be integrated. We will also address issues encountered during the course of
development and how those issues can be overcome. This article is intended to
demonstrate how to integrate .NET applications and 3DS Max and provide
perspective about when this solution is appropriate.
An overview of the data pipeline.
Level Editor
Approaches
With the
requirements and timeline set for our level construction tool, we now had to
research how to achieve this new system.
The first option
we considered was to build a standalone level editor tool from the ground up. This approach
would allow us total control over the new application and give us the freedom
to customize the user interface and subsystems to fit the needs of the
designers and artists at Vicarious Visions.
Building a new
application from scratch would have required time and engineering resources for
building a rendering engine, user interface engine, file I/O and numerous
supporting subsystems. After looking at the volume of work which would need to be
done just to get a basic system off the ground, we concluded that an alternative
needed to be found.
The artists and
designers at Vicarious Visions are 3DS Max users, so we decided to research how
to leverage the existing functionality of 3DS Max to create our level-building tool. The traditional solutions for adding new functionality to 3DS
Max involve either writing plugins in C++ or using MaxScript. With the release
of 3DS Max 9.0, there was a third option to consider when new behaviors and
functionality needed to be added to 3DS Max -- .NET controls. We will go over
why we chose this new solution of .NET integration, but first we need to examine
what the .NET Framework is and how it works.
Image courtesy of codeguru.com
.NET Framework
Overview
The .NET Framework is a software
component provided by Microsoft to facilitate an end-to-end solution for
application development. "End-to-end" means that an application
developer can write code, build code, and execute code entirely within the .NET
Framework using any of the supported .NET languages. The .NET Framework
includes code libraries collectively known as the Base Class Library (BCL),
packaged in managed .dll files called assemblies, that solve common programming
tasks including: user interface, numeric algorithms, file I/O and XML document
manipulation.
The
runtime side of the .NET Framework is called the Common Language Runtime (CLR)
and is responsible for compiling code on the fly with the Just-In-Time
compiler, managing memory and handling exceptions. Programs developed in .NET
languages are initially compiled into an intermediate language called Common
Intermediate Language (CIL).
The CLR is responsible for compiling the
intermediate language into native code when the code is first executed. The "just-in-time"
compiling of intermediate code to native code means that wherever the .NET
Framework is installed, a .NET program will be able to run, regardless of
operating system or hardware configuration. Mono and Portable.NET are examples
of implementations of the CLR other than the Microsoft .NET Framework which are
capable of running .NET programs.
|
Printer-Friendly Version
Much obliged.
This is actually not quite right :-)
http://msdn.microsoft.com/en-us/library/y31yhkeb(VS.80).aspx
The .NET integration-features that have been introduced into MAX is a step in the right direction, but there are some shortcomings that may benefit from the act of being brought to the surface, in case someone out there were dancing a mazurka of joy, thinking they could throw out the MAX sdk come blue morning.
The ability to interface with MAX datatypes from the .NET assembly is practically nonexistant. As a result, shuffling large portions of data to the .NET-side therefore requires iterating the data. This e.g. hardens the possibilities of quickly performing a very common plugin task: munching geometry.
Hopefully, integration will become a bit tighter in the future, although I would rather prefer they put their weight on making MAXscript run faster.
I had such a bad time with making the UI for the tool. I could never make it as good as I would have liked.
IIRC Maxscript cannot access everything that's visible in the UI. For example I had issues with using the "loft" tool in Maxscript. Not sure if anything's changed now. I used Maxscript essentially for raising events and for the UI. The majority of the work was done in the 3DS Max Plugins.
Could you tell us something about the formats in which you had exported the data from 3DS Max?
"For some developers, integration with 3DS Max may mean rewriting thousands of lines of code within .NET, and each developer will need to assess how reasonable that would be to achieve."
I've been in positions where I needed to get a lot of old C code into C#. Lucky for me, it was in a DLL, and C# makes running DLL functions relatively easy with platform invoke. Microsoft has a tutorial at http://msdn.microsoft.com/en-us/library/aa288468.aspx.
You'll have to marshal data between the DLL and your C# code, but there ends up being about 10 basic types of marshals (string, array, pointers, etc etc), and once you've got a handle on them, building a class that will run all your DLL functions for you becomes pretty easy.
Anyways, just my two cents. With platform invoke, you'll still have to write a good bit of C# code, but you don't have to rewrite (and re-debug) the code that does most of the work.