I found some z-fighting under a table in one of the first levels in DoomIII.
What were you doing down there Loffy?? looking for loose change?
I found some z-fighting under a table in one of the first levels in DoomIII.
What were you doing down there Loffy?? looking for loose change?
Haha!
Or, maybe hiding? That game scares me many times.
(I’m playing the exp. pack “Resurrection of Hell” at the moment.)
But even that part isn’t true. It might have been true when the manual was written, but the compiler has changed quite a bit since then.
but the compiler has changed quite a bit since then.
He’s not kidding, if your map takes a few hours in q3map2 to compile, then you would be lookind at it taking the better part of a day (if not longer) with the old compiler.
Fast compile is a by product of good design and good build quality. If the maps not built well, then it still compiles, you just have to wait for it to sort of the poor instuctions it gets from the map.
A map that compile fast also runs fast, due to its efficient use of leafs and smaller better organized bsp.
if your map takes a few hours in q3map2 to compile
How can you get that? I mean… if u r not using bounce 8 or something.
For me the light stage always is the bitch.
A long VIS compile only shows that your structural work and hints are could be improved a lot. My VIS stage (and its not a -fast compile) is down to 2 mins or less for TheRiver II Redux (upcoming map) which has the same size as The River II.
And about overlapping brushes: I found out that its cool to have all structurals caulked but on the visible side of that structural brush I put a thin detail that only has a tex on the visible side. Its surface is on the same level than the caulked structural surface. Sure I get some “z-fighting” in radiant, but it makes the brushworking easier and cleaner imo (less tris AND a more clean VIS).
But even that part isn’t true. It might have been true when the manual was written, but the compiler has changed quite a bit since then.[/quote]
Oh, really ?
Well, I have felt that the rule applied to a map containing high brush count along with having overlapping brushes…because any small map compiles quickly either way.
So I compiled “Goldrush” with -meta and then I moved the 1st allied spawn section near the first tank barrier(to overlap alot of brushes), turn off ‘stop on leak’ and re-compiled with -meta.
Clearly this rule has it’s precedence…
Untouched map compiled;
--- EndModel ---
1088 light entities stripped
44694 BSP planes
--- WriteSurfaceExtraFile ---
Writing C:/Program Files/Wolfenstein - Enemy Territory/etmain/maps/goldrush.srf
Writing C:/Program Files/Wolfenstein - Enemy Territory/etmain/maps/goldrush.bsp
Wrote 12.5 MB (13071316 bytes)
367 seconds elapsed
Disconnecting
Connection closed.
With the 1st allied spawn section moved to “OVERLAP” other sections.
--- EndModel ---
1088 light entities stripped
44086 BSP planes
--- WriteSurfaceExtraFile ---
Writing C:/Program Files/Wolfenstein - Enemy Territory/etmain/maps/goldrush.srf
Writing C:/Program Files/Wolfenstein - Enemy Territory/etmain/maps/goldrush.bsp
Wrote 12.1 MB (12695364 bytes)
550 seconds elapsed
Disconnecting
367 seconds to 550 seconds…That is a 50% raise in compile time!!!
It follows the basis of the rule. It raised the compile time. It seems that it still makes sense in certain matters. :nag:
I d like to see the data of the VIS stage… or did u only move the detail brushes?
I didn’t save the data, I only pasted those portions of the log. Mainly detail were moved with the exception of a few structural.
Your test is far to uncontrolled to tell you much of anything. In particular it isn’t representative of any sane use of overlapping brushwork.
turn off ‘stop on leak’

:sigh: (again)the rule does not specify anything dealing with sanity…it deals with BRUSHWORK !
@Loffy,
:moo:
I should clarify a bit.
Overlapping brushwork may or may not cause longer BSP phase compile times, depending on the exact details. Overlapping brush work may or may not cause larger .bsp files, again depending on the specifics.
So the statement
It cannot be overstressed. If you want shorter compile times and small file sizes, efficient brush construction is “critical” in building your map. There is one rule that stands above all:
DO NOT OVERLAP BRUSHES AT ANYTIME.
Is completely misleading, and outright wrong in a large number of cases. In fact, ‘efficient brush construction’ is often achieved by the use of overlapping brushes.
The correct reasons to ways to use overlapping brushwork are:
EB:
I assumed the person asking this question was interested in answers that were applicable to real mapping. Certainly, you can create non-sensical examples in which the no overlap rule holds true, but that isn’t of any value to to anyone.
You keep telling yourself that buddy. If I didn’t do that dumb test…then you would have grossly mis-represented the rule. I gave it contrast. :moo:
He’s not miss-representing anything…you are. Your test is completely ridiculous and it has no relevance to any sensible or applicable mapping technique.
reyalP on the other hand is talking about actual proven techniques that work, and that should be used.
Anyone can cook up an example to disprove most of the “rules” out there. It would take me less then 5min to cook a test map and show that by overlapping brushes you can half your bsp size and compile times. So what does that mean? Should you now overlap everything so you can get more efficient maps? Of course not.
The point is that the manual is wrong about this issue and overlapping brushes, if used properly, can be extremely effective tools. They can be used to improve anything from vis and file size to the actual map brushwork. But you need to learn how and when to use them.
There’s absolutely nothing grossly miss-representing about that.
@wanderer
You misunderstand. I am not disproving the RULE or approving it. I am simply stating that it still has cohesive properties to mapping still. Why ? > Not everyone who jumps into mapping understands what “Proper” brushwork and “proper” mapping techniques are. If they did comprehend this off the starting block, then there would never have been a need to create the rule as everyone would have known to NOT OVERLAP brushwork and how to use detail and structural brushwork as well.
There is a learning gap that this rule has a point of representing and this is what I am trying to show. If you cannot understand what I am explaining…(there is no need to argue).
To a skilled mapper;this rule is of no-concern.
To a new mapper;this rule enforces stable guidelines as so they do NOT create a cluster-f^&* of brushwork. (a deterrent) Even if the rule does not hold as much water as it did before…it still has cohesion for the basis for which it was created and to ignore this or to deny it is obsurd. [AKA…it still holds water to an extent]
Also, to argue that I “cooked something up” is a strong insult as you have done nothing to disprove me besides state an opinion.
You chose to attack me rather than attack the rule to disprove my test…very remedial. [The test was not done for concrete results. It was made to add depth to the meaning of the rule.]
Afterall, it is hard for new mappers to deal with the learning curve. I am sent e-mails on a daily basis because some new mappers are too scared to be flamed in the forums because they don’t understand an entity or a model. I added the test to this thread to help those kind of mappers understand in the way they seem to understand best…by example.** Anyone can understand an extreme over-the-top example that topples the sides of the rule but not everyone can understand what directly is and isn’t ok by a few statements that generalize the situation to someone who has no clue as to what any of it means. My test gave it boundaries that are out of the ‘Norm.’ which lets them know how far they can and can’t go.
I have reasons forthe things I do. If you feel I have made a mockery of it, then it’s your opinion. Although I will guarantee that it will help the newer mappers create a mental picture of where the overlapping brushes rule draws the line.
-----There is no reason to argue as if your view is the “RIGHT” one, everyone learns in different ways. Black and white rules only go so far but with added examples…it makes the learning process that much easier to say “ok, this is what it is and this is how it acts”.
Please > Keep your insults to yourself. Also, may I ask to keep the assuming to a minimum ? There has been several ideas thrown into my corner…of which all have NEVER crossed my mind. I have NEVER SAID overlapping brushwork is a negative thing.(If I did, quote me on it) The presumptions about my P.O.V. are beyond belief…I believe I can speak for myself without 2 other guys trying to tell other people WHAT I THINK.
“Be careful of the words you say, keep them soft and sweet. You’ll never know from day to day which ones you’ll have to eat.”
P.S.
Exactly the point I am trying to make in my posts. I may explain it differently…but it leads to the same point. New mappers need to learn to use things…examples are the best tools for the new guys. If they cannot comprehend the use of proper mapping techniques or they have no idea of what the techniques are…they may run into a block in the road correlating back to this. Does this shed any light on this for you ? Not everyone has the same level of wisdom or the knowledge of how to do things.
We all have different learning-styles and EB did something and chances are that whatever he did might mean something to someone.
My test gave it boundaries that are out of the ‘Norm.’ which lets them know how far they can and can’t go.
All your test showed was that two different maps took different amounts of time to compile. This isn’t surprising, and it doesn’t tell us anything interesting. Nothing you posted gave any indication that it was the overlapping brushes which caused increased compile time (it might have, but your test doesn’t tell us.)
If you wanted to do a test that had some value, you would create visually equivalent brushwork. Cloning something simple a bunch of times should be enough to get the compile time up to something you can measure.
I still wait for wanderer and reyalIP to provide an example map of “effective use of overlapping brushes” 
ReyalP did offer up:
The correct reasons to ways to use overlapping brushwork are:
- non-drawing faces overlapping with at most one drawing face. This is usually either cliping, or ‘caulk hull’ style construction, which is in fact a method specifically developed to create more efficient .bsp files. Note that ydnar, the main author of q3map2, was one of the main people behind developing this technique, specifically to produce more efficient .bsp files for limited platfroms.
- decals overlapping other drawing faces.
- a few situations where visual problems caused the intersection or overlap of two drawing faces is the lesser of evils (embeddign irregular buidlings in terrain).
In fact, if you look at Detoeni’s sample map for caulk hulling, you’ll see that most his walls are overlapped caulk brushes, with only one textured face, so that the engine is only drawing brushes that can be seen. This is in contrast to mitering all of his walls.
Embedding anything in terrain tends to lead to overlapping brushes, where 1) it’s a pain in the ass to clip everything to eliminate overlap, 2) you create more tris/verts by cutting up brushwork to eliminate overdraw than you would save by simply letting it go.