jaydolan
Quake 2 Mapping Club
Posts: 161
|
Post by jaydolan on May 16, 2015 9:10:12 GMT -5
There are actually two preferences in GtkRadiant that can help with opening and saving maps authored in other tools: * Interface -> Editing -> Snap to grid -- TURN OFF if loading maps from other editors * Interface -> Editing -> Don't clamp plane points -- TURN ON if loading maps from other editors Yes, this is stupid, but it's 15 year old legacy garbage. These settings should reduce leaks when switching between editors. Interesting side note, SPoG (the guy who made that huge Q2 map you're talking about) actually worked for id Software for a while, and is responsible for many of the kludges in GtkRadiant (especially the 1.5 branch). I can't tell you how many times I have cursed his name when attempting to keep GtkRadiant limping along for Q2 / Quetoo. The brushes you create in the editor are only the first step in determining the actual structure of the BSP tree. For all practical cases, the number of brush definitions in your .map file is never the same as the number of brush structs written to the .bsp file. The number of "output" brushes, as determined by the compiler, is what is triggering the error you're seeing; not the number of brush definitions in your .map file. The reason for this is that the compiler, among other things, must split your brushes up into non-intersecting volumes. It's generally okay at this, but it's not perfect, and in any case, it will always output more brush structs than what your .map file defines. That's just the nature of the algorithm. This is why I asked you, giftmacher, if your brushes are overlapping a lot. Overlapping structural brushwork is a guaranteed way to generate more output brushes than you intended. The best way to combat this and to create clean BSP trees is to apply CONTENTS_DETAIL liberally. You may have seen a note or comment scribbled in a tutorial, or even in a source code file somewhere, that says " detail brushes never eat structural brushes." What this comment actually means is that CONTENTS_SOLID and the like will never be split by an intersecting brush of CONTENTS DETAIL. This is hugely important. Here are some screenshots of TRaK's crazy .map file (in-game screenshot above) in GtkRadiant. The first shot in each location is with CONTENTS_DETAIL filtered. Notice just how much of his geometry is in fact CONTENTS_DETAIL: there's a basic box structure for the visibility hull, but the rest of the map is CONTENTS_DETAIL. Area 1: Area 2: By doing this, he not only creates a much cleaner, minimal BSP output tree, he also greatly reduces the map's compile time and improves its in-game performance. Would you believe that this map, with all 7300 brushes, actually compiles in under 2 minutes for all 3 stages? Granted, my BSP compiler doesn't calculate indirect lighting; but still. Impressive, right? Take a look at his .map file. It's a great way to understand how to feed the compiler what it wants. Hope this helps!
|
|
|
Post by giftmacher on May 16, 2015 11:29:12 GMT -5
That is an interesting side note indeed! Makes me wonder how he managed to make such a map with the hardware of that day, I mean Quark lags for me on my modern PC when my maps become large enough. Turning off the 3D view I suppose is key For sure I'm not doing this perfectly, looking into a few things already, noticed my clip brushes was not detail!, as well as my water brushes and a few others I was able to spot. What is bugging me however, is that I pretty much used the approach that TRaK is doing (I got the idea from spirit and his .map files originally), making a solid layout as you say and then pretty much everything else is detail brushes. It just alerts me that this map crashes around the exact same brush amount as my messy contest map 'giftdm6'. Another example, before getting to the current giftdm8, I made 2 other attempts which I decided to scrap, one was constructed completely in solid brushes! And both this version (which got well over 1000 detail brushes) crashes around the same amount as my completely solid map. Making me think it has something to do with Quark, the editor/way of compiling. Here are two images from giftdm8, first one is the solid layout, the second one is with all the detail brushes showing: (It compiles in 15 seconds, although is it relevant since we are now on modern day PCs?)
|
|
|
Post by giftmacher on May 16, 2015 12:03:29 GMT -5
Also, you can't add anything more in terms of brushes, detail brushes does not get past this limit either, so it appears it has nothing to do with it being solid or detail brushes, just the amount of faces in general?
Edit: At 1755 brushes (according to .map, yea probably many more after compile as you say Jaydolan) adding just 1 more square detail brush produces "Error - Too many surfaces" in giftdm8.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on May 16, 2015 12:12:08 GMT -5
= About Max Brushes Q2 error =
- update- I have this problem a long time!, You can delay the error with a couple 100 brushes use flag detail & func_wall, and with smart mapping, use walls twice in corridors,design a good layout, rock wall in a func_group entitie.. but finally the error max brushes is coming for me when I approached bsp map size 4.5mb!.. - update-
Jaydolan mean well, knows a lot and have a lot of knowledge, but we're talking here about q2 max limit and Quark editor maximum possible!.
These below are Q2 facts & evidence, ( i think it is the quark editor that give this error )..
giftdm8.map ( Design In Quark ) bsp size 2.103.132 1768 brushes Max Brushes Q2 error 12305 brush sides
margaal21.map ( Design In Quark ) bsp size 4.459.372 1746 brushes Max Brushes Q2 error 13657 brush sides
margaal14.map ( Design In Quark ) bsp size 4.595.804 2057 brushes Max Brushes Q2 error 13715 brush sides
margaal28final.map ( Design In Quark ) bsp size 4.338.972 2153 brushes Max Brushes Q2 error 15834 brush sides
===================================
|
|
|
Post by giftmacher on May 16, 2015 12:28:36 GMT -5
Yea and I appreciate his help, just want to get to the bottom of this. Hopefully there is someone active on the Quark forum who might know. I could try and do some func_walls but this error is stoping me from making one last hallway-stair-connection in the map that would make it run better :/ 4.5 mb is a very big bsp I must say, but entities and everything else goes into that size. SPoGSP1 is 5,4 mb.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on May 16, 2015 12:37:57 GMT -5
Yeah Jaydolan knows a lot!...and I appreciate his help!.. But unfortunately , You can not ask any other Q2 mapper, because there is no mapper who go so far with their brushes in Quark editor, we are the only two.... want to get to the bottom of this. I already tried so many things.. skip or use little clip brushes in my maps..., because needed all brushes available.. or use litte light entities, instead use sky light, to remain under the 4.5MB..nothing works!. I am glad that this error also happens to you Giftmacher. But this means we have to fight soon...because i was the only Highlander... sooooooooo where is your sword!?. There Can Be Only One... Or or...join forces, and beat everyone!..
|
|
|
Post by giftmacher on May 16, 2015 13:00:11 GMT -5
www.youtube.com/watch?v=sqcLjcSloXs Indeed... Yea that is one way, try and open up as many areas as possible to sky light, all brushes used for light sources is quite a lot, especially if you want more than just the square brush with a light texture on it.
|
|
jaydolan
Quake 2 Mapping Club
Posts: 161
|
Post by jaydolan on May 16, 2015 14:10:27 GMT -5
func_group is an editor-only entity. func_groups are merged into the world model when the map is compiled. They are a convenience for mapping; nothing more.
func_wall is often abused in Quake maps, and it's a shame. By making static geometry (that is, func_walls that do not take damage and then break apart, or do not move), you're impacting the rendering performance of your map, and you're wasting an entity slot on the server. In short, don't use func_wall unless your wall is shootable, or moves, etc. It will do nothing to help these MAX_BSP_BRUSHES errors.
Everything I explained above, re: CONTENTS_DETAIL and the compiler, was relevant for Quake2 and Quetoo alike. My BSP format is 90% the same as Quake2's BSP format. The only difference is that my format adds two new lumps in order to calculate per-pixel lighting. Everything else (including MAX_BSP_BRUSHES and the rest) is exactly the same. So when it comes to splitting brushes, solids vs clips, detail vs structural, the two engines are identical. I can point you to the lines in the stock Quake2 BSP compiler's source code that handles splitting of brushes, if you like.
I wonder if Quark ships with a busted version of the compiler tool.. What if you download the Quake2 compiler that comes with NetRadiant and try that?
|
|
|
Post by giftmacher on May 16, 2015 15:58:43 GMT -5
Ok good to know about func_wall / func_group, got it. I did as you said and switched the compilers and it granted me some interesting results, as follows -> Quark with standard compilers qbsp3.exe arghrad.exe timvis3.exe 1755 brushes (according to .map file) = Error too many surfaces 1754 brushes (-1 brush) = Works -------------------------------------------------------------------------------------------- Quark with Gtkradiant compilers (Or well, the ones I got when downloading Gtkradiant 1.6) Qbsp3.exe (same as above but this is the .exe I got with radiant, so different file) Qrad3.exe Qvis3.exe [Errors] 1. Two leaks needed repairing. 2. Some texture and brush mis-alignment 3. Map is full bright, even with full compile 1754 brushes = Works - I added 5 square cube brushes - 1760 brushes = Works (!) -------------------------------------------------------------------------------------------- Finally to fix the lighting (I guess Qrad3 is for Q3? I'm a newb for gods sake Qbsp3.exe (Radiant one) arghrad.exe (Quark one) Qvis3.exe (Radiant one) Same errors with textures/brushes but lighting works with some lighting bugs here and there, but more importantly the map loads with 5 additional brushes. This was not possible with the standard setup of compilers. 1760 brushes, I have not gone beyond that so I don't know if this is a "fix" yet. I will do some more testing. But I'm guessing and asking you Jaydolan, is it/was it the Qbsp3.exe and/or timvis.exe shipped with QuarK that was broken? Margaal, do you have these compilers to test with?
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on May 16, 2015 16:18:53 GMT -5
Ok good to know about func_wall / func_group, got it. I did as you said and switched the compilers and it granted me some interesting results, as follows -> Margaal, do you have these compilers to test with? This Q2forum is messy and unclear, often the same questions again and again. so much time is lost... ( ADMIN please CLEAN THIS FORUM. Yeah I try different versions. tested endlessly...get a headache from it... The info is here on this q2forum, but can not find it sorry. ok ok you use a different compiler, this give some extra brushes, because it change the map size in kb. ====================================I use these compilers for years... arghrad.exe size version 270.390 ( can cause problems in different versions of Windows )..there is also size version 164.352 txqbsp39.exe size version 157.184 ( I've tried others )..no effect! timvis3.exe size version 106.564 i upload compile tools for you Giftmacher.. Here I add brushes in you map today, only 30 brushes in open sky, after compile ( Error ) ====================================You can try kmqbsp3.exe ( this give again maybe 200 brushes ). use Kmqbsp3 means only supported for Kmq2 Engine.
|
|
|
Post by giftmacher on May 17, 2015 4:04:05 GMT -5
Yes maybe it got lost throughout the years, that information, I searched for it or anything regarding "too many surfaces" error and didn't find much. I will see how many brushes I can add, if it's just 30-100 then it is not worth it and the problem is more complex.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on May 17, 2015 4:21:32 GMT -5
Yes maybe it got lost throughout the years, that information, I searched for it or anything regarding "too many surfaces" error and didn't find much. I will see how many brushes I can add, if it's just 30-100 then it is not worth it and the problem is more complex. It's not fun, searching again and again for info...there is so many info here on Q2cafe.. Forum should be neatly organized: - mapping setup editors. - mapping problems ( R_speed , flag detail, func_wall ). - Texture problems ( tex origin, tex scale, tex angles ). - bots. - textures. - maps. - models. - contest maps. here from 2010 my first mapping problem - has too many surfaces - .. leray.proboards.com/thread/2987/surfacesCompile tools home.insightbb.com/~gryndehl/q2compile/quake2.html
|
|
|
Post by giftmacher on May 17, 2015 4:56:24 GMT -5
Yes I've downloaded your compilers but first I'll try and hit the limit with these I got with Gtkradiant, then I'll try yours.
Edit: Yes should be more organized, it would be great to have a F.A.Q or a sticky thread with clean answers to all the questions asked throughout the years.
Edit: Ok hit the limit at 1779 with these compilers.
Edit: Same with the ones you provided there Margaal, crash at 1779.
That's a shame!
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on May 17, 2015 5:08:12 GMT -5
That's a shame yes, I hoped I was wrong about the compile tools. hmmm.......2015 contest margaal28final the bsp tool explodes, shifting walls.. SPoGSP1 map is a mystery.. Soooo conclusion is it must be Quark editor.
|
|
|
Post by giftmacher on May 17, 2015 5:15:53 GMT -5
Yes because I've used various approaches, some good, some bad, but all of them hit the limit around the same amount. A good mapping approach should award more than just 50 brushes (solid or detail, doesn't matter) compared to a crappy and careless one, I've used both! Edit: I posted on the Quark forum now Margaal, hopefully there will be some answers -> quark.sourceforge.net/forums/index.php?topic=1072.0
|
|