Porting levels to 3D quake/goldsrc map format trivial?

[dileepvr]

I've been trying to parse the C++ code from the old Pentagram team: https://pentagram.sourceforge.net/download.php
And I came across this comment block at the beginning of a file:

This convinced me that the whole map is tile based and all the collision boxes are cuboids.

Now we already know how to extract sprites from the game files. And the pentagram code (and others on this form) know how to read level data as well. Given that there are extant open file formats for 3D levels with great open source level editors, shoudln't it be easy to programmatically read the old game files and spit out a simple map file that can be read by these 3D level editors? Start with assuming that everything is a cuboid and worry about modelling and texturing later?

Suggestion: The Quake or GoldSrc (Half-Life 1) formats. These formats have great level editor tools like Trenchbroom and JACK. Trenchbroom has really good documentation and tutorials. And JACK is said to be really fun to work with. Not that that matters at this stage. The task is to write code to translate levels into something that these programs can read. Again, everything can be a cuboid to begin with. Save the modeling and texturing for later (and for others?)

The twitter bot BSP_overviews keeps autogenerating isometric views of GoldSrc maps and posting them twice a day. Example:

And someone has made an isometric mod to one of those open source quake engines.
So there is potential here for an eventual full port. And there will be reduced risk of the project dying prematurely due to a drop in interest as everything uses extant open tools and progress can be modular. New teams can simply pick up where the old one leaves things off.
I can start working on the basic cuboidal translator code end of Summer 2024, unless someone else wants to beat me to it.

 

[IGTC]

I think it would be a great idea to have the maps ported into a generic format, even if there is no impetus to port the game into, say, the Quake engine. Just having that kind of map data would be great to play with.

stauff has done a butt load of work porting pentagram code into ScummVM and getting it working with Crusader. If anyone knows the details about the map format and the feasibility of what you propose it would be him.

 

[Candy]

Just let me know what the format should be and I can output both the bounding boxes and the level data. Already tried into gltf with a Javascript viewer, and that worked, but at 8FPS due to object count. Level 1 has about 17000 objects - every floor is an object too, just so you realize.

 

[dileepvr]

Just let me know what the format should be and I can output both the bounding boxes and the level data. Already tried into gltf with a Javascript viewer, and that worked, but at 8FPS due to object count. Level 1 has about 17000 objects - every floor is an object too, just so you realize.

That is so cool. Wasn't hardware acceleration available? Is the code available somewhere?
I don't know what the best format is yet. I gravitated towards Quake2/HL2 MAP and WAD files, thinking that their level editors are stand alone and easy to pickup. But their engines are optimized for first-person cameras (uses binary space partition). Isometric rendering should be a lot simpler. However, Godot engine has a plugin called Qodot that can import these MAP files.

I'll find some time to play around with basic rooms and minimalist polygons in Trenchbroom and get back to you. It would be good to get a repo going. Maybe make a basic viewer with some sprites being selectable (and a properties popup)? Using something with hardware acceleration. Say raylib.

 

[dileepvr]

Yes. I am more convinced that the Quake/Valve MAP format is the way to go. The meshes are stored not as vertices but as planes, with each plane defined by three non-collinear points. Their order decides direction of normal. The engine extends the planes until they intersect a skybox of sorts and then culls them where they intersect each other. All these maps need roofs as they are defined as cavities in a solid universe. The lighting prebake shoots out rays until they terminate on a surface, so no room for "leaks". And I think our camera vows are being solved by this new isometric mod for Half-Life caleld Loop:

The Crusader games can become a mod to this mod.

 

[Candy]

Yes. I am more convinced that the Quake/Valve MAP format is the way to go. The meshes are stored not as vertices but as planes, with each plane defined by three non-collinear points. Their order decides direction of normal. The engine extends the planes until they intersect a skybox of sorts and then culls them where they intersect each other. All these maps need roofs as they are defined as cavities in a solid universe. The lighting prebake shoots out rays until they terminate on a surface, so no room for "leaks". And I think our camera vows are being solved by this new isometric mod for Half-Life caleld Loop:

Crusader doesn't have meshes. It doesn't support rotation. That's in part why the explosions look so weird; things are supposed to rotate next to an explosion and they just don't, because they can't.

Do you have an engine to target? Half-life or quake? Note that Quake uses BSPs which take a lot more effort on my part and are not great for maps with tons of objects / polygons.

One thing that's different is that most games and level formats try to have as many as possible "static" bits that are unchangeably part of the level, and some "dynamic" bits that can change. Crusader didn't have this split. Every floor, wall and so on are separate entities. Most game engines fall over unless you somehow convert from the "floor, wall" entities to some static form.

I have https://github.com/dascandy/cnr which draws a whole level at full resolution. Unlike the image above, these tend to be around 16k pixels wide.

 

[dileepvr]

Yes. I have been thinking about this a lot. I think we should go backward to Doom. Everything in fixed.flx can be sector wall textures. These can be programmatically derived from the sprites in shapes.flx with Y-shearing and stretching. Here are two examples:


As for objects, including the silencer, we just need sprite views from eight or sixteen directions, which GZdoom supports. I found the sprites for the rolling barrel and was able to come up with these:

That is one quadrant.

I am in the process of adding an isometric camera with orthographic projection to the gzdoom engine. I am hoping to be able to show it here by christmas.

 

[Candy]

Do you have all the shapes rendered or should I send you my set? I think I have them mostly categorized.

Also, do you have a ref for the output format you can use for gzdoom? The data in fixed.dat is in x/y/z format, and typeinfo gives a width/height/depth to it.

 

[dileepvr]

Merry Chrismas and Happy Holidays resistance scum.
I finally got gzdoom behaving with orthographic rendering:

More details to follow once I have the code in good shape to share. Right now, adding a rotatable camera. I think an 8-viewpoint mode and a 16-viewpoint mode will be lovely. I need to fix the controlling scheme too.
This won't work as well with most Doom maps because, well, walls will be in the way of the view. We are using the textures-don't-render-from-behind trick. Maps will need to be made specifically for this mode. And as you can see, there are restrictions on what sort of roofs you can get away with.

@Candy I'll try and make two simple standalone map files. One being a simple square room, and the other with an 'I' shape and some split level floors. You could start studying them. You will need 9 sectors instead of 1 for a simple square room to get the wall top edges to show.
One major issue will be that all Actors (non-level-geometry objects) need a square footprint bounding box. The sprites can be whatever shape but the physics treats everything as a cuboid always aligned with the global axis.

I would love to see your categorized shape set (that sounded dirty) but not right now, as I will stop working on it for a few months. I would like the footstep sound though.

 

[dileepvr]

I made a fully functioning branch for isometric camera with orthographic projection to the GZDoom engine (in my fork): https://github.com/dileepvr/gzdoom_isometric/tree/g4.11.3_iso

Video showcase:

I made some test maps with assets pulled from the gamedata. Took a while to get the desired behavior, and I kept discovering new bugs to fix. But it is finally stable. The maps cover just about everything needed geometry wise to regenerate actual game maps. They move from simple to complex (for Mr. @Candy ). Attached.

I am stopping working on this for now, since it is very addictive and has consumed all my free time. But I will answer questions posted here. I learnt a lot about GZDoom this past month.

 

[Keenan]

Wow.

 

[IGTC]

Freakin' amazing!