FBX shenanigans.

#1 If you convert the FBX to DTS, you lose all advantages of using FBX in the first place, unless you're working with a modeling program that supports FBX but doesn't support DTS.

It was said that, internally, the DTS format does store multiple UVs, but none of the exporters support writing those UVs out, so you could take advantage of that.

#2 Definately sounds like a good idea Phil, keep us updated on the progress as this is definately something that could benefit us all.

Also as a FYI last I heard was that a bunch of the options in Collada are based on Filmbox. There is also some interesting work coming through with Collada for Physics and Shaders. The jist of is that it would store the physics or shader data in their own intermediary format that could then be loaded by the game engine and used in whatever solution you have (ie. Physx or Havok for physics).

Logan

#3 Manoel, there's nothing to say I cant extend the DTS format a little bit. Especially in terms of multiple UV sets etc.

the thing is this really:

Do we have an external (probably command line) app that takes an input fbx and writes an output dts, then add that as an external build step (possible have a recursive option that automatically checks and generates ALL dts's from thier same fbx's and recurses down the directory tree.

Or

Do we have some code in the engine that allows creation of a tsMesh from whatever file format (a mesh factory class and associated readers).

OR

Both :)

Seriously though, this definitely seems doable and I'm up for doing it because I think its worthwhile, I just need to think it through as to the options and I would prefer to get others feedback.

Logan: There is a collada reader in the fbx sdk, there are also .obj, .3ds and .fbx (naturally) so we should be able to handle at least those formats with this.

I'm thinking of writing code that will be extensible with other format readers (and might implement halflife .mdl format myself) because I've wanted that for ages.

I think I'll start off with a converter app, to prove that I can actually generate a valid dts file.

#4 That sounds awesome Phil :) I'm not an artist but I see complaints (both on these forums and others) about the lack of good importing tools for torque.

#5 Phil, you can do both, but linking the FBX SDK to Torque adds almost 3MBs to the .EXE size. You also need to do a small change of unknown consequences to get it to work (I didn't have any problems with it yet, but I need to stress test the engine further to see if there are leaks or other similar stuff going on).

The external tool solution may be a cleaner way to do it, since all you need is to add support for your DTS extensions to Torque. You could have a script execute the tool for generating the DTS files during load time (and you could safely remove it along with the FBX, collada or other source art files for shipping builds).

#6 Manoel: I didnt think about the exe size, but youre right, it would bloat the exe a bit.

I will write the converter app first because its an easier thing to do and will prove the concept (that you can convert from those formats into dts.

I might even go a teeny tiny bit further and add a .net interface to it at some point too so it can be sold as a product.

There should be a number of advantages to doing it this way I think. One thing I wanted to add was auto-generation of convex hulls (col meshes for instance).

I also prefer to have seperate files for each LOD for a shape, so maybe I'll incorporate that kind of functionality into the app (so for instance, instead of a fairly convoluted export process where you have to link things into a scenegraph for the exporter to understand it, we build it from individual meshes, such that the mesh naming convention signifies the level of detail for that mesh.

Imagine a situation where you want 4 LOD's for a given mesh. You would simply save out:

Tank_LOD1
Tank_LOD64
Tank_LOD128
Tank_LOD256

and the app would create a Tank dts with 4 LOD's and an automatically generated convex hull for COL and LOSCOL (with appropriate switches set).

Thats the thinking anyway. I'll post some initial thoughts about the architecture and maybe a UML diagram sometime soon.

#7 Hey Phil, for the unenlightened of us out here, could you explain the ultimate goal/benefits of this change?

#8 The main thing from my point of view Mark, is that I wanted to experiment with some baked lightmaps in a few different projects. Looking at the DTS code as it is, there isnt support for multiple UV sets.

Now Matt has changed the code to allow Multiple UV sets, but the current exporters dont support the exporting of that data, so basically there is a disconnect there.

I'm of the opinion that exporters in general are a pain to manage, because as software changes and new versions come out, trying to maintain exporters across them becomes unbearable for a small company. So I've been looking for "standards" based formats with wide support to use as the basis of asset management for my own games.

That said, there really isnt a single solution, but its pretty clear to me that a good first-pass attempt would be to use what is, as far as I can gather, as close to a useful standard as possible (FBX) and has the incidental advantage that it also supports .obj, .3ds and collada .dae formats.

So the point being, that some work now in moving from an EXPORT based pipeline to an IMPORT based pipeline I think will payoff in terms of flexibility. In essence, we move from spending time updating exporters for the myriad platforms, to adding importers for the myriad file formats. File formats change far less frequently than products, plus we can live with a smaller subset of file formats than we can exporters AND have the added advantage of being flexibly able to extend features where the file format allows.

Let me give you a concrete example or two.

Right now, there is no option to have a mesh with baked in vertex colouring. If I wanted to add it, I would add that support into the engine, then have to write an exporter to support that, for EVERY peice of software that is Torque supported. With my proposal, we can add the feature into the mesh system and then write some code for the import process that allows the various file formats (where this feature is supported in the file format) to access that functionality.

Similarly multiple UV sets for baked in lighting

But outside of that, having a pipeline that can be extended and "plugged into" would allow for a number of alternatives in terms of automatically generating representations.

So for example, I could actually extend the pipeline to support automatic generation of pathing information, or automatic resampling of mesh data (for instance, I could add an automatic mesh reduction facility into the pipeline) or even automatically reducing texture sizes.

The point being, I think right now, the amount of maintenance of the content pipeline and how it functions is beyond GG or anyone else. I think that is a by product of the exporter centric model.

That said, I'm willing to be shot down here.

So to answer to your question, the ultimate goal, is to be able to easily add features to the 3d content pipeline that arent easily incorporated right now, plus to maybe help make the pipeline actually easier for artists to grasp and to allow more tools to be used by incorporating more file formats into the pipeline.

So for example, a user would be able to incorporate .3ds models in thier app, which wouldnt require "rigging" or "exporting" in order to get a basic mesh into a game. Similarly any other of the file formats supported. If the user had a more complex situation, such as boned meshes or morph meshes, they would be able to write to a more useful application native format. Thus the asset isnt a one-way street, it could be tweaked and shared in its native format.

#9 Your idea is awesome, and it looks to be the better solution for the eternal problem of extending the DTS format, by eliminating the need to update exporters for the new features.

You're actually onto a very modern trend in game development pipelines. Importer-based approaches, which move the knowledge of the final asset format away from the artists' end is arguably the way things are moving to in the industry.

Like you said, it also allows you to do a myriad of extra processes to the art assets which would be unfeasible to be done by simple exporters.

As another example, using an importer would allow the transparent integration of texture atlases creation to the pipeline, with little to no artist intervention required, keeping them free to worry about producing quality assets instead.

I've been working with FBX on Torque myself for quite a few months already, but for different purposes (polysoup-based interior replacement), so if you have any questions or need some help in using the FBX SDK to actually load files, fell free to drop me a note.

#10 Thanks Manoel,

The FBX SDK is actually reasonably easy to understand, if a little class heavy for my liking. Hopefully I should be able to get the basic static mesh to dts thing done reasonbly quickly and work from there.

I'll let you know if I need any help though for sure.

Incidentally, I've been looking at using Maya and Turtle to bake lightmaps off. I've also been looking at using Gelato, but I'm not sure that will be as useful.

Anyhoo, on with the work I guess.

#11 We are currently using Turtle in extended experimental phase here at work. I also did a few quick tests with Gelato, but ran into a few very annoying quirks (but I plan to re-evaluate it in the near future).

The biggest plus in Turtle (when compared to mental ray baking) is the ambient occlusion rendering. While not as physically accurate as doing a full blown global illumination render, it's much faster to render and can produce very pleasant and consistent results much quicker, since it doesn't depend on lights and requires less tweaking.
(The surface transfer feature is also very easy to use and is fantastic for creating LOD models).

But one problem still remains: generating the lightmap UV coordinates. I couldn't find a good solution dedicated to that. Right now the best we can do is use the automatic UV from Maya (they finally fixed it and it works on multiple models in 8.5), and do some tweaking using the Layout UVs option.

#12 Another option I was going to look at was sunflare, which has the added bonus of being open source.

Yeah, I liked the ambient occlusion option too, seems to be quite GI like in visual property, without actually BEING GI, plus, seems like its easier to setup :)

At some point I'm going to get my MSc students to write an ambient occlusion lightmap generator for kicks :)

Turtle has one major drawback for me. Its DAMN expensive.

#13 Incidentally, that was one of the things I used to talk to Jay Stelly over at valve about (I was writing a halflife renderer). Basically, they project the coordinates onto major axes and map the UV coordinates from that axis. So essentially lumel space is interpolated across the major axis that the plane being mapped sits on. I guess the boundary conditions arent so bad.

So basically, you find the closest major axis plane that matches the plane of the triangle you are mapping. You generate UV space (packed) for that major axis such that the space is optimised for triangle sized patches (I recall being something like 16x16 chunks, but that might be wrong). That way, for any given surface, all of the triangles that lie on the plane are mapped to the same major axis and thus to the same texture page.

At least, thats how I remember it, its likely to be completely wrong, but I do recall spending ages trying to reverse engineer thier radiosity lightmapper before breaking down and sheepishly asking jay about some code :) luckily he was a nice guy and was forthcoming with an answer.

Oh, I just remember, during the projection onto the major axis plane, each areae was projected into the plane and its surface area checked, if the surface area was > some delta, it was then split into smaller areas and checked again, doing it recursively until the entire surface was coverable by surface patches. This meant that the overall texture UV space had a certain lumel coverage (essentially making the UV space<-> Lumel mapping uniform as near as dammit).

Ahh, good times.

#14 Ok, I understand what you're doing now Phil. You call it an "Importer" but as I think about it, the name is just semantics. Essentially what you seem to be writing is an "exporter" that is built into Torque that uses already standardized file formats, rather than program native formats. However, since it's working from the end-product line "importer" is a more appropriate name.

Question #2: what should I be reading/researching to start understanding what you're talking about for your post above? I believe my Engineering degree has given me a good base level of knowledge but I need to find sources of good explanation of game technology theory. Got any good books to recommend?

#15 Mark, I use the term "importer" because you "import" files from the native application format INTO torque. The areas where I used the term "exporter" are where I'm talking about the plugins you use for max, maya, milkshape and "export" from the application into .dts format.

In terms of understanding game content pipelines, perhaps the best place to start is www.gamasutra.com as it has a few articles about how other developers setup thiers.

If you mean about the lightmap generation and UV space stuff. Hmm, not entirely sure about that. I've been looking at these things for nigh on 20 years, so the sources all kind of blur together. I learnt about lightmapping and lightmap baking and texture spacing from writing (and reverse engineering) a halflife compatible renderer in OpenGL. Basically, if you look at the Halflife SDK (not the SOURCE version, the older halflife 1 version), you can get a feel for the kind of issues involved with that.

I guess the easiest way to get a feel for it, is to try it. Try making some meshes and baking lighting into them. Try then thinking about how you would get that information into a game engine and rendering properly. Break it down into the steps required and then research each step seperately (youre likely to find sources easier for each individual step).

#16 I wish you luck in this endeavor, Phil. If you pull it off you will instantly be every torque user's hero. It would be the holy grail for the notorious torque art pipeline.

#17 Thanks Jacobin, although I really dont think its that big a deal. I do hope that it makes it easier for artists to get something into the game though.