Can't be func_walls, because if that were the case it wouldn't have ever looked correctly, not in WinQuake, and not in GLQuake.
Must be plain worldspawn. 

#32086: coplanar polygon overlapping simply does not exist in the BSP format. Polygons in a model can only be overlapped by the polygons of different models, and for that to happen they must be used in different entities.

dumptruck_ds: does that also happen in this version of Beyond Belief? I'm going to take a look into that later. I know the old release runs in WinQuake, but the newer wip version should run in MarkV WinQuake. 

Also, Z-fighting in the worldspawn model simply does not exist in WinQuake. func_walls does look correctly in it no matter how much polygon overlapping there is against the world model.

As I said, WinQuake clips func_wall polygons against the world polygons in worldspace, killing any overlapping against the world. 

Well yes, coplanar worldspawn brushes will just leave either one face or the other after compiling, that is my point. Either the compilers or the brush order must have changed.

In WinQuake, overlapping func_wall would have been invisible, i.e. the opposite of the desired result. Since it used to look right, it couldn't have been a func_wall. 

A significant percentage of what people want can be achieved by just using the Q2 BSP format. Of course that brings in other things that people don't want, such as storing textures outside the map.

Some of these features were discussed when designing BSP2, but in the end the overriding priorities were ease of implementation in existing codebases and keeping compatibility with the original .map file format. The fact that BSP2 succeeded vindicates this, but I still regret not including a Q3A lightgrid lump.

I need to look over how software Quake clips brush models again. It's been a while but my recollection is that it's not actually that simple, and may have dependencies on faces being converted to spans before it does the clipping. 

Case in point; ladders and rotating brushes. Quake 2 got ladders right on its first try 25 years ago, yet AD has those godawful sticky catapult deathtraps.

AD has 3 ladder systems;
1=Rubicon2 (sticky + jump upward only movement)
2=Extra4 (player facing direction for up/down movement)
3=FTE (uses skin key, works like extra4)

The reason most people use the rubicon2 system because its easy to implement, the source is available and most people understand it straight away (ie don't fall off ladders and die) Probably the best system is the FTE skin system (closest to Q2) because its engine controlled and not hacked by QC progs to fight the engine physics.

I have pestered eric to add rotating brushwork support to Quakespasm for years and at this point I think everyone has just given up because the chance of it breaking something else in the engine is too high! With no universal engine solution everyone just accepts the shite QC Hipnotic version instead. The RMQ and DP/FTE versions are very good, but to really make a difference it needs to be added to the core (QS/Mark/Fitz) engines to really be adopted. Ideally it should be a declared feature so that progs can switch around rotation types.

PS. Tried to login properly, but can't remember password anymore. I had to reply to the AD jab from Text_Fish because there is a lot of history to the reasons why stuff is the way it is! 

nathnolt has the best ladder. In bsp. He let me use it in the map I just released. I used it in 2 places. One place is the courtyard at the start. You just walk forwards, and you convincingly bounce up the steps, one at a time, at a believable speed. 

I need to look over how software Quake clips brush models again. It's been a while but my recollection is that it's not actually that simple, and may have dependencies on faces being converted to spans before it does the clipping.

I don't remember the exact order, but here are the steps:

First of all, the server uses VIS data to determine which BSP entities may be visible to the client.

The engine clips all visible BSP entities' polygons against the world. Somewhat similar to selecting the world in a map editor and using the "carve" function. This is what eliminates coplanar textures in software Quake.

Frustum clipping also clips the BSP polygons, this time against the frustum.

Spans clipping is the last step in vanilla software Quake. It clips the spans of the resulting polygons against each other in screenspace, ensuring zero overdraw and eliminating most of the need for a depth buffer.

Z-buffer checks clips the polygons' spans on a per-pixel basis, and is only done by custom engines with features that requires overdraw (semitransparent water, colormasked textures, etc).

Vanilla Quake's source code makes things confusing because the worldspace "carve" clipping, the frustum clipping and the screenspace spans clipping uses very similar terminology in the code. There are lots of "edge" clipping stuff in the comments with no mention of screenspace and/or worldspace. 

In WinQuake, overlapping func_wall would have been invisible, i.e. the opposite of the desired result. Since it used to look right, it couldn't have been a func_wall.

Good point. Maybe, for some reason, that worldbrush was now converted into a brush entity by either the map editor or the BSP compiler. Comparing the current map sources against the map sources of the original release may give a clue.

Also, r_drawentities 0 helps to identify which brushes are part of BSP entities.

If the coplanar polygons are still present with r_drawentities disabled, there's something really broken in the BSP file. 

If this was an endurance excercise to see who can keep guessing the longest without opening TB and actually testing it, I guess I lost.
No but seriously though, there's no need for some rogue brush entities when it's simple qbsp. I think I got it right in #32075, then metl agreed, and then dumptruck never responded.
Like this. Note that TB doesn't consider brush order to be significant, while compiler clearly does. Case solved? 

I thought you were talking about a problem that happens when actually playing the map. What happens in the video you've shown is normal behavior, with the resulting BSP having zero polygon overlap.

At 0:26 the small brush appears because the big brush was carved by the BSP compiler to make space for the small brush. There's absolutely no overlap happening in the engine.

Brush carving order during compiling is up to the compiler, and can also be completely random. There are no rules for it in the map spec. This is why map editors have a "carve" feature, so the mapper can manually define which brushes should be cut to make space for other brushes.

Developers shouldn't rely on undefined compiler behavior. This is true for both programming and mapping.

There are many ways that undefined behavior can go wrong. For example, nothing guarantees that when copying & pasting multiple brushes the order between them will be the same. And afaik, there are zero editors with an option to display the brush order. It simply shouldn't be relied upon. 

This reminds me of when Abrash mentioned that despite out-of-order execution making CPUs much faster, it became impossible to predict exactly how many cycles a function would take to execute.

With multithreading and many other optimizations in modern BSP compilers, I wouldn't be surprised if the brush clipping order became completely unpredictable. EricW has much more in-depth knowledge about this than me, maybe he can give a better answer. 

Two things. Matthais hasn't been back to the Discord so no need for me to follow this any further.

I saw your reply and metl's follow up. Thanks! GOod info and great illustration.

P.S. Log in FFS. 

https://lvlworld.com/review/id:2339 

I made this other account called "Mopey bloke" with space. I no longer have that passphrase. If you want, go ahead and delete that please. 

https://www.einpresswire.com/article/561032975/new-research-modernist-architecture-may-be-bad-for-health 

Discord is down, time to party like it's 2002!

But seriously, it's a good thing the community is distributed. 

 

 

 

...to assist in updating map releases.

Here's a post with some updated requirements that will make adding your maps to the database a bit more streamlined. There's much more info there but here's a TLDR version:

Here's a template for people to copy and paste for future release posts here. Replace the example placeholder with your own data.


MAP TITLE
example -- "Subterranean Library"

MAP AUTHOR(S)
comma-separated list of everyone who made levels in the release... example -- "ChrisHolden, Greenwood, Grue, Heresy, ionous"

MAP AUTHOR HOMEPAGE OR PROJECT URL (optional)
example -- https://alkalinequake.wordpress.com/

EXTRA LINKS (optional)
one link per line, format is (title)|(url)... example -- "ModDB|https://moddb.com"

MAP SIZE ESTIMATE
are these small (~5 minutes), medium (10-15 min), or large (20, 30+ min) levels? help players budget time and expectations

SHORT DESCRIPTION (1-4 sentences)
How many maps? Do they form an episode? If it was a map jam, what were the constraints? What map themes or styles? Any custom weapons or textures or monsters? What mod kit did you use, is it already included or downloaded separately?

TAGS (optional)
Comma separated list of Quaddicted tags. Common tags: "small, medium, large, medieval, wizard, base, slaughter, ad, copper, makkon"... see tagging policy here https://www.quaddicted.com/help/tagging_policy

SCREENSHOT URL
link to a 1024x768 JPG that's under 300 kb + isn't too dark + shows at least one main area


Note: we still might edit or clarify your data, or take a new screenshot if it seems misleading, etc. 

https://youtu.be/-VQRBvJ8sB8 

 

The map I posted about in screenshots is finished, Im waiting for it to be uploaded on Quaddicted so im just gonna post it here.
https://www.quaketastic.com/files/hydromadness.zip 

News thread created here: https://www.celephais.net/board/view_thread.php?id=62162