Here's an example of what I mean:
As you can see, the ground, the airfield itself looks fine. There is some "shimmer" from the depth masking. But that's not important. What is important is that the textures on the fuel tanks and nearly everything else, is just wrong.
Only three things I can think of:
1.)
Are you sure you've pulled the
texture index from the polygon group? When I first started playing with my exporter I had a similar problem. I was pulling the material index (instead of the texture index) from the polygon group. A lot of times the texture indices and the material indices match (almost all of them do on the training map). Because of this, some textures show up right (because they have matching material indices) and some don't.
2.)
That, or perhaps you're using the darkmap coordinates insted of the texture coordinates?
On polygon groups with textures and darkmaps, the texture coordinates are always the
last array of coordinates in the texture coordinate listing (darkmaps are first). (If this is the case, the reason the ground texture is showing correctly is because on ground textures there are no darkmaps (this is why shadows are rendered directly to the ground texture map itself). In these groups, the ground texture is the
first texture coordinate array, the second texture coordinate array is the ground detail texture (sort of like a fake bump map)).
3.)
Also, I'm not sure if it is an OBJ format thing, or something about the way RSE stored their texture coordinates, but to get the textures to display correctly I had to have the exporter invert all of the Y (S) coordinates for the texture maps.
I've looked through Mike's VB code for his map parser. I understand it but it really doesn't resemble Basic at all. I was looking through that code to try to see where Mike is pulling the texture coordinates for the polygons that he is dumping to the OBJ file. Except this program doesn't do that. It appears that this program is identifying the same block of data that I am as the texture coordinates. But his objects look just fine in Max. It's possible with all the crazy referencing of vertices, normals and texture coordinates that the wrong coordinates are often used for the vertices. It wouldn't surprise me at all. In fact, I thought it quite odd that the texture coordinates are just by vertex and not by triangle since the data is laid out by triangles. Now, with a mesh, that makes some sense, but on the face of it, it looks a bit strange.
To make the loading process faster (and faster to code) I created a set of user-defined types (like C's structs) and organized them so that they matched the layout of the MAP file entries. Most of the entry data is "mass loaded" by reading a large block of data from the file directly into the UDT as a whole.
This part actually pulls the data from the file (General->ParseGeometryList):
For lngLoop3 = 0 To .NumTexMaps - 1
ReDim .TexMaps(lngLoop3).TexMap(.NumFaceData - 1)
Get mintFF, , .TexMaps(lngLoop3).TexMap
Next lngLoop3
TexMaps is an array of texture coordinate arrays, TexMap are the coordinates arrays.
Which is structured according to these UDT's (General->Declarations):
' Polygon Group
Public Type GR3D_PolyGroup
bytUn1 As Byte ' Unknown
bytUn2 As Byte ' Unknown
bytUn3 As Byte ' Unknown
MaterialIndex As Long
NumTextures As Long
TextureIndices() As Long
lngUn4 As Long ' Unknown
DarkMapIndex As Long
lngUn5 As Long ' Unknown
lngUn6 As Long ' Unknown
lngUn7 As Long ' Unknown
lngUn8 As Long ' Unknown
NumPolys As Long
grpUn1() As GR3D_4UnFloat
PolygonIndices() As GR3D_PolyIndex
NormalIndices() As GR3D_NormIndex
NumFaceData As Long
NumTexMaps As Long
Normals() As GR3D_Normal
TexMaps() As GR3D_TexMapData
grpUn2() As GR3D_4UnFloat
End Type
' Texture Coordinate Arrays
Public Type GR3D_TexMapData
TexMap() As GR3D_TexMap
End Type
' Texture Coordinates
Public Type GR3D_TexMap
X As Single
Y As Single
End Type
The OBJ writer I coded isn't very pretty, I appologize for that. The purpose of writing it was to get something visual to work with, and I had to put in a few ugly fixes for some problems I encountered early on. It's functional, but hardly neat and clean.
Because OBJ files use a single vertex, normal, and texture coordinate array, I had to create a messy way to reindex everything beyond the first room "on-the-fly" as the OBJ file was being written.
I also flipped the Y texture coordinate "on-the-fly" and did a simple texture count "test" to see whether the first array or last array of texture coordinates should be used (first when ground texture is present, last when 1 texture and 1 darkmap are present).
~Mike
