Another MAX_EDGE_LINES issue


(Zeke) #1

Hello,

I have been searching extensively for a solution to a problem I am having with compiling in the BSP phase. I am getting the MAX_EDGE_LINES error and the compiling terminates after trying to fix the TJuncs.

I have attempted to debug my map ALOT and removed alot of thing to try and narrow it down to an invalid brush or something like that.

I have been working on this map for JK:JA (JK3) for a few months now and it’s grown in size.
I have used Bobtoolz to see if there are any issues there but to no avail.

I have removed 3 areas of terrain and more, all point entities were removed with the exclusion of a player start point. I have also tried increasing the block size all the way up to 8192 but with no change on that part.

I’m at the end of my tether here and I can’t afford the soul destroying feeling that the death of this map will cost me.

Brush count before all the deletion was just over 25,000 brushes and some 1000 or so point entities.

The map is big, I’ve made sure to keep my brush work clean.


=== running build command ===
"C:/Program Files (x86)/GtkRadiant 1.5.0/q3map2.exe" -v -connect 127.0.0.1:39000 -game ja -fs_basepath "D:/Games/Jedi Academy/GameData/" -fs_game base -meta "D:/Games/Jedi Academy/GameData/base/maps/zeke_ih_d.map"
Connected.
4 threads
Q3Map         - v1.0r (c) 1999 Id Software Inc.
Q3Map (ydnar) - v2.5.17
GtkRadiant    - v1.5.0 Apr 26 2007 19:01:46
Last one turns the lights off
--- InitPaths ---
VFS Init: D:/Games/Jedi Academy/GameData//base/
VFS Init: D:/Games/Jedi Academy/GameData//base/

--- BSP ---
Creating meta surfaces from brush faces
entering shaders/shaderlist.txt
entering shaders/shaderlist.txt (2)
entering shaders/shaderlist.txt (3)
entering shaders/shaderlist.txt (4)
entering shaders/shaderlist.txt (5)
entering shaders/shaderlist.txt (6)
entering shaders/shaderlist.txt (7)
entering shaders/shaderlist.txt (8)
entering shaders/shaderlist.txt (9)
entering shaders/shaderlist.txt (10)
entering shaders/shaderlist.txt (11)
entering shaders/shaderlist.txt (12)
entering shaders/bespin.shader
entering shaders/bounty.shader
entering shaders/byss.shader
Script file shaders/cairn.shader was not found
entering shaders/common.shader
entering shaders/danger.shader
entering shaders/decals.shader
entering shaders/desert.shader
entering shaders/doomgiver.shader
entering shaders/factory.shader
entering shaders/flares.shader
entering shaders/fogs.shader
Script file shaders/h_evil.shader was not found
entering shaders/hoth.shader
entering shaders/imp_mine.shader
Script file shaders/impdetention.shader was not found
entering shaders/imperial.shader
entering shaders/jnegretetest.shader
Script file shaders/kejim.shader was not found
entering shaders/korriban.shader
entering shaders/models.shader
entering shaders/mp.shader
Script file shaders/narshaddaa.shader was not found
Script file shaders/nar_streets.shader was not found
entering shaders/quicktrip.shader
Script file shaders/rail.shader was not found
entering shaders/rbettenbergtest.shader
entering shaders/rift.shader
Script file shaders/rocky_ruins.shader was not found
Script file shaders/rooftop.shader was not found
Script file shaders/sandcrawler.shader was not found
entering shaders/siege.shader
entering shaders/skies.shader
entering shaders/stu.shader
entering shaders/system.shader
entering shaders/taspir.shader
Script file shaders/tests.shader was not found
entering shaders/ihz.shader
Script file shaders/ihz_terrain.shader was not found
entering shaders/vjun.shader
entering shaders/wedge.shader
entering shaders/yavin.shader
entering shaders/epiphany.shader
entering shaders/white.shader
entering shaders/black.shader
Script file shaders/Characters.shader was not found
entering shaders/test.shader
entering shaders/metashader.shader
entering shaders/sprites.shader
entering shaders/cinematics.shader
Script file shaders/vader.shader was not found
entering shaders/cheshire_vader.shader
entering shaders/tattva.shader
entering shaders/xmas.shader
     2060 shaderInfo
--- LoadMapFile ---
Loading D:/Games/Jedi Academy/GameData/base/maps/zeke_ih_d.map
entering D:/Games/Jedi Academy/GameData/base/maps/zeke_ih_d.map
Entity 0 (worldspawn) has lightmap scale of 1.0000
    17128 total world brushes
    14511 detail brushes
        0 patches
    13491 boxbevels
     1609 edgebevels
       23 entities
    22530 planes
        0 areaportals
Size: -14600, -7576, -4104 to  6152,  1928,   696
--- ProcessDecals ---
        0 decal projectors
--- CreateMapFogs ---
        0 fogs
############### model 0 ###############
block size = { 8192 8192 8192 }
BSP bounds: { -14600.000000 -7576.000000 -4104.000000 } { 6152.000000 1928.000000 696.000000 }
Lightgrid bounds: { 99999.000000 99999.000000 99999.000000 } { -99999.000000 -99999.000000 -99999.000000 }
--- PatchMapDrawSurfs ---
--- FaceBSP ---
    15503 faces
     7951 leafs
--- MakeTreePortals ---
      207 tiny portals
        0 bad portals
--- FilterStructuralBrushesIntoTree ---
     2619 structural brushes
     3865 cluster references
--- FloodEntities ---
     1419 flooded leafs
--- FillOutside ---
     3769 solid leafs
     2763 leafs filled
     1419 inside leafs
--- CullSides ---
     1785 hidden faces culled
      312 coincident faces culled
--- ClipSidesIntoTree ---
--- FaceBSP ---
     3890 faces
     2276 leafs
--- MakeTreePortals ---
      223 tiny portals
        0 bad portals
--- FilterStructuralBrushesIntoTree ---
     2619 structural brushes
     4916 cluster references
--- NumberClusters ---
      900 visclusters
     2073 visportals
     4077 solidfaces
--- WritePortalFile ---
writing D:/Games/Jedi Academy/GameData/base/maps/zeke_ih_d.prt
--- FloodAreas ---
        8 areas
--- AddTriangleModels ---
--- AddEntitySurfaceModels ---
--- FilterDetailBrushesIntoTree ---
    14509 detail brushes
    18043 cluster references
----- FogDrawSurfs -----
        0 fog polygon fragments
        0 fog patch fragments
        0 fogged drawsurfs
--- SubdivideFaceSurfaces ---
--- FixTJunctions ---
************ ERROR ************
MAX_EDGE_LINES

(Zeke) #2

I’ve done some more research and learnt that the issue can be fixed by increasing the constant defined in the Q3Map2 source code and using the exe.

The only issues with this is that I can’t get the project to compile, even without any changes to the code (VS 2010 Ultimate) and there may be a possibility that the engine won’t be able to cope with the higher edge/vertex count.

Does anyone know what compiler and IDE should be used for the source?


(ailmanki) #3

The problem you have should be fixed in the map.

Either convert the part which makes troubles to ASE.
Or fix the t-junctions.
As last resort you can deactivate t-junctions creation.

http://www.ubertastic.com/index.php?topic=2065.0


(Zeke) #4

I’ve been round trying to fix the issues, merging brushes and trying to reduce the brush count but the map is so large and detailed that even after even more fixing and the removal of excess brush detail will still result in the error reappearing.

I managed to set up the compiler and have made a modified Q3Map2 with double edge/vertex limits, it’s just a matter of whether or not Q3 will spit it back at me or not.

Fingers crossed.


(ailmanki) #5

T-Junctions is not about merging brushes, its about creating the brushes in a way, that the compiler does not have to split em up any further.
This thread http://www.splashdamage.com/forums/showthread.php?t=17869 has some screenshots showing that - likewise what is happening in your map probably.

And this thread has the explanation, also linked in above thread…
http://www.splashdamage.com/forums/showthread.php?t=10838&highlight=t-junction


(Zeke) #6

Wow, I always knew that all quads were subdivided in to tris but to this extent was unknown to me.
I understand now why the ASE method works to reduce the tris but it would be a major pain to myself to neuter the map as it would also make these segments of detail hard to edit unless I kept them as prefab .map files to edit and import through development.

I did finally manage to reconfigure Q3Map2 to use a higher edge count and I am also looking into research on how to improve the lightmap resolution if possible.

Maybe at the end of development when I’m happy I can go ahead and optimise my map and do some model conversion to reduce the brush count so it then works with the original Q3Map2 if necessary.

Thanks for the help,
I’ll post here if I have any more issues in the future.

If anyone wants the modified Q3Map2 that uses a high edge limit, drop me a line.


(ailmanki) #7

I strongly suggest to fix the t-junctions, its better on the long run. AFAIK, when you do convert your map to ASE with q3map2 - you will run into the same problem again.
for lightmap:


(Zeke) #8

It’s possible that I could run in to the issue again but I can’t be sure either. If a single model is referenced from one file and is always covered in a single square clip brush for collisions it should reduce the TJunc count as IIRC ASE models are already subdivided in to tris after being converted from brushes.

Unless of course they are subdivided further or existing edges in all model references are added to the TJunc count.

It looks like fixing the TJuncs will be a big job as the map is so large, understanding the theory on where the TJuncs will appear will be half the battle.

At least I’ll be able to test if I have made an progress with the modified Q3Map2, I’ll be able to see the divisions in game without having to cut out half my map and storing it in an external file.


(obsidian) #9

You seem to be mixed up about a number of things. When converting brushwork to ASE models the T-Juncs are still there, only Q3Map2 doesn’t have to worry about fixing them. As mentioned above, it’s best to just fix the T-Juncs so they do not exist in the first place.

Merging brushes does not fix T-Juncs. Converting brushes to ASE’s does not reduce tris. T-junctions aren’t hard to understand, they literally look like a capital letter “T”. If you see two lines meeting in a T, use the clipper tool to miter the brush to fix the T-junction.


(Zeke) #10

I’ve seen this term “miter” thrown around alot and have done searches to explain what is done but with no luck. Can you explain or post a link to a tutorial/article about it?

Compilers working but the light phase seems to take at least triple the time that it usually does, either because of the compiler used or something in that area or due to the TJuncs issue that is still present.


(ailmanki) #11

http://icculus.org/neverball/mapping/
very short and precise .)


(Zeke) #12

I see, should this be done on Structural brushes where the void is kept out etc or detail (Or both) ?


(ailmanki) #13

‘Should’ be done where it is needed. And yes structural and detail.
Its a good practice to do it always, but I guess its time consuming.


(Zeke) #14

I’ll try my best to clean up where I can, it’s going to be a long night to put it lightly.


(ailmanki) #15

Be sure to have backups, step by step… :slight_smile: Good luck.


(Zeke) #16

Is there anyway of finding out how much I have exceeded the count? I’ve tried to get the compiler to print it out but with no luck.


(ailmanki) #17

No idea, I think it will stop the code cycle when it reaches the limit, not counting before. But did not check.

If you add ‘-notjunc’ to the command line, q3map2 will not fail on that, is does just not do it. As a result you will have probably lots of sparklies… The more sparklies the more you will have to fix in that area I guess. Might be a good indicator for where it has most troubles.


(Zeke) #18

Looks like another trip to the source code, I’ll force the compiler to continue regardless and do the check when it’s finished fixing the TJunctions and also print out the numbers compared to the hard coded limit.

Will be quite helpful as I will know if I’m fixing it properly or not.


(Zeke) #19

After going back and looking at the BSP (With BSP and VIS only) the problem seems rather extensive but I can’t for the life of me figure out how to prevent all the extra subdivisions from the TJuncs.

I can post the BSP up some where for some one else to look at it with r_showtris for themselves and I’ve got a few screenshots to hand for on lookers to cast their opinion as well.

After compiling the map with just BSP and with notjunc there didn’t appear to be a single sparkly in the entire map. Unless this is because only BSP was used I will recompile with BSP, VIS and LIGHT.

If anyone knows of any other tutorials regarding TJuncs I’d be extremely grateful. :slight_smile:


(Zeke) #20

Right, I’ve reduced the edge count and everything now compiles Ok with the original Q3Map2 compiler but now the light phase STILL takes around 3 times longer than usual even on the lowest setting (-faster only).

Any idea on what could cause this?

Start Edit
When compiling the Task Manager says that Q3Map2 is only using 25% of the processor (I have a quad core), I have set -threads 4 on BSP, VIS and LIGHT but it doesn’t seem to make any difference to how much the processor is used as shown in the task manager.

Is there any way around this?
End Edit