Portals vs. Hint brushes?

[AEon]

In SolarAE I have a very strange effect happening concerning vis. The whole window frame in the RA room (a relatively closed off room, well with 3 exists and one long "tubed" sky view), simply is not drawn when you exit the rectangular room. The vis compile must have been "confused" into thinking that the window is not visible from the outside, but obviously it is in the line of sight.

How can one "accidentally" create such an issue only using hint/skip brushes?

Portals in Q3?
That brings on another thought. The map would be relatively well suited to use portals (not triggered portals via doors), I was thinking about those used by Doom III. "You see portal, everything behind is is drawn", and only then. I don't remember, but was that possible in Q3A?

[AEon]

How can one "accidentally" create such an issue only using hint/skip brushes?

Seem two smaller hint brushes, one angled and one perpendicular intersected in the area of the window in a "bad way" creating that problem. Deleting the smaller hint brush "inside" the larger one fixes the problem. I am aware this does not really help anyone, but could the description hint at something one should never do with hint brushes? Very strange. Well now I can release beta 1 of SolarAE at least.

Comments on the Portals would still be of interest though.

[GONNAFISTYA]

You like yellow and orange?

Can you post some screenies of the in-game effect and a shot or two from the editor?

Perhaps a layout change is in order?

[AEon]

In the top/left corner you see the tube based TP (XY Top). I use an angled hint brush face, along the inside edge of the TP room (upper edge doorway) and pull it down into the RA floor, to cut off showing the tube above the TP, for most of the map.

A second hint brush face was placed in the doorway to the TP. Technically this would be how one places a portal in Doom III, not sure this actually has any use in Q3A, probably does not.

Anyway the angled hint brush reaches into the selected window. Outside the RA room (south in the XY Top view) everything inside that frame plus the frame is no longer drawn, you look right into the skybox.

• [lvlshot]http://aemap.hugelaser.com/misc/solarae_r83_vis_issue.jpg[/lvlshot]

I fixed the problem by deleting the small hint brush that covers the doorway to the TP.

[pjw]

Hints in Q3 have never worked with the predictability and efficiency of portals in later idTech. Placing hints has always been a bit of a "rolling dice while spinning in a circle" sort of thing.

For best results and least weirdness, hint planes should usually stay aligned with at least one axis. When you start angling them on more than one axis trying for a few more FPS in a bad spot, things can occasionally get weird. Actually intersecting hint planes is really just asking for abuse and ugliness, and tends to make Mr. Compiler go , as you have discovered.

I lack any actual technical explanations--only speaking from experience.

[AEon]

When I started hinting again I remembered that angled brushes (not just in one plain) were sorta evil. Interestingly the hint brush here does exactly what I wanted, only when you get really close to the TP do you actually see the tube above.

Something else I remembered was that 1024 unit grid used to cut portals into the map by default. SolarAE is a bit suboptimal in this respect because, the origin cuts through geometry in the map that does not profit by these cut. I.e. useless "doubling" of portals in that area.

I read somewhere that you can turn *off* (IIRC) the default behavior of cutting portals every 1024u into the map. Has anyone tried that? I am thinking of doing that, to reduce the unpredictable "chaos" these unwanted portals create.

The portal viewer is really quite a marvel, I went through the map looking around what portals are being created, and discovered a really nasty area in my deco grates on one wall. As it turned out it was a rock protruding the grate that was structural, but should have been detail (had forgotten to fix that). In other words, detail brushes are your friends ... as we all know.

I was looking for a tutorial that links sliding doors to "portals" (closed off rooms), but had trouble finding one, any suggestions?

[Silicone_Milk]

For sliding doors, I believe an antiportal brush is to be used rather than a hint brush. I don't have any links about that off the top of my head but I'm pretty sure it's floating around in one of the stickies.

[dONKEY]

You can alter _blocksize in worldspawn, either upwards or downwards to help control vis. As you say AEon, the default is 1024. I always found structural brush placement to be the first line of attack, followed by hint placement (not sure what you mean by angled brushes are evil...I thought faces with hints really needed to be on an angle, and seem to work best in pairs, kind of if face A can not see face B because of a structural brush, what can not be seen is culled. The third line of attack for me was then _blocksize, which was often quite useful for controling the silly Q3 sky bug where geometry in the same vis block gets drawn through sky brushes. I'm pretty sure in the pre-q3map2 days large terrain maps _blocksize would be increased in order to speed up compile times.
SM, I believe that would be an areaportal

[sock]

Portals and hints can be confusing because most of them are generated by the compiler based on the order in which the brushes are found in the map file. Some older versions of the GTK editor use to reverse the order of brushes in the map file on each save and that cause no end of problems because the portals would keep changing every save/compile.

Ultimately if you want to hint/portal map *the way* you want it, then use _blocksize 4096 4096 4096 on your worldspawn and create your own portal space. The compiler will still add portals even with a large blocksize but it will be easier to predict with structure alignment what the compiler is doing, than rather just pure guesswork.

One other option that is often over looked is the PRT viewer in the GTK editor, best Q3 tool feature ever for checking exactly what the compiler is actually doing portal wise with your map.

[sock]

I read somewhere that you can turn *off* (IIRC) the default behavior of cutting portals every 1024u into the map. Has anyone tried that?

I did this with my last map Mystic Gemini and got some really good results with odd angled hint brushes and portals being where I wanted them. You can download the source files if you want a quick look, I released most of the map files and editor textures you will need to view it. I used a really high _blocksize on the worldspawn and portal viewer inside of the editor to get the hint brush placement working how I wanted. Of course there are still some weird compiler generator portals happening but certainly not as chaotic as the default.

Here is a quick screenshot I took from the editor showing the manual portals for the central area:
[lvlshot]http://www.simonoc.com/images/design/maps_q3/mg_hinting.jpg[/lvlshot]

[AEon]

@dONKEY
What I meant was a hint brush face orientated just in *one* 2D-View, i.e. top down would be angles in the x/y-plane but not z-plane, that would typically be simply full map height.

@sock
Will try _blocksize 4096 4096 4096... alas that should not fix the portals created in the origin of the map, right? Will be using the PRT viewer extensively. Luckily, the bsp and vis compiles - even on my old hardware - a matter of seconds for this map, so by trial and error a lot optimization should be possible. And if nothing helps I'll change the geometry of the map

Patches and Hinting - somehow special?!
I noted a few weird vis issues in SolarAE's RA room that I had closed off, it should technically be impossible to see anything in the Quad arena now, when you stand at the SG - even with default portal generation - but almost all the tubes above the room and in the Quad area are still drawn, most of the geometry is not. My guess is that the window to the right of the TP, leaks up the the skybox area, and the grates up there somehow connect to the Quad area. But why is this primarily happening with the patches? Yes, they are grouped, and the grouped walls are also shown, but none should be directly visible. Will experiment with this, just wondering if this is some common, known issue.

Hide Hint Brushes with Skip faces?
As soon as you place a skip shader on the other faces of a "hint brush", GTKradiant no longer lets you hide those brushes... probably a well known issue, but was there a solution to this? I presently group all hint brushes, letting me select them all at once to then hide them.

[sock]

Hide Hint Brushes with Skip faces?
As soon as you place a skip shader on the other faces of a "hint brush", GTKradiant no longer lets you hide those brushes... probably a well known issue, but was there a solution to this? I presently group all hint brushes, letting me select them all at once to then hide them.

Editor filtering is done by shader name, use the following instead:

Code: Select all

textures/common/hintskip
{
	qer_editorimage textures/common/skip.tga
	qer_nocarve
	qer_trans 0.30
	surfaceparm nodraw
	surfaceparm nonsolid
	surfaceparm structural
	surfaceparm trans
	surfaceparm noimpact
	surfaceparm skip
}

[AEon]

Thanks, that shader was really something I had been hoping for, only I was guessing the filtering would only work on shaders named "hint" exactly. So painlessly elegant, *snif*

In PTR viewer, the _blocksize 4096 4096 4096 sure cleaned up some of the really weird areas I could not explain. Now I only would need to be brave enough to move the map out of the map origin... but with texture lock I may have issues later one when changing the geometry when trying to align textures without offset.

[obsidian]

You can disable blocksize entirely by typing in a zero value (note: for advanced hint users).

BTW, looks like you were looking for this (URL fixed in sticky links):
viewtopic.php?f=10&t=3620

[AEon]

You can disable blocksize entirely by typing in a zero value (note: for advanced hint users).

Will try that... awesome, _blocksize 0 0 0 indeed works, makes thinks so much cleaner to look at.

BTW, looks like you were looking for this (URL fixed in sticky links):
viewtopic.php?f=10&t=3620

Actually I read your tutorial a few days ago. It motivated me to use the PTR viewer more to check for "useless" cutups in the map.

Alas the only *real* way to check if the hint brushes are correcting the vis (along the line of sight) is to run around the map, with bind ALT "toggle r_showtris" turned on, and then to check, asking yourself: "Should I be seeing all that presently? Or shouldn't those brushes actually block all that stuff?". To then find some "line of sight" that cleverly cuts along the edges of the geometry.

I wonder if a "real world" application with examples would still be of interest. Presently I am actually getting exactly the results I am hoping for. Whee it's deterministic after all . But the tip is probably, to add one hint brush face at a time, compile bsp/vis, load map in q3a, check if it worked, if not think about it some more, etc.

[obsidian]

Someone edited the post in the links sticky saying the link was broken and I only assumed it was you when you were looking for threads. Anyway,

[AEon]

Ah, that was me... I had not know your tutorial was actually meant. Good that you fixed that.

Well I seem to be getting the r_speeds to around 10K in SolarAE almost everywhere, though a few weird areas (outer corners looking into the map) get to 14K briefly. The RA room is particularly "nasty", only with many hint faces do you get it under control somewhat... A direct line of sight into that room sure is an ugly thing.

[AEon]

For those interested how a "hinted" map looks, here SolarAE r96, I selected all the hint brushes. Not a pretty sight, but gets the job done:

• [lvlshot]http://aemap.hugelaser.com/solarae_r96_hint_brushes.jpg[/lvlshot]

In most cases it is enough to place the brushes, full height in the top-down (XY) view. r_speeds are below 10K now, almost everywhere.