If a new model format is considered, I recommend either .mdl(Source Engine) or .fbx.

.MDL (Source Engine)
====================
Pros:
Skeletal anims
Morph anims
Higher precision
Multi-skin support
Uses qc (wierd am-I-right?)

Cons:
Difficult to create
Pipeline is horrible
Creation is not streamlined (okay so that's really only 1 con)

FBX:
======
Pros:
Skeletal anims
Higher precision
VERY common, de facto Standard

Cons:
Proprietary so there is limited support in some tools (still avail. in Blender)
No morph anim support 

Need engine support in the trinity of Quake engines: Quakespasm, FTE, and Mark V.

+1 

- Quake the Way id Did
- optional PS1-style vertex jitter
- +1 for gameplay mods 

#77
See #75.

#31 Alpha / Masked alpha on models. Can make bat wings cheaper this way or torn cloaks. More than one material per model would be nice too for some quake 3 level shaders like glowing eyes or lava flowing down some demons back. All still in quake palette though.

Super8, Engoo and MarkV already supports alphamasked models, and Quakespasm likely does too.

Glowing eyes and flowing lava can be faked by using fullbright colors and animated skingroups. Animated skingroups are part of the original Quake MDL specs but were never used in the main game, so most people aren't aware it exists.

IIRC, support for animated skingroups was broken in GLQuake, but custom hardware-accelerated engines fixed this ages ago.

What I don't remember is if animated skingroups supports custom timing, like animated framegroups does.

Better lava! I want to break up tiling for this stuff. Have it more solid on the shore and flowing in the center. Just have bigger macro textures to break up tiling when seen from a distance. Those large lava lakes could look so much nicer...

Lit liquids with luma textures can break the tiling. But again, lit liquids aren't going to happen, and I don't know if MarkV and Quakespasm supports luma textures.

I second more advance water volumes that accept lighting and foam.

Foam could be faked by using "negative dirtmapping" on lit liquids. Dirtmapping makes surfaces darker at the edges, but if it suddenly cranked up the lighting at the edges all the way to fully white instead, it could look pretty close to foam.

Even without negative dirtmapping (which could also be called "foam lightmapping") in the light compiler, this could be faked by manually placing lots of tiny lights on the liquids.

The other sensible way would be to implement texture crossfading, which I'm going to do in the future (at the moment I'm faking it through soft depth), but I don't know if any of the other engines supports it. Also, each engine (Q3A, etc.) does texture crossfading in a diferent way, and getting some consensus on standards for such things is near impossible given how different each Quake engine is today. 

I'd like to see it included with new releases of source ports. It would lower the barrier of entry massively for newcomers who don't know how to, or even want to, create shortcuts and BAT files.

A simple front-end for loading maps should be a no-brainer in this day and age. :) 

If a new model format is considered, I recommend either .mdl(Source Engine) or .fbx.

I suggest neither. Any additional complexity is a barrier to implementation. What most people really want is just MDL but without the vertex dance. Better texturing comes second. 

What most people really want is just MDL but without the vertex dance.

Exactly. Cuts to the chase. 

either md3, iqm, or its a waste of time - the tools are much more important than the format itself, and bsp2 meant the same tools could be used (or at least the user-visible ones).
mdl tools pretty much universally suck, worse - the main one that people seem to use is closed source.

md3 already works in qss(r8), fte, dp, ezquake, and _multiple_ others. And there's been at least one software-rendered engine that supported it.

iqm works in fte, dp, and rmqe... and oh noes! quats! flee in terror!

So yeah, md3. Trying to push some other format is pretty much pointless now, especially as there's ALREADY two 16bit q1mdl-derived formats (that noone uses). q1mdl just isn't worth it, imho, especially when the various incompatibilities will persist regardless. 

I didn't know QSS already supported md3.

That hugely increases the chances of it being implemented in other similar engines then. Just need some md3 content, and I'm sure increased support will follow. 

Maybe the lovely chaps behind the AD monsters could export some md3 versions of them? 

a couple exporters exist for blender that are still maintained and there's enough literature to get you rolling quickly. tags are nice, too. 

I'll admit I haven't looked at QS-Spiked (or really anything quake) for the better part of a year - does QSS support crunchy pixel filtering on the fancy particle system yet? 

yes, 'nearest_texture foo.tga' instead of 'texture foo.tga', though I think it requires ALL foo.tgas to use the same type, which is a bit annoying - I didn't tweak QS's texture manager code that much. 

 

My shambler model is exported to MD3 and then converted to MDL in my pipeline... sooo I will have to give it a try in QSS... did not know it supported it ha. I just want bones support to have nicer arching clawing animations. Animating at 10fps with vertex interpolation makes for some wonky sweeping movements. :P 

(At least I hope so) 

#49 It has technically been done for years, it's just that the community didn't really want it. Also, mods like Hellsmash definitely had custom GUIs. So does Brood Hunter. So did Scout's Journey when it still ran on the Quake engine. It had a friggin' drag and drop inventory (other mods did as well). Various mods by gnounc were all about custom HUDs. It's been possible for years, it has just been stifled by being "uncool".

I'm of the simple opinion that it's about workflow.

CSQC is incredibly complex, because it was made to interoperate with Quake's client/server architecture and stuff like physics and AI. People who just want to do simple stuff like making the Ranger face animate in the HUD feel overwhelmed by all of the extra complexity that they don't need.

Custom HUD and GUI coding needs to be as simple as possible. There's no need to create a whole dynamic programming language for it when the user just want to do some tweaks. A static definition format, like a simplified CSS, would be enough.

The power of CSQC lies in massively reducing network traffic, and allowing the creation of really complex works. Its learning curve is too steep for simple cosmetic tasks like "display that icon at position xy if this bitfield is set".

#81 one thought I had a while back that I'd love to see would be 'layered' 2D skyboxes. Engines like QS support loading extra textures as a six-sided skybox cube, but they can't contain any animation or fancy effects like that and completely replace whatever sky texture is used in the map. It might be neat to see a similar system where the six-sided texture set is loaded as normal, but can include transparency and any transparent areas instead show the standard animated Quake sky, meaning you could potentially keep the classic looping-sky look while adding in some detail for the horizon or whatever without dedicating to using an entire skybox texture. If that makes sense.

What you described are Retroquad's hybrid skyboxes. It's a great idea indeed, but it's a pain in the ass to get working, at least on the software renderer. And creating alphamapped skyboxes that looks good is very difficult.

#90 What most people really want is just MDL but without the vertex dance.

And a big part of the vertex wobbling happens because the animations are not skeletal. Animating models without skeletal animation is a living hell, because anything that rotates gets distorted while interpolating. Swords gets shorter, tubes gets crushed, etc.

As Spike said, the tools are much more important than the format itself, and bsp2 meant the same tools could be used. People create Quake maps because the tools are good and they have fun doing that. But creating Quake MDLs is a pain. 

Odd way of saying it... Making monsters is simple for me compared to making a map. But you do end up using tools like 3dsmax, Maya or Blender for modeling and animating. I myself use 3dsmax. I do all my painting using 3dcoat which makes the task of painting the texture in 3d a breeze. Again not a free tool. Blender does have a very good 3d painter as well.

As for converted to MDL, I just export every frame from 3dsmax as a new mesh and then use Inferno's MD3 compiler to make the model. Then I convert the MD3 to MDL and inject the correct textures I want.

Everyone has their tools chain they need to run through. Making monsters or enemies does require a lot of other knowledge that has nothing to do with the tools change. Good mesh construction and unwraps, a sense of form and anatomy, good color and design. Making your own animation rig that is easy to use and deforms well. Good animation! Sense of weight and timing for those attacks and run animations which are seen most of the time by the player... Just different interests is all.

I should just make a video showing my workflow to get a model in game I guess. Tons of resources on making maps for quake but very little when it comes to making MDLs. 

2018 is the year I want to properly learn 3d model making for quake. Any tutorials would help a huge amount 

This was posted last year sometime by the author. It's a solid tut that I found very useful (if you're out there, thank you).

Are you looking for quake-specifc modeling tutorials or just modeling in general? 

... to see in 2018 is the weapon position from WinQuake's "viewsize 100" implemented properly in Quakespasm, Mark V and Darkplaces.

Mark V has an option to enable it, but it doesn't work properly on viewsizes higher than 100 (WQ didn't keep it consistent either, but imho this should be fixed, and I've fixed it in Makaqu).

Seriously, this is my main problem with most Quake engines. This is what makes most engines feel wrong for me, because the weapon is displayed the whole time and I can't avoid noticing that its not where I expect it to be.

Also, I like how the on-camera position of the weapon changes when looking up and down in WinQuake's viewsize 100. This happens because the weapon is higher in world space, not in screen space, but I remember that there's an engine that uses screen space instead of world space in its higher weapon position option. 

QSS to be merged into master. 

This is an idea I had some time ago.

Draw the entire world. Pick a leaf to be the viewleaf. Using occlusion queries determine which other leafs are visible from it, from all 6 directions. Read back the results, that's the PVS for the viewleaf. Pick the next viewleaf, repeat until done.

Vis time should become linear, with no more weird extreme cases.

Vis time should no longer be a function of geometry complexity.

PVS should be tighter and nonsense like geometry half way around the map being included should go away. 

Occlusion queries?:
•Raycasts? 6? Would be woefully insufficient. In a room with 4 world columns in a square in the middle, the 4 corner leafs wouldn't get drawn when you stamd inside the center leaf in the square space between the columns.
•6 Renders - ortho? Possibly if each leaf is assigned a different color. 

Nope; nothing to do with raycasting; using the GPU for rendering to a small enough viewport - 256x256 should be sufficient - do 6 standard renders with 90 degree horizontal and vertical FOV for each. For each, run a bunch of hardware occlusion queries to determine samples passed for each leaf. Any leaf with 1 or more samples passed is visible.

This is nothing to do with raycasts and nothing to do with any software-based approach; it's pure hardware using standard rasterization techniques (that have been available since OpenGL 1.5) based on similar thinking to that used for shadow mapping. Because if you think about it, shadow mapping is just an occlusion/visibility problem so the same thinking should be able to apply to the more general case of determining actual occlusion/visibility.