Are fence textures on .mdl possible? 

I suspect you probably could make palette entry 255 a mask.

I assume this would come with its own problems, you can see through the other side of the model completely (as it wouldnt have a back-face) and would limit what you can do with it. Some models might use this colour as its a skin-toned colour. My guess is that the flame textures use it. So you'd probably have to redo some of the textures for certain models.

Maybe the engine would be able to recognise models that should be masked, perhaps using some kind of naming convention on the model? Is it possible that external textures could be compatible with models? You could create a number effects this way. 

No luck, still crashes on startup, I've got quakespasm already installed, do I need to download Mark V from the link on the OP? 

I'm thinking vegetation.

Imagine a modelled tree with branches, and a bunch of quads plastered on it with "fence" leafy bits and whatnot.

Also cross-quad grass billboards. That sort of bojangles. 

sounds like what you're actually looking for is lit sprites.

can we have lit sprites? only problem with that one is that most sprites are supposed to be fullbright, but sprites used for foliage and such need to be identified in some way to let the engine know to apply lighting levels to them. 

sounds like what you're actually looking for is lit sprites.

no, not really.

I'd rather have one entity to represent a big bush (hehehe) made of many quads all in one .mdl, than add 50 separate sprite entities - one for each quad. 

oh ok, when you said billboard, i figured you were just going to create a bunch of 2 tri models with a transparent texture on it. :P

but yeah, now that max edicts is 32k... doing leaves with sprites is doable.

whether or not it should be done is another question, but it might be work trying?

you could use qc to generate the leaves on certain parts of the model; would make it so trees look slightly different? 

It's an interesting idea but even if it is technically possible given a high enough max_edicts, the sheer principle of using one edict per vegetation quad makes my eye twitch. It just seems like we should be looking at more sensible/efficient ways of doing it.

Doing it with unlit sprites would suck anyway. 

actually, while we're dreaming... if we could get a bump up on the max number of static entities, we could make each foliage static and make it not use edicts at all! 

I guess to be fair the only way these sorts of feature requests get any traction is if there's already a bunch of well-made assets ready to go that a lot of people would use.

Making a bunch of quakesque vegetation models has been on my list for a while, so I might as well just start making them and then bully the engine coders into supporting alpha on them afterwards :} 

if we could get a bump up on the max number of static entities

It's actually quite silly for an engine to have a fixed-size maximum for these in 2016. Static entities can be just allocated on the hunk until memory runs out; don't need to come from a separate array at all. Likewise with efrags. 

hexen2 supports it. There's some model flag you can set that enables it (but tools may not provide you with that option, and might necessitate using some hex-editor).
afaik FTE is the only quake engine that supports it at this point in time, although if you're targetting DP, you can use shaders with some 'alphatest gt128' line or something, along with an external texture (iiuc an external texture alone will enable alpha blending, which will look a little ugly if they overlap).

#define MFH2_HOLEY (1u<<14) // Solid model with color 0
so byte 0x4E should be set to 0x40, assuming I counted correctly.


clientside limits on static entities are kinda silly (and implies wasted memory).
serverside limits on them due to the signon buffer size are harder to remove, although not impossible. 

Trying deleting your config.cfg. Are you using an old version of Windows like XP or something?

I made a couple of tough choices in very recent version that may affect old, old Windows versions. 

@Kinn - I think your ideas are interesting but at least for 2016 ericw/Quakespasm are where your best chances lie.

That being said,

Check this out:

http://www.celephais.net/board/view_thread.php?id=60502

That modified FitzQuake engine already has that feature, it's color 255. 

@Kinn: It's the trees with alpha masked textures.

Mod screenshot 

Kinn I guess what I'm saying: If you make a model with alpha masked textures and it works in that FitzKurok engine that I posted (you should be able to play with the model in that engine), ...

My recollection is the modification is not that difficult, but in the engine code for that model, the alpha masked model names are HARDCODED. i.e. look through the game data pak file and find the alpha model name (is it bush.mdl? tree.mdl? but whatever it is, use that name and there may be several).

The key thing is I would obviously not have the model name be hardcoded, so how to indicate a alpha masked texture? The quick and dirty version would be something similar to r_noshadow_list, r_nolerp_list or whatever those cvars are called and make a r_alphamaskedmodels_list or whatever would be a good name. 

a bunch of well-made assets ready to go that a lot of people would use

Sock has some really nice ones:

http://www.simonoc.com/pages/artwork/tp_plants.htm 

Baker - thanks very much for that! Looks interesting, I'll have a play with that :)

adib - sock's foliage assets are great for Q3, but I would want to be making stuff that fits in with quake's established chunky-pixel aesthetic. 

I might try deleting the config. 

Checking to see changes involved:

Engine modification requires:
1) Creating a color table for alpha masked textures (probably already exists since QS/Mark V both support this for the .bsp)
2) A method for specifying if a model's texture should be an alpha masked. (Sadly, since some rare models do use color 255 in them ...). Options cvar list var, external file, model name, somehow adding more model flags to a .mdl (like blood trail). Default option is probably creating a cvar with model names like the existing r_nolerp_list.
3) Checking such a model's texture for actual palette index 255 alpha masking, and if not disabling it.
4) Turning on alpha test during draw for specified models, then turning it off. Since GLQuake model lighting and FitzQuake overbrighting is just a color modification, no other drawing consequences.
5) Permitting external textures to have an alpha channel for models where alpha masking is indicated. 

Cheers, sounds reasonably doable ;}

2) I guess a list cvar fits in with the existing list stuff. To ensure that everyone gets the list in my mod even if quake.rc doesn't run (e.g. if someone loads the mod from the console), would it work if I did a stuffcmd from the QuakeC? 

I'd rather Spike suggest a better solution than the cvar list thing. ;-)

I hate the cvar list thing. Consider it an ugly placeholder until someone comes up with a better idea or a standard.

So consider the cvar list as a temporary placeholder until someone comes up with a great idea. 

Spike says something about a model flag that Hexen 2 uses above. Hmmm. 

I'd personally be down for using a new flag (like blood trail).

However that requires tools that would support it. It personally doesn't bother me in the slightest as I bang out .mdls from blender using a script that I can easily edit. 

For existing tools (QME) to conveniently work, I would personally opt for checking BOTH a rocket trail and grenade trail (selecting multiple trails is non-sensical in the engine, it only uses the first trail flag).

In model.c in model load, engine authors can just add a

if (model->flags & (EF_ROCKET | EF_GRENADE) == EF_ROCKET | EF_GRENADE ) model->flags ~= EF_ROCKET | EF_GRENADE, model->flags |= EF_ALPHA_MASKED;

A non-supported engine it's going to render horribly wrong anyway with pink everywhere.

This would allow QME to be able to edit the flag, instead of putting terrible burdens on mappers.

/One thought ... Spike said only FTE has a mechanism currently.