Writing 3dsmax export for interiors (dif / map)

#1 I'm not sure that your endevor is entirely sane. The interiors are based on CSG brushes. That is why Quark etc is used to edit MAP files which are then converted to DIF files.

Max/Maya etc are all polygon/NURBS etc based modelers.

#2 I'd definitely stay away from this, CSG tools are great for CSG and poly tools are great for poly, but don't try to force one to do the job of the other...

#3 I'm certain it's not *entirely* sane, but neither is attempting to use TSE (in it's current state) in an ambitious production with tight deadlines ;) Nothing against TSE, it's simply unfinished. I've already resigned myself to the necessity of getting my hands dirty, and this won't be the half of it.

It also seems of questionable sanity to attempt to model anything of high complexity in Quark. We gave it a valiant effort, but Quark is choking.

I'm fully aware of the distinction between between CSG and triangle soup. However, the only strong requirement of map files (as far as I can tell) is the convexity of each brush. A set of convex brushes can be generated from a triangle soup via a bsp composition. That part of it really isn't very hard. I've done it before. Coplanar faces in the same brush have to be addressed, but that issue isn't a deal-breaker. Is there another more subtle issue lurking here that I've overlooked?

Can anyone address my original questions more directly? Has anyone else tread similar ground?

Is the .dif format sufficiently cryptic to make it avoidable at all costs? From my cursory examination of Interior::read(), it really doesn't seem that way.

For the export to .map option, is the current map2dif truly hopeless, or can it be fairly quickly fixed? Our braindead effort last night to fix it was partially successful, but not totally. The 32-vert problem seems to have been eliminated but the output is still not perfect.

At this point I'm leaning towards exporting to .map and writing map2dif from scratch. The advantage of this approach is that it's not much harder than exporting directly to .dif, and is verifyable at two smaller stages. After spending a little time with the current map2dif source I'm not sure it's worthy of salvage.

Constructive ideas would be very greatly appreciated.

Thanks again.

#4 1) Upping the 32-vert limit is trivial (simply an array). However, the more you up it, the more dangerous ground you tread when generating triangles by clipping the convex brushes' planes together. A brush that generates more than 32 sides per polygon can take a *long* time to run this clipping pass. In my experience upping this limit has only led to bad things. However, feel free to try =)

2) The .dif format isn't complex...there is just a *lot* to it. Glancing through read/write it doesn't look too bad until you realize that a lot of those sub read/write function calls are hiding some fairly in-depth read/write function calls of there own which in turn are often hiding even more complex read/write calls =) It is layered and often times the underlying layers are more complex than the top layers. I am slowly documenting the .dif format but it is way down my priority list at this moment.

I am in the process of rewriting map2dif for Garage Games. I am doing it in stages with the first couple of passes being fixes and cleanup on the current source code so that I can eventually reach a point of replacing whole pieces of it with better stuff while still allowing artists to use improved versions in the near term. A lot of the source in the current map2dif is poor but there are some very nice pieces here and there. I'd recommend not throwing out the whole thing without a lot of study. Re-writing map2dif from scratch is a *big* task but if you can accomplish it then all the better =)

#5 Thank you Matthew, that's useful information.

Upping the vert limit was mostly trivial, although it kicked off a minor avalanche that required some tending. Since my last post, though, we have apparently banished the remaining gremlins from map2dif, so it looks we'll be exporting to .map for now.

I will have to wrestle with .dif soon, but not immediately. That is, assuming we don't use a proprietary format instead. In any case, I'll be neck deep in most of the same code. Thanks for your input.