but I have now checked in some updates. Unknowns are correctly parsed according to our current knowledge. Unknowns, depths and vertex co-ordinates are now editable for easy testing.
Great, great, great... my SVN directory will update itself as soon as I finish this post...
At a second look it seems like Unknown1 holds a range of angles from where the primitive is visible, used for advanced culling. This is what makes a bridge polygon visible from all sides, while, for example, the tunnel ceiling is only visible from beneath.
Yes, Unk1 definitively does some sort of "angular culling" (if my terminology is coherent, that is...). When you look at several values of both unknowns for faces of the same object, it's clear there must be a pattern depending on orientation of the faces, only that the actual pattern is not very obvious...
I performed a couple experiments by replacing Indy shapes with tennis courts (so as to take advantage of the net, a very easy polygon to watch
). Naming Cartesian axes as x = length, y = width and z = height, the first two bytes of Unk1 appear to control visibility depending on xz angle (so that objects may disappear when viewed from above - actually from over a certain vertical angle - with "wrong" values), and the last two bytes are related to xy angles (typical example is rotation at car selection screen). What is utter confusing is what sort of limits do those bytes impose... the only certain thing is FF FF grants full visibility and 00 00 gives no visibility (effectively making the polygon invisible, something shape editors could explore later on...). For the xy bytes at least, it seems also that each byte controls half of the possible viewing angles (a 180º range). I simply can't understand, however, why many values of the xy bytes result in far more than two visibility angle ranges (thus making polygons flicker a lot in the car selection screen, for instance), why widely separated values often give nearly the same effects, or why no matter what is done you get always the same viewing range with the xz bytes if their values are neither FF FF or 00 00 (at least from above, that is)...
it would be nice if we could export an individual material list for each paint job on a shape to an external file and then import it later on, so that we can select and distribute paint jobs for custom colour sets easily.
Hm, wouldn't it be easier to just swap 3SH files? Of course, patches are welcome.
Well, I thought of three main reasons for inserting individual material lists into .3SH files:
- Allowing non-editing users (and editing ones too ) to pick their 7 favourite colours easily in a custom file
- Making editors able to restore changes in an individual paint job easily from backups (if one is dealing with the 11 standard colour definitions or simple derivatives such as the ones I presented on the early posts it would "just" require auto-replacing colour strings in an hex editor, but when you start to make more detailed edition it gets a lot harder)
- Allowing for easy recovery of a nice editing work from a .3SH full of failed experiments (this is sort of my current situation with the custom STPMIN.3SH
)
Of course, such commodities are likely not (and need not be) top priority issues for your stressed at the moment, and by the time such sort of stuff actually gets tackled my Java (Fortran? Err...no
) skills might be decent enough for building a reasonable tiny add-on. But the important is the idea gets registered
To switch exploration areas for a brief while, I attempted to dissect a somewhat different file, TEDIT.RES . It basically consists on a list of icon pointers for the track editor interfaces mixed with some other related stuff. Maybe dstien has already looked into it, but anyway here go the main findings. The relevant resources are:
- A huge number of e??? text resources, each containing a set of dialog box messages, error warnings, track piece descriptions, etc.
- A pbox resource with 36*11 = 396 bytes that controls which track pieces will be available on each coordinate of each panel of track editor interface (SHIFT+F1, then F1, F2... F10). Pieces are arranged in the "natural" panel order with coordinates of each panel arranged by rows. Byte values point to track elements using the usual definitions of Track File Format (specified here)
- Three sets of 186 text IDs associated with individual track pieces. snam has 4-byte IDs pointing to resources in SDTEDIT.ESH that define the "shape" of an icon (a very easy way of messing up with use of the regular editor... ). mnam is similar and points to some complementary (maybe colour related? .ESH structure is very different from regualr bitmaps) data on SDTEDIT.3SH. Finally, tnam uses 3-byte IDs pointing at the e??? resources within TEDIT.PRE used as track element descriptions (for instance, "svc" calls "esvc" which prints "corkscrew left/right").
- And last, but not least, ter0...4 are 900-byte resources that define what the default terrains actually are, employing the familiar track file format.
And finally I'd like to close with some new pics - versions of some of my sample paint jobs overhauled with relative ease thanks to stressed... starting with Chulk's suggestion:
Now it almost looks like the real thing, or at least what it would look like on Geoff Crammond's 1992 F1GP...
My American Racing Blue Corvette also benefited a lot from easier detail picking. With a couple small changes, it's a lot more refined now:
(In case you're wondering, I do intend to release my custom .3SHs, it's just they aren't quite up to releasing standards yet
)
