trisouping makes for really wonky slopes and ramps that are very awkward to walk on. collision with lots of strangely angled walls also feels very catchy and jagged. it looks nice but it works a lot better in quake3.

use flat floors, big ramps at compiler-friendly slope ratios, and lots of small steps if you really need to break up a floor with geometry. make your cliffs out of irregular hexagonal and pentagonal prisms (with the corners on-grid and the faces also on compiler-friendly slopes) and only slant the tops and bottoms.

you will be entirely forgiven (by me at least) if your rocks look a little "quakey" but have smooth solid collision. 

So you want to cast a shadow invisibly, like the Q on the ground in e1m5? If you're using a compiler which supports _shadow, you've probably thought of doing it with a func_wall that you then killtarget, or even hacking the entities in the bsp and deleting the func_wall. But there's an easier way! Instead of making the shadowcaster a func_wall, just give it the classname info_null, and the QC will remove it for you, no mess, no fuss. 

I liked the rocks in Daz' brimstone mapjam entry - they looking volcanic rock-like despite being angular and quakey.

Making really big lumps of strata looks good and doesn't leave you with micro-clip floor problems. 

Isn't it just a matter of structural irregular rock brushes touching the floor? Isn't it just a matter of making a whole cliff or at least its bottom a func_detail? Or func_wall, if my compiler doesn't support details?

@Lunaran

Shouldn't I just "caulk" my level in a Q3 style? I mean, make a jaggy cliff func_illusionary and cover it with clip brushes? That would separate the visual cliff from its collision.

About damage_inc question, can't I just fill my level with MDL props? 

I use to smooth player collision against really detailed walls using clip brushes. Any reason to not do it? 

definitely clip off detailed stuff always.

func_illusionary won't help you though, it's not solid to weapons so the player will notice right away.

mdl props are useful if they're small, but since they're vertex lit by the ground beneath their origin they're not useful for large things because they don't get shaded, so you can't make buildings or pillars or archways as big mdls. 

By that I meant when tiny invisible misalignments in the floor form overhangs that the player gets stuck on.

Typically these are the result of mathematical inaccuracy from the editor and/or compiler.

The player will only notice them when they're part of the floor, since that's what they touch the most.

So it's pretty much what Lun says - use flat or simple brushes for your actual floor surfaces, or at least the ones the player will most use to navigate your level.

And yes, make the entire thing _detail. It has two downsides - higher memory requirement for end user (you might need heapsize >64 !!!) and the compiler will crash if there are no 'normal' world brushes.

Clipping off details is good for both the player and Quake Ai, and has a negligible improvement for the speed of calculating the hulls I believe. 

I've seen that "microclipping" thing happen occasionally. Seems to be a problem with the clipping hull because the brushes will all appear to meet perfectly. Usually a well placed clip brush will fix it. I've never had it happen enough to consider it a major problem. 

Thanks, guys. And @ijed, it's possible to pick what will be detail and what will not. In a pillar, just that lower brush that touches the floor, for example, not the whole thing. That's how I used to do for Torque Game Engine. I assume it's the same principle for modern Quake? Sometimes a touched surface can split and it's not bad. 

Lunaran

You mentioned "compiler-friendly slope ratios". Is that just wordsmithing or is that an actual thing? And, if so, is there a reference somewhere? 

http://celephais.net/board/view_thread.php?id=3&start=8236&end=8240 

Yeah I know, it's just more convenient to make the whole thing one object and has no real downside. 

OTP - Thanks! That's useful, saved... 

The compiler splits the world up by radiating brushplanes outwards and cutting space with them, and if it picks a plane that's at some cockeyed angle the split it makes will intersect other walls and brushes in off-grid places. Walls, and vis leafs, will be split more often than is really necessary since intersections will rarely coincide with each other or with existing brushwork seams. Which is *technically* fine, modern computers and all that, but if you do this a lot you'll get a less healthy bsp tree. Vis will be shakier, and I think there's potential for microleafs and etc (someone like ericW can correct me on this voodoo).

Basically it doesn't make the map look a whole lot different to try to stick to 1:1, 1:2, and 1:4 but applied thoroughly it greatly reduces the odds of those really arcane compile errors, or a map with seemingly impossible to trace or fix vis errors like jam6_daz (once you start throwing little cylinders literally everywhere). 

OK, thanks. Yeah, I'm always awash in QBSP errors and VIS problems. 

Just to be perfectly clear: func_detail planes (or func_whatever actually) doesn't split the space, right? Making a func_detail is just the way to let a structural regular brush out of VIS compilation, is that correct? 

func_detail *does* split up the world. e.g. if you have a bunch of vertical columns as func_detail, they will split up the floor where they touch. The reason for this is Quake doesn't really support detail brushes, so they are compiled into ordinary world polys, except qbsp passes some extra info about them to vis so they can be ignored by the vis process. Also, func_detail shouldn't be used to seal the map - not sure why.

All of the other func_* entities behave differently - they're called "bmodels". They:
-are invisible to vis, like func_detail
-don't split up the world.
-are rendered in a separate pass by the engine. Some engines like fitzquake can get slow with very complex bmodels.
-they originally didn't cast shadows, but you can make them cast shadows with tyrutils by setting "_shadow" "1" on the entity.
-they take an edict slot.

So - long story short - if you specifically don't want to cause splitting of the world, use a func_wall with "_shadow" "1" set 

Now that func_walls can cast shadows, they are as close as you can get to Quake 3 detail brushes.

It's too bad they contribute to the 256 model limit. Is that impossible to change? 

You know that func_detail exists, right? 

I tried making all the beams, thin pillars, light fittings and small wall details on my map func_detail the other day and the compiler was just having absolutely none of it. (txqbsp or tyr's bsp) The brushes werent showing o the mp at all, it was like I had deleted the lot. It took me hunting for an autosave where I hadn't edited it yet to get it back to normal. Something I did notice was that when it did work on some wall text I added: whichever engine I was using to play (darkplaces or ezquake) with refused to draw it ater a certain distance. 

You know that func_detail exists, right?

Yes.

You know a func_detail isn't the same as a Quake 3 detail brush, right? 

oGkspAz,

In Quake, func_detail only has one real use. It excludes the brush from the vis process. This can greatly speed up vis if you have a lot of small brushes that do not really block the player's view.

My understanding is that they can cause the problems you are seeing when used to seal the map or if they protrude out into the "void".

I could be wrong though, because I generally don't use them. If I had a map that took more than a few hours for a full vis, I might reconsider, but I don't think they make the final result any better. 

"It's too bad they contribute to the 256 model limit. Is that impossible to change? "

This still exists? Even in expanded/enhanced engines? 

I'm sure it's not a hard limit anymore. FitzQuake will print a warning for over 255 models but the map will still run okay. I'm not sure Quakespasm even bothers with the warning. Maybe it's limited in the network code? 

Perfect, thanks.

Think I confused two "splits". Func_detail allows you to let brushes out of VIS computation, so they don't split (1) 3D space, regarding Binary Space Partition. But makes perfect sense their brushes still split (2) other brushes' surfaces, or the engine would have to know about them in runtime for proper sorting. In this case, shaded func_walls come to hand, but you better not abuse them.

oGkspAz are you sure you didn't just checked one of those "not in easy", "not in deathmatch" etc by accident?