Update Discussion (split from Version 1.5.1.7)

[Dx.]

[Ultraken]

I had to reinvent the wheel because I didn't have access to the previous-created wheels and needed capabilities the previously-created wheels lacked.

Having the engine directly load BMP, TGA, PNG, and other image formats is fine for opaque textures but many translucent textures require asset-specific preprocessing steps. I suppose I could have written a tool that applied the preprocessing steps and output new image files instead of texture files; TGA and PNG both support alpha channel so they would be suitable container formats for 32-bit textures. This would increase load times slightly since the files would be significantly larger (4x the palettized formats and 2x the 16-bit formats) and require conversion at runtime. Also, those formats don't support compressed texture data like DXTC/S3TC and doing that at runtime would be costly. (I could use DDS or the files output by BZ2 DXTGen for that.)

[Dx.]

If you did dds with dxt then it should be 24bit/32bit textures.
It would be nice to use straight up png, tga, instead of map for everything that isn't sprites.

I never got the cromakey to work in my tests, didn't test this latest version yet.

Interesting posts on your LJ, you say you found the rest of the ppm, planet and tank textures?

I may have some of the perl make file scripts but batch files are good too, gota work toward a data build.

What do you plan for the makeobj tool?

Will you do any work to the makeTrn tool?

[Ranger]

DDS isn't a bad idea, since some models(mainly .nif files) depends of the DDS files for more details(yeah im talking about skyrim and other games with this system)

seing this in bz would be awesome, since it opens more options ingame

[Ultraken]

Texture references lack extensions so the loader has to pick one; right now it just tacks on a ".MAP" and is done with it. Using other file types would complicate the process since it would have to check several different extensions instead of just the one. It would also require a more complex import process than loading the file directly into memory. (The MAP format is just a raw dump of the TEXTURE memory structure.)

"-chromakey 255 0 255" (minus the quotes, obviously) should work assuming the image uses magenta; I was able to generate functional interface textures from magenta-chromakey source images. I added an additional option to specify the transparent color index when writing 8-bit indexed textures but the chromakey option itself doesn't rely on that.

The NSDF and CCA textures were already out there on the internet (though I don't remember where I found them). I managed to dig up the effect, interface, terrain, and sky textures but no additional object textures. I'll keep looking, though.

Texture processing is pretty simple so a batch file is good enough for now. It'd be neat to see all the make file script stuff again, though, if only for reference. It'd also be nice to avoid re-cooking files unnecessarily but it's generally fast enough that wasted effort doesn't matter as much. I would have preferred starting from the original asset pipeline but MakeMAP works decently enough.

I don't have any VDF/SDF source text files or OBJ model files to work from so I can't do much to reconstruct MakeOBJ. The whole model format was sufficiently heinous that I'm not sure I want to continue supporting it.

I only recently looked at MakeTRN but I don't know what if anything needs to be done with it since it gets the job done.

[Ultraken]

If I had to pick a replacement for MAP, I'd go with DDS since it's pretty close to a cooked texture asset and adds a bunch of useful functionality. The hardware renderer would still need to be able to generate D3D surfaces from MAP-style TEXTURE structures since several game systems generate them at runtime. (FlagDisplay is a major one.)

[Dx.]

The NSDF and CCA textures are the ones i released which i originally got from you soo many years ago... I still can't believe i forgot about the Black Dogs.

The makeobj source was with the bandlands 1.1 code base from Pandemic you sent me long ago but if you replaced it, what format would you use?

For maketrn i was hoping you would modify it to write out the slope and height data to the planets ini file. This would allow map makers to assign materials and auto paint maps more easily.

[Ultraken]

Ah, so once again the circle is complete...

I haven't thought that far ahead yet and probably won't end up replacing it with anything. I'm not in a big hurry to jump into the world loader system...

Could you describe what map makers would want? I haven't made any maps so I don't know anything about it.

[hitchcockgreen]

Oh man where to start.

Should get Ssuser in on this conversation.

[Dx.]

Could you describe what map makers would want? I haven't made any maps so I don't know anything about it.

Once a map maker has his terrain finished, it's time to auto paint it.

When you auto paint a map it helps to be able to assign different materials depending on the terrains
slope and elevation data. If you guess at the slope/elevation settings, maketrn will spit out the slope/elevation missing errors a very time consuming one at a time, which is a real pita.

If maketrn analyzed the entire terrain and wrote the slope/elevation data to the planet specific ini file, the map maker could assign the material numbers manually.Then it would take mere seconds to paint the entire map.

(For more info refer to the mapeditor.doc section 7 Automatic texture painting)

I'll use bane.ini as an example:

maketrn multdm01.trn /p=”bane.ini” (this writes a new multdm01.mat file)

[Layer0]
ElevationStart = 0
ElevationEnd = 63
SlopeStart = 0
SlopeEnd = 4
Material = 0

[Layer1]
ElevationStart = 0
ElevationEnd = 63
SlopeStart = 5
SlopeEnd = 15
Material = 2

[Layer2]
ElevationStart = 0
ElevationEnd = 130
SlopeStart = 16
SlopeEnd = 45
Material = 3

[Layer3]
ElevationStart = 0
ElevationEnd = 218
SlopeStart = 46
SlopeEnd = 90
Material = 4

[Layer4]
ElevationStart = 150
ElevationEnd = 300
SlopeStart = 46
SlopeEnd = 90
Material = 5

[Layer5]
ElevationStart = 290
ElevationEnd = 352
SlopeStart = 46
SlopeEnd = 90
Material = 6

[Layer6]
ElevationStart = 290
ElevationEnd = 400
SlopeStart = 0
SlopeEnd = 6
Material = 7

[Layer7]
ElevationStart = 0
ElevationEnd = 400
SlopeStart = 0
SlopeEnd = 90
Material = 3

[Dx.]

Some other things that may be handy would be more Elevation editing tools built into the editor.
I believe UDK had a good set of terrain shaping tools.

In the editor ctrl+e then ctrl+w mode, 4th button down in the right column, i'm not sure that tool does anything.

Oh and lastly, expanding the editor build menus so all the game objects can be accessed without having to write new b_*.odf files.

In BzE we added sub menus to accomplish this where pressing "0" went to the next menu.