Discussion about game limits, format support and converters going forward

[Fila]

We should stay to the topic on hand and not veer into other suggestions, only because I want to keep a focused thread on the exact work that needs to be done, not for any other reason.

So now that I went through the wishlist, I am looking at the following:

1. Increasing the limits

This would be the easiest one, for reference the current hard coded limits in the game are:
Textures = 512
Models = 256 (lol)
Model Textures = 1024
Ground Boxes = 2048
Scenery Objects = 541
Ramps = 10
Moving objects = 48

So these are the easiest to increase, it's literally just turning a number up. But I need help to make Traxx compatible with whatever number we come up with. So that we have them working in tandem rather than ending up with different values. Alternatively, I could do what I did with cowpod where I export the actual values in an ini file and have traxx read that ini file at startup and adjust the values accordingly. Though this way it opens up to some issues like what if i release a patch that increases the values halfway while a track is worked on.

2. Increasing the technical limits
The first point naturally leads into this second point. Right now the current limits are the following... with a slight variation between DX11 and Vulkan

current_mtm2_limits.jpg

Now, these numbers will obviously need to be updated if we add more objects and higher poly trucks/objects and increase texture size. Either way, that is not that complicated as it's just changing some numbers, the point is to find a sensible solution.

3. Adding support for different textures

- higher rez textures such as 512 and 1024
- what should the amount be for each?
- i assume we should go 24bit true color textures (regardless of size, so even 64x64 would be 24bit)
- formats? .png .tng .bmp .tga .tiff .jpg even
---- from a quick glance online i see that .tga is generally considered the default? and .png somewhat in 2nd place and the others are kinda per case basis with the issue with .tiff is that they are large

4. Adding support for different model formats
- rudee mentioned .smf due to ease of using it with blender (which sounds like a plus to me)
- in addition, jpez mentioned using stb_image library to change the already existing .bin models to use .png instead or the raw/act combo.

5. Cale suggested adding a new texture type "Shiny Transparent" to help have glass windows which also reflect. That also sounds great, we just need to add that to BinEdit or whatever model editor we use.

For all these points, especially 1 and 3, we would also need to change traxx/binedit to help facilitate this. If we add in .smf then maybe updating BinEdit limits will not be required but some users might still be die hard BE creators who don't want to learn new tricks.

Initially I wanted to do this after Comm Patch 3 but I realized adding these features first would probably be best, it would make an easy cutoff to add to the website that any tracks and trucks added after this date and with a specific tag (will have to think about it, either Tracks 2.2/Trucks 2.2 or something) are only compatible with the comm patch 3 going forward and not with legacy whereas anything else that is done with the old format still works, no matter the version of the game.

[OG_RuDeE]

This post says I don't have permission to view the files attached to this post.

[Fila]

Well that was dumb. Fixed

[Fila]

Side note: In the meantime I have started looking into raising the limits etc and it's becoming clear that if I want for us to be able to bring in high res trucks and objects, I will need to migrate the game to 64bit executable.

[Jpez1432]

Hey Fila, not sure if you saw my other post, rambled about glb models, binary models that include the texture embedded into the model, can either be png or jpg or size. I strongly suggest against tga and tiff, tga is legacy. If you do go the glb route I'll send you code for a model loader with cgltf library if you would like. Otherwise stb_image loads all kinds of formats. My two cents, if not new models, at least new texture overrides where it searches for png or whatever first instead of raw/acts when loading the textures, honestly wouldn't even need to rewrite binEdit or anything, and same with glb models simply look for them instead of bins first.. That would be the easiest in my opinion. Texture resolution at least 512 or 1024.

[Kmaster]

at first I said let's go with DDS format for textures then I remembered we now have Vulkan (and it was me that wanted to get rid of DX in the first place...). I would ask an AI agent what's the best option right now in game development for truecolor textures with multiple API support.

and yes, we should support up to 1024 truecolor at least.

we should also think if we need a new SIT format, or some sort of magic number inside the SIT to identify these enhanced tracks, since we can not make them backwards compatible with old mtm2.

about traxx.. err.. do you want to make those changes? i can share you the 1.6b2 code if you want.

[Fila]

Yea sure, I'll take the latest traxx code you have.

[Cale]

I could write a long diatribe about this, but I'll keep it short. It's great if all these limits are increased and the detail of the trucks and tracks can go to the moon. I won't be building trucks and tracks to meet those standards, though. What I love about MTM2 is that it is a moment in time, how gaming was in 1998, and that's part of the charm for me. I very much appreciate the quality of life improvements and making the game stable on modern systems, but my projects will still be at least somewhat focused on period-correctness. I do hope someone out there has the skill with Blender, the talent, and the time to make super-detailed stuff for the game, but I simply have none of those (the last one, especially - a new baby will do that to you).

I do still plan to try and go through my HD trucks and change the chassis and accessories to not be shiny, but that's only as I have time and energy and that could be months from now, if not longer. I don't have an issue if someone wants to use the bodies etc. as a basis for their own more detailed trucks, but I probably won't do it.

[OG_RuDeE]

I have a similar feeling to Cale, despite playing a bit with pushing the limits myself (since having too many days off recently). I think what has been accomplished by Fila so far amounts to a very nice "HD upgrade" to the game which at the moment can allow for many new "MTM2 style" additions in content to the game.

When the time comes though for lots of the suggestions on the Community Wishlist, e.g. tornados, points systems, way larger maps, who knows what else..., I feel like we are moving into a totally new territory that maybe should fall under a new name, E.G. MTM3 or MTM2 HD Redux (Fila ;) ). I've been wondering if Community Patch 3 should be a "stable" (bug-free) version of what's been accomplished so far and if some of these new larger additions should be something else / new / separate?

[Ford-chan]

I have a similar feeling to Cale, despite playing a bit with pushing the limits myself (since having too many days off recently). I think what has been accomplished by Fila so far amounts to a very nice "HD upgrade" to the game which at the moment can allow for many new "MTM2 style" additions in content to the game.

When the time comes though for lots of the suggestions on the Community Wishlist, e.g. tornados, points systems, way larger maps, who knows what else..., I feel like we are moving into a totally new territory that maybe should fall under a new name, E.G. MTM3 or MTM2 HD Redux (Fila ;) ). I've been wondering if Community Patch 3 should be a "stable" (bug-free) version of what's been accomplished so far and if some of these new larger additions should be something else / new / separate?

My whole vision of MTM2 going forward is much bolder, mostly because no other game ever since has come close to what made the MTM games so much fun in the first place, not to mention giving both Beam and Rigs some competition in the sense of being the penultimate simcade variant of the monster truck gaming ecosystem that we have now.

If purism still persists with some of us here, then how about this for an idea...

Monster Truck Madness 2: New Century Edition

Monster Truck Madness 2: Legacy Edition

Interestingly enough, DOOM does that sort of thing with both Classic (MS-DOS, PRBoom source ports), and Modern (GZDoom, not to mention Brutal DOOM), for everybody of certain accquired tastes.

[Kmaster]

I don't see any point on having two separate editions as long as we keep 100% backwards compatibility with classic tracks and trucks. So far, Fila hasn't changed any core gameplay mechanic (drags being a novelty for mtm2). HD/2.1 Trucks and tracks should be clearly marked as such and I 100% get the retro-fit mentality of some of the modders, but hey, nothing is going away, we're just expanding the game so that we track & truck makers that had to be limited all these years can explore new ideas.
It would make no sense to make mtm2 something that it is not, and I remember discussing this with Fila weeks ago. texture and vertex limits aint changing the core of the game, but if we make mtm2 play like 4x4 Evo now that would completely suck.

[Fila]

The most I would do, if we ever get there, is to add a special toggle for drag physics. But that is a long way to go as there's plenty of other work to be done before we get there.

But that's also why i wanna keep this thread focused on the technical stuff such as objects/textures/how to render them rather than changing the way the game plays. The good thing with this is that it raises the ceiling but it doesn't do away with the old school way of doing things. Just gives you a freer hand to maybe make a 20k poly truck.

[OG_RuDeE]

Oops, sorry Fila. On topic stuff:

For 3, I have experience with .png and .tga from doing some mods for Wreckfest. In my experience both work well. I think .png is preferred for being slightly smaller. Neither .png or .tga get used in the final product there though. There is an asset tool that converts them to .bmap which is compressed and includes several levels of mip maps which the engine decides between depending on distance. If we're going to increase the view distance and max model count, so there are tons of things visible in the distance, some mipmapping may be useful / required.

For 4, with the Blender plugin working well, .bin seems perfectly fine now, especially since you fixed the caps issues in texture names. I haven't run into any issues I couldn't colve yet, but we'll need to wait until more people have tried the plugin to know what other issues might arise with bins. As far as textures go, bin models are not really tied to raw in any way. The name + extension both appear in the bin, so we could reasonably change to any texture type ending in 3 letters, e.g. png, tga, etc... the only other constraint on textures I can think of is that the file names need to be 8 letters or less, not sure if that's an engine thing or bin model structure thing.

.smf came to mind earlier because I know them, and one can simply open them in a text editor and edit lots of properties by hand if needed. They also have a slot for bump maps built into the file structure. Evo used .tiff with smfs, but the current exporter can be modified to change the file type to whatever, or you just open up notepad and do a quite find / replace.

It would be nice to be able to incorporate bump maps for both truck and track textures. This is probably something that just gets coded into the engine where it loads a bump map based on the image texture name, e.g. while loading sand.png the engine auto loads the bump sand_b.png, as long as the bump file is included, and it loads a standard "smooth" bump texture if none was included with the mod.

For comparison, Wreckfest uses its own model format, .bgo that you use their utility to build. I don't know what all goes on there, but their maps are models and I know the utility breaks large maps into smaller chunks for resource reasons. I don't think we need to take a path like this though.

For 5, I was thinking the same when you and Cale were discussing that. Shiny transparent would be great.

Another nice face type addition would be a "leaves" face type that receives different shading than the rest of the models to allow the trees to brighten up. I was reminded of this when working on the 3d Evo trees, and it's something Wreckfest has. It makes a big difference. Some light passes through the leaves in real life, so they should look brighter in game, I think is the idea.

That's all I have for now, but I'll try to keep this thread in mind when I'm working on stuff.

[Fila]

The 8 letters is an engine thing that will be updated along with the rest of the pipeline.

I've already scoped out the shiny transparent and it's doable. Will also add a LIGHTS object instead of being tied to MOVING parameter. A LEAVES face type works, can easily add that too, anything we add from this point onward in terms of lights/shade is much easier to deal with because we make the rules instead of retroactively trying to make it work across thousands of models authored in different ways.

And could definitely add .smf and obviously keep .bin By the sounds of it, doing away with the 8 character limitation and with the .bin/blender conversion working already then it becomes a matter of personal preference.