: Right now, for me the single most time-consuming task
: on a converted map is texture alignment. If the MMC
: could scale all the textures in a map to 0.25 and then
: align textures on vertical faces with neighbors with
: the same texture it would be huge.
Working on this. Unfortunately UT does not follow any known conventions for...well, for anything, but most noteably for texture alignment. UV (not UVW and not ST) coordinates are 3D vectors, not scalars, and you get one per face. If anyone knows how it handles alignment please let me know.
: Another nice feature would be the option to round all
: vertex and coordinates to the nearest integer or power
: of 2 (2, 4, 8, 16... ). The map authors at Bungie
: didn't always do this, and if I need to modify the
: geometry at all, I often have to go through the .t3d
: file by hand rounding the vertex coordinates first.
MMC currently rounds all vertex coordinates to integer values. Rounding to powers of 2 is doable, but doesn't seem as though it would work as you might think. A difference of 1 unit could mean a nearly axial-aligned wall would suddenly jump to a 45 degree angle.
: If possible. set each brush's origin to it's centroid,
: rounding each coordinate to the nearest multiple of 8.
: This is especially helpful for DynamicLightMovers,
: since they are lit depending upon where their origin
: is. However, even for regular subtract brushes having
: all the origins at 0,0,0 can get confusing.
I was using the first vertex's origin before, but have now switched to the calculated center of the brush.
: It drove me nuts. On Blaspheme Quarantine thre was one
: switch that I could never figure out what it did. In
: the original Marathon map it was set to control one of
: the light tags, but I could never find a place in the
: map where that light tag was used. Providing a text
: report file from the original map that included each
: poly's number, location, lighting, and tags, as well
: as each light number's definition, could occasionally
: be useful. Including platform parameters in the report
: would also be helpful.
Lighting is...difficult. Marathon 1 and Marathon 2/Infinity seem to use completely different methods of storing the light data. I don't have a complete reference for either, and I can't piece together the bits of information from both. I'm looking into it for MMC2 though.
As for a report I'll look into what I can generate.
: Occasionally someone askes me for the geometry for an
: M2 or MInf map. I can give them just the geometry, but
: it would be missing all that other creamy MMC
: goodness.Some people might like to see the ability to
: convert those map types.
MMC converts Marathon 1, Marathon 2 and Marathon Infinity maps. Marathon Infinity's double doors are not properly converted; I only create 1 mover instead of 2. This has to do with the internal data strcture that I use. It's fairly stable and it works, so I'm not quite prepared to fiddle with it yet.
: Many thanks for your fine work.
You're more than welcome. Just glad I can lend some assistance.
