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. 

+1 for new scripting system
+1 for flexible HUD

Movable liquid volumes. Like turning a water brush into a func_door I could lift to flood an area. I understand that it envolves translating a volume where special physics and render takes place in runtime, but how hard it is to do?