Maya -> DIF

#1 I don't use Maya or Milkshape but ...

There are a few issues with exporting meshes into map files through 3rd part programs. I've been testing building interiors in Blender, exporting as a .map from Blender, and then importing to Constructor. Here's a few tips that I found the hard way.

1. Build like a BSP for ease. Make brush style meshes and place them together like bricks. If you build a standard mesh style model and then convert the faces to brushes in the map exporter, it tends to goes wonky, hideously wonky.

2. Constructor likes the geometry scale at 32, so export your .map at 32. This gives a much greater chance of getting all of your brushes into constructor alive and avoids "cannot load # brushes because they are deformed".

3. Having brushes angled at both XY and then Z is asking for trouble. If you want a curving slope, do it in Constructor using the slice tool.

Doesn't Maya have a "Quake .map" exporter plugin? You do seem to be using multiple 3rd party tools which just amplifies the possiblities of cock-ups amongst multi-conversion/exporting.

Static shapes don't get converted to DIF in Constructor, they're still static shapes and don't have collision. If you want collision, cover them in a collision brush. Needless to say, I don't use them like this at all.

(rhetorical) What the hell is an FBX format?

#2 Interiors aren't supposed to be created with Maya. Period. Even if you do get it working, you'll have a terribly optimized DIF, since polysoup-to-MAP converters usually just replicate the triangles using tetrahedrons, since CSG is based around convex shapes, not polygons.

Either build the shape you want in entirely Constructor, or make a mix of Constructor solids/collisions and static shapes (which is how most things are done in Unreal and Source).

#3 No offense, but why on God's green earth are you even trying what your trying? If you want to make dif's, use contructor, or Radiant, or Quark etc. You can make interiors with Maya, but not in dif format.. that would defeat the purpose of using it.

Make your interiors through dif using one of the programs above (exported through constructor). Then through some combination of your choosing, fill them with detail (either through contruction in the dif format, or through map objects through maya).

#4 Yeah, any modeling tool is a poor choice for CSG -> BSP type structures. There is a totally different mindset for modeling and "constructing", the two are totally different beasts.

The fact that your static shape was deformed after being imported into and then out of Milkshape and then embedded in Constructor leads me to think there was something wrong with the model or the import/export process. Anyway, doesn't Maya have a .dts exporter? EDIT: yes it does, very first link under exporters.

I've embedded lot's of .dts shapes in a .dif with few problems, and also had collision with them... most of the time.

#5 Thank you for your answers.

First of all: I and my team are new to Torque. We choose this engine because of its amazing capabilities, but we're still finding things out (the hard way...)

We're kind of on a limited time (its for college and we've got 7 weeks left) and Constructor is so... I can't even start to describe how slow and hideous it is. So the learning curve of new tools apart from Maya is preferably avoided as you can possibly understand. We didn't realize that we had to create DIF files and we sure as hell didn't realize that we had to create them outside of Maya. Our visual artists like working in Maya because it allows us to create high quality geometry. Is that same level of quality available in Constructor or any other MAP/DIF/BSP editor? I believe it is, but its more work, right?

To give an impression of what we're trying to make, here are some fryrenders of our current scene in Maya (with different lighting):
http://i43.tinypic.com/2hmm3pv.jpg
http://i42.tinypic.com/2vw7eqt.jpg
http://i40.tinypic.com/hx3hx2.jpg



@Michael Hall: The model itself had indeed an error in it. It appeared to be completely clean in Maya and Milkshape, however when imported as a DTS model, somethings went horribly wrong.

@Steve: The FBX format is a generic ASCII format, kinda like the XML under the model tools, everything can read it.



Again, thank you for your advice. We did find out that having a TStatic with a seperate collision mesh that didn't have any concave shapes works just fine and just using "usePolysoup = 1" and a greater margin and bodyRestitution of the shapes did work.

We were, however, stuck with cameras going outside of the static shape unfortunately, but I'm sure there's a resource available for it.

#6 For that type of scene your best bet within your constraints may be to create the rooms (walls, etc) and any other obviously convex objects with Constructor or similar tool, and then add the other objects (desks, chairs, etc) as static DTS objects (either in Constructor or in the world editor). If you want to work in Maya you may have better luck just outputing only the walls and such as a .MAP and then exporting the chairs and such separately as DTS. Trying to output the complex stuff in .MAP format is definitely a no-go though.

#7 Correct me if I'm wrong but, I can't remember the Half-Life tools having these limitations... why does Torque have them? Is there a reason for this design?

#8 Which limitations in particular? I'm pretty sure you couldn't just export a polygon modeled scene from Maya to Half-Life and expect flawless results, since they used brush-based BSP interiors too. Mostly you used their editor, which was similar to Constructor, though quite a bit more polished.

#9 Gerald is right. Half-life and all Source games use WorldCraft for level building and you import polysoup models as entities and place them over the BSP structures. I believe It doesn't even support lightmaps on the meshes, using per-vertex colors instead.

#10 Hmm.. I still find it unbelievable that an engine so capable of achieving near Unreal 3 graphics, with a netcode that kicks so much ass... and yet they use this 15 year old technology with these kind of limitations.

#11 @Eric den Boer: It's not unbelievable. Unreal 3 itself uses the same 15 years old technology with the same kind of limitations. Just load Unreal Editor (comes included with UT3) and look for yourself.

#12 Oh it's very believable, a lot of games out there today still rely on those old BSP optimizations, it's only recently that we're seeing the switch towards polysoup, or an all mesh approach instead of Constructive Solid Geometry.

#13 Actually Unreal 3 mostly uses mesh levels with separate collision volumes, the CSG editor is just for roughing out the initial level layout and is what's shipped with the game for modding.

However, a polysoup-based interior system is something that is not easy to generalize across many types of modeling packages. They would really have to focus on one or two modeling packages in order to create something like that, and choosing which ones would invariably piss off half of the users :P

But maybe now that they have Collada support they can get around to coming up with a better interior system.

#14 @Michael: to be fair, there always have been games with mesh approaches, specially on old consoles. But were always very game-specific when it came to handling collision and culling/zoning.

@Gerald: the main problem is the pipeline for laying out zones/portals and the PVS calculation. With the advent of vertex buffers, the actual rendering of BSP and mesh structures became very similar.

Since the Collada support will include lightmap-importing capabilities, people can happily go on in making their full DTS levels, until they come back to the forums asking why their GTA-like cities are so slow.

#15 @Manoel, indeed that is the big problem.

Another issue with using DTS is the limited collision volume support. Straight polysoup collision with the current collision implementation will result in a lot of players getting stuck on edges :P

#16 This is very educational :)

So has anyone ever written another interior system for Torque? Or has anyone just given up and used BSP?

Btw, right now we're using a basic TStatic, with a basic collision mesh and adding detail to that as a room, while having the basic collision mesh from the basic shape. This seems to be working just fine in our first testing mockups.

#17 I made a custom interior system for TGEA. It's primarily focused on 3DS Max though, since it makes use of light maps baked from the modeling package, and the Maya light map baking is hideous.

#18 @Gerald: lol, I did something similar too, long time ago. It loaded Gile[s] files, then later I changed it to use FBX files (focused on Maya, but using Turtle for lightmap baking instead, also supported baked-vertex colors instead of lightmaps).

It had better sub-mesh culling than TSStatics (using r-trees), but only the Gile[s] version had zones/portals (hand-placed and riddled with constraints). Shipped some commercial products using it (the last one using TGEA 1.7.1).

I always entertained the idea of releasing it as a resource, but it requires a large amount of work to become as general purpose as Interiors. Every project I used it on had game-specific tweaks added, both on the renderer, collision and even on the ShaderGen. As example, normal-lightmap generation was never done properly, it doesn't work with the in-engine scene relight and the pipeline for lightmap generation is much more convoluted and error-prone than a DIF's.

#19 Yeah that's why I basically tied my system to Max. I made a number of plugins for Max to make it as painless as possible, including material plugins and exporter plugins that do all of the UV unwrapping and lightmap rendering automatically on export. It requires setting up the sun light in the same way it is in the mission for exterior lighting, though, so I added a light plugin too that allows you to setup the sun identically with how it's setup in the mission file. I never bothered trying to tie it into the Torque scene relighting except for having it cast shadows on the terrain during relight.

Within those minimal constraints it works very well and is quite flexible. The material plugin allows the artists to do all of the material tweaking in Max and it's pretty much what you see is what you get, including a number of special effects and post processing effects.

Since the built-in light managers only support up to 2 lights and mainly just directional lights, I implemented a custom light manager as well, so I can use up to 4 lights of any type on each render instance for the dynamic lighting that compliments the static lighting (for specular highlights, normal mapping, etc), plus the 2 additional dynamic lights for the dynamic volume lighting.

Maybe with T3D we can get full dynamic lighting and shadows and eschew much of the pre-rendered lighting, though I think we're still going to be a ways from having the dynamic shadows match the quality of nice baked shadows.

#20 Seems you went a lot more into the pipeline than me. When I moved the codebase to TGEA 1.4 (which had lighting and batching) I just ditched my custom render path and uploaded my render instances to the Interior render manager, which drastically simplified my own code with little changes to the existing codebase (needed to add lightmap support on the translucent render manager and a few changes for the vertex color baking - crucial for my projects).

With T3D and Collada I take it we can get away by having dynamic shadows and pre-baked occlusion (which are much easier to bake than full lightmaps) as a fallback/compliment for the SSAO (which doesn't work for large area occlusions).