the rbsp variant (and derivatives like fbsp) supports lightstyles (4 per surface, like quake).
and yes, 4 styles per lightgrid node too (it uses some compression scheme).
FTE supports them (if you've custom shaders then lightmap passes need to be first due to format weirdness), but dp doesn't.

(side note: it might be nice to calculate model lighting for the centre of each leaf, and interpolate between those, using surface data in place of neighbouring solid ones.)

even with q3bsp itself, you can get lightstyles with rtlights.
alternatively you can get quite creative with custom shaders. 

The problem with q3bsp is that i can't use TrenchBroom and Radiant is pathetic. :( 

Can you provide a screenshot of the light/shadow situation?

In Quake (when not going to q3bsp) it's pretty much not possible got get sharper shadow/light contrast than shown, e.g., on https://maikmerten.de/base1/randomscreens/happy-with-those-cones.jpg - all one can achieve is to make sure you don't get ugly stairs by using some advanced light options (in my case, for final compiles I use -extra4). 

The problem with q3bsp is that i can't use TrenchBroom
Does the compiler not accept q1 map format?

You could use the -convert flag on my qbsp (see http://ericwa.github.io/ericw-tools/doc/qbsp.html ) and hook that in as a compile step. You can convert vanilla q1 map to q2 (which I think q3bsp compilers accept). Or, valve to brush primitives, etc. 

In Quake (when not going to q3bsp) it's pretty much not possible got get sharper shadow/light contrast than shown
There is the "scale your textures up 2x and use texutre scale 0.5" hack that gets you higher resolution. Downside is it causes more qbsp subdivision of your level so the faces still fit in Software Quake's surface cache. 

Downside is it causes more qbsp subdivision of your level...

Would QS/QSS have any issues with that?

I don't think I asked this specifically in a previous post, if it has been answered already my apologies ;) 

It makes a mess of linear filtering.
Replacement textures should at least fix that, but anyone using the default settings+textures will find it looks a bit ugly.
Software renderers will have less mipmaps available (this also affects fte's r_softwarebanding).

note that you can also double the -subdivide qbsp arg too which will reduce the subdivisions needed.
QS supports up to (128-1)*16-precision. glquake actually supports up to (18-1)*16-precision.
FTE/DP/QSS(now) support up to (256-1)*16-precision. However that doesn't mean you must use lightmaps that big, as it kinda makes a mess of the lightmap allocator resulting in excessive wasted space, with more texture switches/batches (doubling won't hurt much though). 

It's been awhile!

I remember coming here when I was just getting back into Quake, and was trying to learn to map.

Anyway, I need some serious help. I've been working on a dm6 remake with modern geometry, and some extra tricks to do for ease of movement. I had to come up with a way to make circular polygons, which turned out great (map features 16 sided polygons for some rooms).

This map is meant for competitive play in ezquake, and so far people have thought I've done a pretty good job. However, there is a problem with it, and it's the performance stability. After a bit of digging and talking to Spike, we identified the issue was overdraw with the entities. This can be proven by going to the worst spot in the map, disabling entities, and watching your fps go way up (tested in ezquake).

When talking to Spike, he told me of Hint brushes. He tried explaining how I would use them to make my map more efficient, but he arguably did a horrible job, and I'm still lost in what I am supposed to do with them, and where to put them.

So, as a final call to help, how the hell do I use hint brushes?

My map: http://www.mediafire.com/file/kod7fj4yod745wv/dm6_pro.map

Ignore the texturing, no one ever uses them anyway in the competitive scene. I used a self discovered way to make circular polygons in trenchbroom, but I'm sure many know how to do it. If not, I will be happy to share how I did it. 

You could also just post a map that uses them effectively, and I can try to figure it out by example. I have some knowledge in how vis portals work, but I obviously don't know enough. 

Editor screen please, top view 2d.

https://developer.valvesoftware.com/wiki/File:Hint_example6.PNG

https://developer.valvesoftware.com/wiki/Hint_brush 

Hint brushes force a new cut when the compiler is creating vis portals. It won't magically hide stuff at point A from a player at point B, if point A really is visible from point B. However if point A is actually hidden from point B and the default vis portal creation is not recognizing that, then adding hint brushes can help.

In addition to Qmaster's link, here's another:

http://omnicide.razorwind.ru/wiki/index.php/Tutorials:Understanding_a_VIS_and_Hint_brushes

My little summary (and that link) is going from what I remember about Quake 3... if Quake 1 hints differ in some way then hopefully someone else can elaborate. 

IMO, don't bother with hint brushes until you have established that qbsp is making a bad decision in a particular spot. I guess you could just preemptively apply them and hope it works, but I doubt it will do anything.

First run in Quakespasm with "r_showtris 1" and post a screenshot from the slowest position. Maybe post your fully compiled (qbsp + vis + light) bsp as well.

Also check Darkplaces with "r_drawportals 1" - this will draw the actual BSP portals (the boundaries between leafs), which are what you would be trying to influence with hint brushes. 

I just looked at the map, compiled it, it shouldn't be any slower than the original DM6, the e-poly seem really close to DM6, and the visibility is fine. I'm really surprised anyone would have performance (and stability?!) probs with it, and I doubt hints will help so much (could probably optimize some of the hallways a tad, having the main arena appear a bit later but it really wouldn't change much). 

I aggregated some questions regarding how to pull off certain effects. I'd like to use unmodified id1 progs.dat, which makes certain things difficult or impossible, I guess, but perhaps I'm just not aware of some nifty tricks.

- some maps nowadays have transparent grates. I guess this is a new-ish engine feature (QS? FTE? DP?). I haven't had luck googling around on how this works - can somebody point me to some documentation?

- there doesn't seem to be a straighforward way to embed a .mdl in a map with id1 progs.dat - but is there a hackish way?


-I'd like to do an arena fight with a pentagram on the floor (that's the simple part). As the fight progresses, I'd like flames to ignite at the corners of the pentagram. When all five corners are ignited, the player is transported to a demonic realm (teleport or changelevel). As far as I know, light_flame* can not be toggled on/off. Of course, I can put standard light entities there an toggle then on, but then the question remains on how to make the flames appear. Ideas? (if this cannot be done, I can still change the concept to, e.g., have pillars with demonic symbols raise instead at the corners) 

- some maps nowadays have transparent grates. I guess this is a new-ish engine feature (QS? FTE? DP?). I haven't had luck googling around on how this works - can somebody point me to some documentation?
The last color of the Quake palette- that's the kind of funky pale pink one at the end of the last row- is defined as transparent when used in 2D UI/HUD elements, i.e. the main menu or the (in)famous light_globe entity. In engines that support the feature (alpha masking, fence textures, whatever you want to call it), that same transparency is applied to 3D stuff as well- entities and world geometry. It's as simple as using that color in the areas of the texture you want to be see-through, and adding a left curly brace- that's the pointy parenthesis, {- at the start of the texture's name to tell the engine it has transparent bits, similar to * for water or + for animation.

Two things to keep in mind, though- one, textures can only have one leading character so you can't have a curly brace and a plus sign, meaning no animated-textures-with-transparency (probably possible through a really complex set of cycling doors or something, but generally not worth it), and two, the texture has to be used on a brush entity like a func_wall or func_door or else you'll get unsightly grey or hall-of-mirror-effect areas where parts of the world are cut away from compiling and you can see through them into the void. ericw's tools include multiple entities specifically for this purpose (func_detail_illusionary and func_detail_fence), as well as a handy entity field called _mirrorinside that makes those two types of entities automatically have their textures mirrored to the insides of the brush, meaning an infinitely flat, two-sided fence texture (i.e. Doom style fences) is done by just making a func_detail_fence, adding the mirror field, and applying the skip texture to every outside face except the one you put your fence/grate/whatever texture on. 

And in case you mean glass, just add key of "alpha" and a value between "0.0" and "1.0". No quotes of course. 

alright, I will try that. Darkplaces actually runs the map fairly stably, which is another reason why the ezquake renderer needs to be redone. There are plans to do that.

Introducing `-forcegoodtree` helped the performance by quite a bit, but those slow spots are still apparent. I don't feel or mind them, but apparently other players will, and will cause my map to be depreciated.

I can't exactly give data right now, I'm on a trip. However, I will get back to you through email when I do. I will post my fully compiled map here as well.

It does seem to be caused by entities. When disabling them in the renderer, I get a stable 1300 fps around the map in ezquake (AMD card on linux, which is why my performance is lower than usual, others get way into the 3000s and are affected a lot less than me). With them on, I get the slow spots in ezquake.

@Bal

That is true that the performance is similar between dm6, but one of the things I wanted dm6pro to be is better than the original dm6 in every aspect, including performance. If I'm able to improve it, I will. Also keep in mind that there are people in the competitive community that do notice this stuff, but I honestly think it's a buncha bs most of the time. They all play aerowalk, which has similar "slow spots."

This is also an issue with ezquake, so that's introduced as a problem. Since that's the current engine that competitive players use, I will have to design the map around it. I think it actually may have to somehow do with how inefficient ezquake is at rendering entities, but that's only a theory. It's definitely correlated by my tests.

@Qmaster

Again, I will try to get back to you on that.

-----

Thanks for the great initial support, never got that here before.

On the side, do any of you actually like it? I've been trying to get opinions before I hand it up to the higher players. 

Now that's how to answer a question in mapping help. I've used fence textures once before but I just learned how to do it properly. Cheers. 

Thanks for your comments, this is very helpful! 

Took a peek at that valve documentation, really helped me understand how I actually need to use hint brushes. I doubt they will help, but they might do something. 

When you say that people are complaining about your map's performance, is it "bad performance" in the sense of "only a thousand frames per second instead of ten thousand"? Or is it a performance problem that could actually be noticed without watching an FPS counter?