The model / painting / material editing documention in Modo is really terrible. Where is the section on Materials? I must be missing something. Dragging/dropping materials seems to work, but assigning an image map to a material (such a basic operation) is eluding me.

Ok, apparently I need to assign Material Groups, not Materials, to individual items. Then all the functionality that's described in the tutorials will work. Sheesh. I must be missing an entire section somewhere on how material groups work. It's not anywhere in the documentation, mentioned only in passing. Grr. Downloading some video tutorials that I hadn't seen before...

Now I can't for the life of me figure out how to make Modo SAVE the painted texture. This is ludicrous.

Ah, you right-click the image when in Paint mode, and choose "save". It wasn't working before because it wasn't attached to a Material Group. I think.

I am starting to think that the UV Painting is a little buggy, or there are dependencies on the painting module. For example, I added a SECOND image map and second UV map, and applied it only to one face, but I couldn't paint on it though I could see what I'd put on it. Reapplying the UVs seemed to fix it, but I'm not sure what gives.

Anyway, I now have a texture-mapped cube that mostly looks like I made it that one on purpose. Now, to export it as FBX and see what is actually in the file.

EXPORTING...

FILE->MENU->Export As... FBX. The exporter complains that it can't guarantee accuracy with complex Modo texture mapping. Doh. We'll see.

Now let's see what's in the FBX file. Hmm, it is not XML, but a binary file format.

Well, let's try loading it into FX Composer and see what we can find out about the format.

• Created a new project in FXC2
• Project->Import Geometry
• Loaded my FBX file (it also will handle Wavefront OBJ and 3DS formats)
• Told it not to import cameras or lights, but do import materials

At first, the model didn't appear, but I noticed that its TRANSPARENCY in the "Parameters Common Profile" was set to 0. I set it to 1, and it appeared. This is a crappy name...if transparency is 1, shouldn't it be fully transparent? Transparency 0 should imply opaque. Hmm.

Anyway, upon viewing the model, I can see it brought in the diffuse color correctly, but I saw no references to texture maps or UVs anywhere. Hm. Some searching of the luxology forums seemed to indicate that certain things must be selected before exporting.

So I went back into Modo, and selected the item AND the materials AND the UVMaps before choosing EXPORT AS. I also exported as WaveFront OBJ too, since FX Composer can load that as well.

Reimporting the FBX file:

• I did see ONE of the textures, but it wasn't mapped
• the emission color was not there
• transparency was again set to 0, so I changed it to 1
• Diffuse Color setting allowed me to set the image. However, it drew completely messed up.

Importing the OBJ file:

• material Diffuse color imported correctly
• No texture
• FXC2 crashed when I attempted to delete the other object. So I restarted FXC2, and same issue. Hmm. It doesn't like loading multiple projects...CRASH CRASH CRASH

Ok, trying FBX export variations:

• manual select all materials in the shader tree, all UV maps in the UV list --> black box, no images loaded
• man select only cube material group, and simpleCubeDif1 and SimpleCubeMat, also only one UV map --> image map loads, but diffuse color does not.

I then tried importing some .X files that I know work just to see how FXC2 looks at them. It loads several map instances as diffuse maps.

I am coming to the conclusion that Modo's FBX and OBJ export are broken for the way I've set up materials. In other words, Material Groups are probably not supported (this might explain the cryptic warning that Modo issues regarding FBX export with "complex" modo mapping). Sigh.

This fellow on luxology's forums went through the research as well, and posted his findings:

• no alpha in the PNG...use RGB, not RGBA
• one UV map in the scene, or one UV map per meshpart

What I could use is an FBX decoder or utility to see just what's going on. This is an Autodesk-supported format now (was Alias), and they have several tools available. I am downloading the SDK, the QuickTime viewer, and the Converter.

Sitting back and contemplating this workflow problem (and importing is ALWAYS a problem in 3D)...

• There is an FBX to other format converter from Autodesk.
• Looking at the FBX files in the Autodesk Quicktime viwer shows UVs mapped, but no textures loaded
• There is a Collada exporter script for Modo which is supposed to be quite compliant. Can possibly use the FBX Convert to convert from Collada to FBX, and see if THAT works.

Also, I should try exporting a simpler model than my "beveled cube" one, because this might make for easier-to-debug UVs.

After sleeping on this, I think I actually do need to derive my own workflow tools. The problem can be summarized as follows:

1. Exporting vertices and associated UV maps
2. Exporting materials (overall surface light reflection properties)
3. Exporting texture maps with associated UV map (diffuse, normal, specular, etc)

The two 3d formats that XNA will read as-is are FBX and X format. The FBX importer doesn't work with some mapping features.

The formats that Modo will export natively are FBX (which doesn't work too well with textures), Wavefront OBJ, and I think Lightwave LWO. Each of these exporters has some weakness that requires Modo models be built a certain way.

An intermediate format with promise is using Collada. There is a third party LUA script for Modo that will export Collada 1.4.3 compliant XML (allegedly tested). Since it is XML, it's human readable and parsable. We might need to modify the script to export texture map information as well.

There is a script on the Collada forums that implemented Collada parsing for an XNA workflow. It is written in C# and I will have to check it out.

Here I am in San Jose working on-site with the rest of the team, and I'm taking a step back and not worrying about model import at the moment, because we need to really just hook up the projector system. I'm writing an "Entity" class which just draws cubes, using BasicEffect. I'm pulling bits of code out of the example to make my Entity class, which is just a placeholder.

It's been a while since I updated. I hacked together an application that draw cubes by generating its own list of vertices, and it now talks (or rather, listens) to another server that feeds it entity position information, so yay...finally, some system-level progress.

I have been having some key insights into the XNA learning process:

• It really all boils down to vertex management, shader programming, and videocard memory resource management. The various example demo and tutorials I've read all are about recipes, not principles. Once I realized that I should focus on where vertices and shaders came into play in each example (and this took some digging, because a lot of the intro tutorials gloss over this), things started to make sense. I even started to catch what I think were bugs in the tutorial examples that missed some crucial point.

• The Great Missing Link in XNA documentation is the complete lack of hyperlinks to the data structure classes. This is where the "last mile" of understanding is buried. I spent many an hour cruising the online documentation in search of insight, furtively clicking on every hyperlink I saw. When I finally started to iterate through the entire class library, I noted the importance (and lack of emphasis) on the data structure links. The documentation generally doesn't link to or explain the data structures returned by the classes, which enumerate a lot of XNA details that are important in developing an understanding. A typical example that comes to mind is VertexDeclaration, which I couldn't figure out from the uselessly terse description given: "Gets the vertex declaration for this model mesh part." But I want to KNOW what a VertexDeclaration is, and WTF it's used for! There is no link to the critical VertexDeclaration class, which is also terse and useless in explanation until you start digging around the unlinked VertexElement class. And so it goes, making the documentation fairly useless except as a syntax reference.

• Shaders Shaders Shaders. The way to think about them is as specialized rendering commands. In the old fixed-function pipeline, we would think in terms of providing a "rendering engine" with polygon lists, textures and texture coordinates in some kind of data structure, then calling a Render() function. In the New Way, you pass parameters to a shader, which is basically a program that runs on the graphic card, and is ultimately invoked through a DrawPrimitives() call of some kind. This is hidden to some extent due to the prevalence of BasicEffect, which is a built-in shader that provides some "getting started" features for new XNA developers. What would also be useful is the source code for BasicEffect, which must be implemented as a shader somewhere.

• Multiple Materials. You basically implement a shader for each kind of effect you want. This includes texturing, drawing metal, etc. Tutorials do not offer extended examples of drawing multi-texture objects, but the basic idea is that you separate your model into several submeshes that all share the same effect, which is basically a wrapper for the shader code that runs on the video card's GPU. Before you draw each mesh, you select which shader to make active. The provided Model class provides functionality for this, but this presumes that the Effects have been set for each submesh.

Continuing on...

• Shader Language. This is less mysterious than I thought; it's just that the reputation of shaders being "difficult" makes people write about them in a round-about way. A shader is basically a C-like program that implements a subset of useful 3D and 2D mathematical operations that in the past you used to have to write from scratch. In that sense, it's actually a huge leg up, basically a scripting language for 3D transformation, projection, and rendering. You do need to understand the basics of the math, though, and understand some of the built-ins like texture sampler. The semantics of things like TEXCOORD and so forth are not well explained either, but I think trying to find documentation on the HLSL compiler itself might illuminate.

• Importing Models. We finally got SOMETHING imported from Modo, a simple texture-mapped cube. I was resigned to the idea of extending an importer based on Collada, but someone wrote a post about exporting to FBX: how textures needed to be in RGB, not RGBA format (that suddenly explained the zebra-striping I was seeing), and to avoid multiple texturing and UVs. This is a start. Assigning effects to specific submeshes is something to look into, and will still probably require a custom importer. Seeing what is coming out in the FBX using the Autodesk FBX SDK utilities might help debug this.

• Modo. I also finally understand the shader tree in Modo, which isn't described in the provided user documentation at all. Big hint: use their context sensitive help to click on commands on the screen, and you will likely get a useful tutorial that will explain how things work. I also was clued in by my realignment of understanding of shaders relating to meshes; Modo works the same way.

I don't know how I missed Building a 3D game from scratch, but thanks to Ben for pointing it out.