The future of Quake - Wishlist

[Fragger]

Well, we have new engines and new textures too. What else do we want?
Models come to mind. It would be so cool having models that don't look so blocky. Rounder heads, facial features, etc. Also, give the grunt a real shotgun and the ogre a real grenade launcher. Make the gibs more realistic. Maybe have gibs for each monster instead of having them all share the same set.
What do you think? What's on your mind?

[Dreadlorde]

New models; maybe a different model format, idk much about it, are something I think most people would agree we could really use. Maybe we could backport the Quake 2 model stuff? I'll have to take a look at the code.

There's a bunch of stuff that has to do with engines I would like to see. I'll add them later once I make the list.

[Efess]

More quakers!

[MH]

New models is seconded here. I like the suggestion of the Q2 format; it's simple enough to work well within the bounds of Quake and QC (which should keep the modders happy, as well as not requiring too much time to build) and would be a huge improvement on the basic Q1 stuff. I'd suggest that they should work as drop-in replacements, so that it would be possible to just directly replace the Q1 models and have them work straight away without any requirement for QC changes.

If there's another format that's simpler, gives better quality, and has working real world code for both a loader and a renderer that could be integrated into a Q1 codebase with minimal pain/grief that would be great too.

[Baker]

MH are you able to write such a Q2 model tutorial?

Just curious. I think the Q1 model format is too difficult to make and the Q2 format is a lot easier I have heard, but I know that I for one lack the expertise to add it into an engine.

[Hazza]

Personally I'd have a cardiac arrest if someone were to make a Quake-themed mod on the Source engine. That would just be too awesome.

[Mr.Burns]

I think there are a number of us who would welcome easy to use portable "drop in" models. Although it could be seen as something of a novelty, so many other games (eg UT) have had this feature for such a long time now. If the auto map/sounds/model download code could be utilised to do this with a minimum of fuss or user intervention IMHO it could helpt to "freshen" the game a little and could just broaden it's appeal. Picture Ronald McDonald slaughtering Arnie and Superman only to be blown to bits by Mr.Burns. Nice image just for the comedic value alone We've had multiskins support for years in mods like Q1 DMP and bloodskins in painkeep and although these are an improvement, new models might just be the way to go.

Other possibilities:
Blood skins - to further improve player options perhaps engines could place increasing Blood/Wounds on players as their health decreases. This might even ecourage lesser skilled players to engage in combat (rather than camp/run away) with higher skilled players if they can actually see thei opponent is injured and potentially more "fragable". This has been discussed in another thread and from what I undersrtand from such luminaries as Rook it is possible and would add a little [more]realism to Quake.

vote-anticamp - On the server side perhaps a voteable option to ensure that if a player stands (camps) in one area for over 5 seconds without moving they will receive increasing self damage. This would hopefully "encourage" them to partake in the game a little more.

Just my two cents worth.

Kind regards

Monty

[MH]

MH are you able to write such a Q2 model tutorial?

Just curious. I think the Q1 model format is too difficult to make and the Q2 format is a lot easier I have heard, but I know that I for one lack the expertise to add it into an engine.

I should be, yeah. I've done Q2 models before based on the old QuakeSrc tutorial, but that's obviously well out of date by now (it predates the Q2 source release).

The architectures of the engines are just so freakin' similar that I have a feeling that 80% of the renderer will be just drop 'n' go; translate some qgl calls to gl, remove some Q2 specific stuff (FX and whatnot), fix up cases where globals might have different names, and I think it'll be there.

It will probably need some more careful consideration of how to do the loader. I'd suggest a similar strategy to what's currently done for textures, i.e. look for a Q2 model with a name based on the Q1 model name, and if that's not found we fall back to Q1. Memory management might be fiddly; Quake initially loads models into a big memory buffer, so we need to rejig a little to support Q2. Likewise cache name matching. But none of this is not solvable.

Then pick up any other areas in the engine where a model is referenced. And ideally have a single unified struct header (and potentially renderer) for both types so that we can keep code changes to a minimum. Yeah, that last point: both should be capable of being rendered via the same code, and the closer that code is to vanilla Q1 the better. Ideally load the Q2 model into the same structs as is used for Q1, and modify as little as possible.

How does that sound?

[gnounc]

Sounds like I shouldnt question you

[Dreadlorde]

I should be, yeah. I've done Q2 models before based on the old QuakeSrc tutorial, but that's obviously well out of date by now (it predates the Q2 source release).

The architectures of the engines are just so freakin' similar that I have a feeling that 80% of the renderer will be just drop 'n' go; translate some qgl calls to gl, remove some Q2 specific stuff (FX and whatnot), fix up cases where globals might have different names, and I think it'll be there.

It will probably need some more careful consideration of how to do the loader. I'd suggest a similar strategy to what's currently done for textures, i.e. look for a Q2 model with a name based on the Q1 model name, and if that's not found we fall back to Q1. Memory management might be fiddly; Quake initially loads models into a big memory buffer, so we need to rejig a little to support Q2. Likewise cache name matching. But none of this is not solvable.

Then pick up any other areas in the engine where a model is referenced. And ideally have a single unified struct header (and potentially renderer) for both types so that we can keep code changes to a minimum. Yeah, that last point: both should be capable of being rendered via the same code, and the closer that code is to vanilla Q1 the better. Ideally load the Q2 model into the same structs as is used for Q1, and modify as little as possible.

How does that sound?

That sounds great. I haven't looked at the Q2 code much, just grep'ing it to find references to md2 so I can see what to hack on. That's not going to well :p I just get references to models, not the code that renders them (afaik).

Hopefully someone with more talent than me in C can figure out where to actually begin.

[MH]

Look in gl_mesh.c for rendering, gl_model.c for loading. Mod_LoadAliasModel is the loader, same as for Q1.

Anyway, I've started working on this and there are a few questions and other items I need input and opinions on before I can really go further:

• The naming convention. Let's get this down at the very start and avoid a mess similar to what happened with Q1, where multiple different naming conventions exist. I would propose keeping it quite simple. If we are given "progs/soldier.mdl" to load, we should look for "progs/soldier/tris.md2". That way a Q1 model name can be easily translated to it's Q2 equivalent with no messing.
• Skin names. Q2 models contain skin names in the MD2 file which are then loaded. The skin name is a path which can be fed into COM_FOpenFile or the like. Proposal is that we use the same path as the tris, so we get "progs/soldier/skinname.pcx". The MD2 format doesn't require this and the skin can be anywhere in the filesystem, but it seems cleaner to keep them together. So let's use this path irrespective of what the MD2 says; if it's not found then we can always load from the path specified by the MD2.
• Image formats. The MD2 format doesn't require PCX, you can specify any file type in it. To keep things simpler I don't think I'm going to bother with tutorializing an image loader here. This will let me focus on the MD2 loading and rendering element without peripheral stuff to distract. There are plenty of image loader tutorials around (start here, for example), so when I get to this part I'm just going to say "now send it through your image loader".
• Auto-animation of skins and frames. MD2 doesn't have this (see Carmack's .plan entry on the topic) and I propose that we just live without it. There doesn't seem to be a need to replace torches with MD2s anyway.
• Frame scaling and translation. MDL stores scale and translate per model, MD2 stores it per frame. I was hoping to avoid doing it, but it looks like I'm going to need to extend some of the Quake structs to allow for this. An alternative option is to slightly modify the alias model renderer. Which one seems preferable? Remember that one of the objectives here is to have a single renderer for both model types.
• Interpolation. I'm not going to bother with MD2 interpolation. Again, it would distract from the objective of getting baseline loading and rendering done. It should be possible to use Q1 interpolation on an MD2 if the single-renderer objective can be met.

[Dreadlorde]

Look in gl_mesh.c for rendering, gl_model.c for loading. Mod_LoadAliasModel is the loader, same as for Q1.

Thanks for the hint.

Anyway, I've started working on this and there are a few questions and other items I need input and opinions on before I can really go further:
[*] The naming convention. Let's get this down at the very start and avoid a mess similar to what happened with Q1, where multiple different naming conventions exist. I would propose keeping it quite simple. If we are given "progs/soldier.mdl" to load, we should look for "progs/soldier/tris.md2". That way a Q1 model name can be easily translated to it's Q2 equivalent with no messing.

That sounds good. I can't think of a simpler way of doing it.

[*] Skin names. Q2 models contain skin names in the MD2 file which are then loaded. The skin name is a path which can be fed into COM_FOpenFile or the like. Proposal is that we use the same path as the tris, so we get "progs/soldier/skinname.pcx". The MD2 format doesn't require this and the skin can be anywhere in the filesystem, but it seems cleaner to keep them together. So let's use this path irrespective of what the MD2 says; if it's not found then we can always load from the path specified by the MD2.[*] Image formats. The MD2 format doesn't require PCX, you can specify any file type in it. To keep things simpler I don't think I'm going to bother with tutorializing an image loader here. This will let me focus on the MD2 loading and rendering element without peripheral stuff to distract. There are plenty of image loader tutorials around (start here, for example), so when I get to this part I'm just going to say "now send it through your image loader".[*] Auto-animation of skins and frames. MD2 doesn't have this (see Carmack's .plan entry on the topic) and I propose that we just live without it. There doesn't seem to be a need to replace torches with MD2s anyway.

Sounds good.

[*] Frame scaling and translation. MDL stores scale and translate per model, MD2 stores it per frame. I was hoping to avoid doing it, but it looks like I'm going to need to extend some of the Quake structs to allow for this. An alternative option is to slightly modify the alias model renderer. Which one seems preferable? Remember that one of the objectives here is to have a single renderer for both model types.

Whichever one sucks less. I don't know much about how the models work, and don't want to muck things up.

[*] Interpolation. I'm not going to bother with MD2 interpolation. Again, it would distract from the objective of getting baseline loading and rendering done. It should be possible to use Q1 interpolation on an MD2 if the single-renderer objective can be met.

Do whatever you think think sucks less.

What engine are you doing the porting in? DirectQ? Original Quake source, or something else?

[Baker]

Thanks for the hint.
That sounds good. I can't think of a simpler way of doing it.
Sounds good.
Whichever one sucks less. I don't know much about how the models work, and don't want to muck things up.
Do whatever you think think sucks less.

What engine are you doing the porting in? DirectQ? Original Quake source, or something else?

Some insight might be able to be gleamed from this GLQuake engine which I believe has MD2 support:

:: Q2K4 Project ::

[Dreadlorde]

Some insight might be able to be gleamed from this GLQuake engine which I believe has MD2 support:

:: Q2K4 Project ::

It indeed does have support for Q2 *and* Q3 models. Thanks for the link.

[MH]

I think what sucks less is modifying the Q1 formats a little so that we can meet somewhere in the middle. Trying to wrestle the MD2 raw data directly into the Q1 format would be complex, flaky and bug-prone. Example: MDL has 2 commands per vert, MD2 has 3. Adding a dummy third in the right place to the derived MDL mesh is far easier (one line of code and 2 changes of "order += 2" to "order += 3" than compressing down the MD2 commands (and also having to decompress MD2 verts as a result).

For the engine I'm currently putting it on to DirectQ 1.0 because it's closest to stock GLQuake and is more stable and usable on my machine. I'll also be putting it into a stock GL engine as a final test, but I'm finding it easier to build this in an environment I'm familiar and comfortable with. So use that for the hard part, then integrate back.

Anyway, the loader is mostly done now, and I'm just integrating with the renderer. I haven't fully done PCX loading, but as soon as I do have a screenshot of an untextured MD2 I'll post it.