#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. 

That sounds like it could massively improve vis quality in big outdoor Tronyn-style facemelters. 

but i'm still waiting for a something new from Kinn

@Kinn , there's a TF discord channel, if you're willing to join to https://discord.gg/P56HXr 

... 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...

Recent QuakeSpasms have restored the original code via the same cvar-based mechanism as MarkV too.

It'll probably never happen in DP because Religious Reasons. 

I'd love to see the top tier mappers start a project expanding on the shareware episode maps the AD's extra beastiary and projectile weapons.

I want to play E1M1 with the Widow-maker, dammit! 

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.
Hey, that's pretty neat. At risk of sounding like a complete moron, what exactly causes it to be a pain in the ass? I'm sure it's somewhat difficult to make it look good, but honestly, any sort of happy medium between the standard tiling two-layer skies and the static but six-sided skybox textures supported by newer engines would be fantastic. The extra detail given by the skybox is great but given how lively some Quake maps tend to look within the play area itself, the completely stationary skies and backgrounds can sometimes stick out like a nailed thumb. 

...what exactly causes it to be a pain in the ass?

I assume that's specific to the software renderer. In hardware it's just some cubemaps and some texture matrices. 

#112 Recent QuakeSpasms have restored the original code via the same cvar-based mechanism as MarkV too.

Thanks, I've found it now. There's no menu option for it in QuakeSpasm, and I usually don't bother searching through cvars in game engines anymore, so I didn't notice it was implemented.

After enabling it, paying in QuakeSpasm got 200% better for me now!

#114 what exactly causes it to be a pain in the ass?

The zero-overdraw architecture of Quake's software renderer is incredibly monolithic and gets in the way.

In my implementation, each side of the skybox is vertically cropped twice, one time for the fully opaque section of the image, and another for the section that contains some transparent texels, while the fully transparent vertical area of each side if fully cut out. The fully opaque section gets drawn as an opaque surface, and the rest is drawn as an alphamasked surface.
Also, the background layer's sides are cropped from the bottom of the alphamasked portion of the foreground, to the absolute height of the skybox.

Dynamically resizing surfaces like this, specially when all of them are shared by the same cube, causes complete chaos in Quake's monolithic BSP architecture.

The hybrid skybox implementation in previous versions of Retroquad was far simpler, resorting to much more overdraw, which is much slower. 

I noticed that some universal flags like Not in ... don't work for all entities, even though they work for entities that aren't documented as having them in .fgd and .def files.

How hard would it be to do this without mods so i can use an existing mod that i have no source for? Or is it better to leave that to mods just in case someone used those flags on theirs? 

Unless I misunderstand, it seems like there are two issues with that idea. First, there will always be false negatives if a leaf is visible in a narrow sliver that falls between raycasts. I realize these can mostly be reduced by adding more raycasts but never eliminated. Second, leaf PVS has to be valid for all points within a leaf, while any raycast-based system will be treating the leaf as a single point (or a small number of points) 

...there will always be false negatives if a leaf is visible in a narrow sliver that falls between raycasts. I realize these can mostly be reduced by adding more raycasts...

I really don't understand this part, and it's second time around.

Why the fixation on raycasts?

I'm not talking about raycasts.

Forget about raycasts.

There are no raycasts. 

isnt a "sample" in a hardware occlusion query effectively a raycast? I admit to not knowing the tech behind it. 

Unless you raycast for each pixel or something? 

If, however, you assign a unique color to each leaf and render flatscale color into a buffer, then parse each render to see what colors are visible... 

https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_occlusion_query.txt

Occlusion queries use the depth buffer. Raycasts are absolutely nothing to do with it. 

In full HD, surfaces smaller than 7*4 pixels would be invisible. 

And raycasts, lots of raycasts. Whatever the fuck they are.