There were reasons about a decade ago, but in 2019, there are none. 

There's still the lighting issue, models don't get lightmaps, they just sample the light value of the surface under their center, so depending on context they will look out of places with the rest of the lightmapped brushwork. Would use them alot more otherwise.
These pine trees are pretty cool though, and the animation is obviously only possible with models, but they work cause it's dark ambient lighting. If you had very directional lighting they could look quite weird.
Pritchard is doing some cool stuff with palm trees and having them as brushes really helps integrated them into the level. 

Is there any reason to not go crazy using models?

It depends. In terms of raw polycount, not really. If you had, say, a forest of animated trees, then you'd see a perf hit, mostly from the vertex animation. The transparency might be a bit of a hit as well.

It would be rather difficult to get nice model lighting using qbsp. You'd basically want to bake all that onto the texture and account for the uniform shading.

You have more flexibility with q3map2 since models can lightmapped or vertex lit (using the lightgrid) on a per-model basis. both methods can looks great. 

There's some chat about this very issue in the quake engine wishlist thread here:
http://www.celephais.net/board/view_thread.php?id=61737 

Doesn't FTE already use vertex lighting on models?

Of course i could be wrong, but there is a "vertex" mode in the lightning menu/options. 

Would anyone happen to know if this model has ever been released?

https://www.youtube.com/watch?v=LTE_9TXY51E 

I would like some advice for this model.
I am tweaking with the framespeed of the forcefield static.
I added a {self.nextthink = time + 0.01;}; option to the frames,
as I thought the framerate is too slow.
Now I'm not sure if it works allright, as I've seen it switching from end to start.

Also I'm searching for an option to toggle the static.
Now it is coded as killtartget, but I would like the toggle option more.

screeny
forcefield 

Why using tons of triangles instead of alphamasked textures?

An alphamasked MDL can do the trick of morph-target animating tons of pseudo-particles using only a few triangles. You can even combine it with skin animation. 

I'm using it for an old mod and I'm not costumed to alpha channels.
Once made a lightning static with an alpha and a sprite.

I thought combining it with an alpha mask could enhanced it, but was not sure how to do it.
I saw the Pine trees from Redfield, but was tricked with the alpha thingy. 

not sure how to do it.
Just paint the transparent areas of the skin with the color index 255.

Some engines also requires a special pointless flag to be set in the model. 

Backwards compatibility isn't pointless. 

Using a func_illusion, added the texture after skip brush results in this.

Working with alpha's make use of *.tif and *.psd. And that are not the usual import values for qmle. Bmp won't work so I don't know what it is. 

 

pcx

No use, I don't know how redfield made it but I see no way to import an alpha channel in Qmle or Q2Editor, or Noesis. 

mankrip - the assumption is that some existing mdls will be using index 255 as opaque colour, before this whole mdl alpha thing was ever conceived. 

Please tell us what engine you are using. You know that mdl alpha only works in a few of them, ya? 

Quakespasm_AD. Pinetrees of Red field run fine. 

I've never found any MDL that uses color 255 as opaque.

This "backwards compatibility" thing was inspired by problems such as GLQuake-targeted maps using fullbright color indexes in textures by mistake.

However, in the vanilla Quake palette, there's no risk of color 255 being automatically selected by any program because its RGB values are exactly identical to those of another color that's located earlier in the palette. Color 255 is a duplicate color, and any color selection algorithm will pick up the first occurrence of that color. Color 255 is ignored.

The only ways to select color 255 by mistake is by using a modified palette for conversion (which is dumb), or by manually selecting it instead of its earlier occurrence in the palette (which is also dumb). 

You're assuming that everybody's pipeline is identical, and that you've seen every single MDL that was ever created. 

That's pipeline-independent.

The only reason to use a modified palette with a non-duplicated color 255 is to make it easier to create textures with transparent texels. Using a modified color 255 for opaque textures is dumb.

Using the default unmodified Quake palette will never result in undesired transparent texels. It's not about the pipeline, it's about math. 

This is one of the pine trees skin: https://cdn.discordapp.com/attachments/180367751813005314/605044265093038100/skin.BMP

I could be wrong on this but, you are not assigning an alpha channel in any model editor. As stated above you just USE the garish pink color(255) in your skin?

The engine will know what to do. 

Using the default unmodified Quake palette will never result in undesired transparent texels.

This is, again, assuming that every image editor will use the exact same algorithms in the exact same way.

The amount of times I've been burned this way is countless. 

The method I used to set index 255 as transparent is to set flag 'MF_HOLEY' or bit 0x4000, or flag 16384 in normal speak.

Without this bit, Quakespasm will not mask index 255. So far, QS 0.93 is the only 'out of the box' engine I have been able to see support for this. Older DP builds and FTE don't mask 255 on these models, where QS does. MarkV fails to properly mask 255 when other full-brights are present, where QS does not have this issue.

In order to set this flag I use Preach's home brew qmdl Python plugin. Import qmdl Helper and set the mdl flag as outlined in Preach's guide. You could set this flag in QMe under model Properties-> flags, however saving any model in QMe will break smooth shading across seams. So if you shade normals smooth in Blender, QMe will break them, qmdl will not and is the best approach to set this flag. 

But that sort of argument really doesn't wash. It's all jolly beans until you find that one obscure mod with all the bollocked skins. Back in the day it would be pretty common to be painting in indexed colour right from the start, instead of converting from a true-colour image, and we have to assume that others in the past may have picked index 255 just because they can. I know we're just jacking around with Quake as a hobby and this isn't a serious production environment, but a little bit of effort to catch these very possible compat issues is the right approach. 

Here's a positive case for using individual particles instead of alpha when it comes to force fields

https://tomeofpreach.wordpress.com/2012/11/18/forcefield-smoke/

It's easier to see in an engine with interpolation than in the animated gif, but each particle has an animation as it fizzles out on the boundary of the field, stretching vertically as it collapses horizontally. I don't think you could achieve the same effect with any fewer polygons if you used alpha masks.