Last week I digged into the topic of exporting a lightmapped, vertex-colored scene from 3ds max to Unity. Unity3D does not come with special exporters but exports to standard formats like FBX and COLLADA. When exporting to FBX, 3ds max Shell Materials do not get converted automatically to a lightmapped shader upon import. No wonder as FBX (= Filmbox which became later MotionBuilder) is not specially targeted towards game content. Therefore you have to manually assign the shader and the second texture. Of course it would better if this could be automatized!

Here are two pictures from a test scene with vertex-colored houses we created once for Virtools-based projects. The houses are currently using only dummy lightmaps, but that's the result without any manual shader or texture assignments.

So, here is how I do it.

Preparations inside 3ds max with Maxscripting (MXS)

Unity allows to hook into the assets import pipeline via custom scripts. This is very cool concept and is similar to something we did for our Virtools Assets&Build pipeline which we called BogBuilder btw. The key concept is therefore to *somehow* pass hints to a assets post processor script. What I do is to tag material names inside 3ds max, for example using __lm__ to indicate that the material is a lightmapped one. I use two underscores on each side because it reduces the probability that the original name accidentally contains such a sequence of letters.

I did not found a way to extract the names of lightmap texture from FBX files inside a Unity post processor script. So I actually add the texture name to the material name itself too! Here is an example of how a material inside 3ds max can look like after preprocessing

wandputz-tex__lm__S_4_WaendeCompleteMap_ambient-schlagschattenMulti100.tga

Pretty long, hehe. But it helps!

The custom maxscript does thus the following for every shell material

• take the texture from baked material and put it into the original material's self-illumination slot
• add the lightmap tag to the original material name (if it's not already there)
• add the lightmap texture filename (including extension) to the material name
• assign the original material back onto the geometry

Don't forget to check if the original or baked material is of type multi-material and handle it accordingly. Another issue I *sometimes* have is with special German characters like öäü. Unity sometimes replaces those upon import with some other symbols and may therefore break your postprocessor scripts when they will look for the lightmap textures. I created two more custom maxscripts that check and replaces those characters in material and texture names. (For object names it would be good, too, I guess). As a little hint, in order to access easily all bitmap-materials inside 3ds max you can use the following maxscript snippet:

local maps = getClassInstances bitmaptexture

Using enumerateFiles or usedMaps() only gives you strings and might turn things more complicated. As some of our meshes use Vertex Colors, I check that too and tag material then with __lmc__ instead of __lm__. To detect the use of vertex colors you can do the following

local tmesh = snapshotAsMesh myObjectNode
if ( getNumCPVVerts tmesh > 0 ) then

Using AssetPostprocessor …

There are several types of asset postprocessors. To create one, you have to place/create your script inside a project folder called "Editor". It's not created by default, so create one if you can't find it. Using Javascript you usually start like this

class AssetPost_ShadersByPostfix extends AssetPostprocessor
{    …

and then you implement a static function depending into which kind of event you want to hook into.

OnAssignMaterialModel gets triggered each time a material has to be imported. In this callback you have the control if, where and how you create the new material. If you organize your project in a way that you cluster all materials in specific directories rather to have them close to the geometry assets, then this works fine. Otherwise this isn't the best callback to use as you don't get any hint where, inside the project directory hierarchy, the imported FBX is. Usually on FBX import a "Materials" folder is created on the same level, something you can't do easily with OnAssignMaterialModel. Alternatively you can use

OnPostprocessAllAssets: The benefit of this callback hook is, that the assets creation is automatically done for you and you get the target directory paths as array. To detect materials you can simply do something like this

        for (var aFile: String in importedAssets)
        {
            // identify materials by .mat extension
            if( aFile.ToLower().EndsWith(".mat") )
            {
               …

This works pretty good. But also with this there is a scenario where it's not the best fit. If you use the FBX exporter option "embed Media" that includes all textures inside the FBX file, then it does not import the lightmap textures during the first import/refresh activation. They get imported if you do a refresh or if you switch to another app and back. As result, your OnPostprocessorAllAssets may not find the lightmap textures because it's called during the first run, when the materials are created (and only diffuse textures get imported) and the lightmaps are added in the second run to the project.

So what I do is calling manually a custom ScriptableWizard inside Unity after import. It's therefore not totally automatic, but quite robust and only something like 3 clicks.

Somehow I miss some built-in functionality to deal with project things inside Unity but you can parse through all material assets inside your project using standard DotNet, like this

import System;
import System.IO;
…
var matFiles : String[] = Directory.GetFiles(Application.dataPath, "*.mat", SearchOption.AllDirectories);
…
for(var aMatFile : String in matFiles)
{     …

The rest is quite straight forward: the Wizard iterates through all project materials, checks if they contain any shader tags in their names, assigns the corresponding shader, extracts the lightmap texture name, finds the texture and assigns it as second texture to the shader.

Well, that's it. I hope this helps you to setup a better pipeline for importing assets with lightmaps from 3ds max. Of course the key concept can be used for anything else too! 

Last week I posted part 1 where I talked about Shaders, Lua and Blendshapes. I'd like to add to the LUA subject, as it seems to be a commonly asked question, that there are no additional tools in the SDK to deal with custom LUA bindings. The docs suggest to use available solutions.

3D Compass

The 3D Compass is a translation handle/gizmo like many of us know it from other DCC (Digital Content Creation) tools like 3ds max or Maya. The good thing is, that it includes handles for translations on planes too (unlike Maya or Unity3D). I really miss them in tools that only provide translations along one axis.

If you look at edges of the pane-translation handles, you will notice an additional arc. These can be used for rotations. I like this solutions, a good enhancement! The yellow pivot does not do a 3-axis translation (I never liked those!) but uniform scaling. This also is a good approach. So overall it's a bit like a universal transformation handle. Therefore there is no variation for rotation-only or scale-only modes. Which means - unless I overlooked it - there is no way to use the 3d compass to do a non-uniform scaling.

Another good addition is the ability to clone easily the selection by holding SHIFT while translating. It does a duplication with few dependencies - the 3d entities get cloned with attributes but not the mesh etc. Good for building content/levels.

The 3D Compass works with the available coordinate systems: local, global, view, parent. (About the ref. guide I am not sure). Something that didn't work yet was the angle snapping when using the rotation handles, but maybe that was fixed for the final release. If not, use the old method. Something that wasn't yet possible too, is the ability to show/hide the 3D compass as in some situations it might be disturbing.

Enhanced Content Protection

VSL code and Shader code can now be encrypted and therefore shared without knowledge transfer. This allows to create a more solid commercial environment for 3rd party component developers and freelancers/consultants.

The password can be specified in the variable manager. Having the correct password allows to decrypt (unprotect) the content. I don't know how solid this is but at least it's one more level of obfuscation and should be good enough for most cases.

For some unknown reason are LUA scripts excluded from this protection scheme. Another problem is, that you can't select multiple items in the editors and un-/protect them all in one go. While the Shader Editor handles at least the first selected item, the VSL Editor just doesn't react. So going one-by-one is not very effective, when dealing with more complex content.

New Building Blocks

XML: When Dassault Systemes added XML BuildingBlocks to Virtools 4.0 but restricted them for deployments for VR/XE/Office players I thought "Oh my!". I mean, if you want to create some interesting online content XML as document-format standard is just omni present. For example WebServices. Looks like Dassault Systemes finally became aware of this and now the XML BBs can be used for Webplayer projects too. Personally, I've only tried to use them once under 4.0. They didn't seem to be very stable  (which might have changed in meanwhile) and I ended by dropping them in favor of a custom VSL solution. Anyways, it's still a good addition that should have been done much earlier.

Thus from now on, they can be found under Narratives/XML Parser. The good thing is, that it can be used via VSL too. Moreover there is a visual XML Debugger window. The documentation could be better, I think, especially as the usage is not always totally clear - for example "XML Load Document" may fail but without any hints why.

Content Processing: I couple of new, useful BBs for examining and processing content: Merge Materials and Merge Textures (to find duplicated/identicals inside a group), Hierarchy Parser Upwards, Dependency Parser , Is Child Of 2D/3D (checks the entire hierarchy upwards)

Camera Movement: Pick And Pan BB, Pick And Rotate, Camera Zoom Extend

The basic idea of BBs for common operations, especially for configurators and the like, is nice. The execution of that idea is "suboptimal". First of all in the beta version the Pick BBs ignore a 2D hit. This means that while a user interacts with the GUI, he might modify 3D content that is hidden behind the GUI without intention. A developer would thus manually check for a 2D hit and deactivate the behaviour, making the "out-of-the-box" idea less effective (less fast ). The pick and rotate BB rotates a picked object along all 3 axis. No idea where this is useful, because reorienting an object towards a desired orientation is very hard to achieve this way, I think. It would be more universal (= fits to more use-cases) if it has options to constrain it to one axis.

Is Key Down BB:  LOL, finally! No more to say about that I guess everybody had their own custom solution for that (i.e. via VSL )

Set World size BB: resizing a 3D entity by giving the desired world size.

Spherical/Cartesian coordinates converters: the spherical coordinate consists of a vertical Angle, a horizontal Angle and a distance value. It sounds interesting and I wonder for what user-scenario these have been designed … GeoInformation systems? It also sounds like that we could simulate the content in 2D and display it on a spherical surface i.e. pathfinding and move-to, using the built-in solutions which might be difficult otherwise. Here two images from the Virtools documentation showing the coordinate systems:

2D Texel = Screen Pixel BB: this BB adjusts UV coords of 2D entites to fit texel/screen pixel ratio, a bit like screen mapping. The docs says "This is particularly useful to ensure sharp 2D GUI display by avoiding resizing artefacts".

To be continued …

Ok, I think we covered the major new features so far. In the 3rd part there will be some more and a final conclusion.