MAX_ORIGINAL_EDGES error at 10k brushes

[kwenga]

Hi everyone.

 

After a long break, I started to experiment with Radiant once again, making some preparations for future projects and ideas. Long story short - I ended up with really complicated map, mainly in spirit of testing the limits of q3map2 engine. I was confident enough to keep on adding stuff, since brush count was still around 10k. I divided my experimental project into several .map files, so I could manage everything easier. Segments were optimized - detail and structural brushes were used, some .ASE objects were added in place of rotated and often broken brushwork, I also avoided patches and autoclipped models. I tested each .map file, looking for errors and stuff, so I made sure that those parts were made correctly.

 

The problem showed up when I gathered all the parts together, into the single .map file. Previous experiments showed no issues, but as I tinkered with parts of the map, the amount of brushwork obviously increased. Preventively, I doubled some segments of the map, just to round up the potential number of brushes at the end of my project and compiled whole project today. At this point, the MAX_ORIGINAL_EDGES error comes up.

 

The map is uncompilable, at nearly 10-11k brushes, with bunch of patches (but less than 50, and not very complicated, mostly bevels), 50+ ase and md3 models. No 'substract' or 'hollow' used, details mostly made of models, not dozens of small brushes.  How is that even possible? There are other huge projects, where brushcount was way above that level, Atlantica may be the best example. How do you get rid of that problem? Is there any way to fix that issue, so I could continue with my work? Please let me know. An answer from @@Szico VII himself would be a blessing, or from anyone who had managed to avoid that error in the past.

 

Happy holidays.

[IrocJeff]

Do you have a brush with too many sides or one that was rotated by chance?

 

I have 15000 brushes in 1 map and have had no issues.

[AshuraDX]

I've had 48000 simple cuboid shaped brushes in a .map (one of my testterrains) and did not see that error. I have not yet done any research on that error but from the phrasing about "original edges" I'd assume it's caused by something that changes its number of edges due to tesselation. So in a first step, I'd take out all those patches and see what happens. @@kwenga

[Lazarus]

http://forums.warchest.com/showthread.php/3455-error-max_original_edges and https://jkhub.org/topic/3189-error-max-original-edges-what-is-this/

 

Tiny brushes, to many triangles, all that kind of stuff... Also, is the spawnflag solid ticked on your models, that also might cause a problem

 

It only happens during the FixTJunction phase of the compile. Apparently, you have hit the limit of 65536 original edges. At this point, my understanding of the q3map2 code fades, and I'm not sure if "original edges" are the set of unique triangle edges in the map, or if it is the number of unique edges allowed per meta surface.

It was the number of edges in a meta surface. I had to reduce the number of triangles in my terrain

[kwenga]

Do you have a brush with too many sides or one that was rotated by chance?

 

I have 15000 brushes in 1 map and have had no issues.

 

Rotating brushes in Radiant often creates deformed shapes, with vertexes placed completely out of the grid, so I avoided that in all of my projects. If I had to rotate something, I would do it manually or by creating ASE, if really necessary. I also avoided brushes with too many sides, with cutting too complicated shapes into smaller brushes, with 3 or max 4 sides per brush, so that shouldn't be the case.

 

 

I've had 48000 simple cuboid shaped brushes in a .map (one of my testterrains) and did not see that error. I have not yet done any research on that error but from the phrasing about "original edges" I'd assume it's caused by something that changes its number of edges due to tesselation. So in a first step, I'd take out all those patches and see what happens. @@kwenga

 

  I spent last night researching similar kind of stuff. Patches are not that bad in terms of original edges, which I will explain at the end of this reply.

 

 

http://forums.warchest.com/showthread.php/3455-error-max_original_edges and https://jkhub.org/topic/3189-error-max-original-edges-what-is-this/

 

Tiny brushes, to many triangles, all that kind of stuff... Also, is the spawnflag solid ticked on your models, that also might cause a problem

 

Spawnflags are mess. I'm only using spawnflags 4, which is for lightmapping ASE models. Since this error is connected to BSP stage, not VIS or light, it shouldn't affect it. If I had to make a model solid, I used simple brushes with clip texture. And yes, I saw both topics you've linked here, but none of them really gave me the answer I was looking for.

 

Using the best method of fixing anything, which is "trial and error", I've managed to test several diffrent scenarios. Error occurs at --- FixTJunctions --- , which is calculated during BSP stage. Since most of what precisely happens during compilation is still black magic for me, I had to delete some brushes, just to reduce overall number to 9k. With reduced brushcount, compiler did its thing and produced bsp without an error. This is FixTJunctions part.

 

Map WITHOUT patches and WITHOUT ASE models.

--- FixTJunctions ---
    18488 axial edge lines
    21528 non-axial edge lines
        0 degenerate edges
    28650 verts added for T-junctions
   143729 total verts
    22346 naturally ordered
     4524 rotated orders
     1633 can't order
        0 broken (degenerate) surfaces removed

With some solid numbers, I began adding and removing different fragments of the map, compiling and comparing numbers from logs. First, I added previously deleted patches.

 

Map WITH patches, WITHOUT ASE models.

--- FixTJunctions ---
    18642 axial edge lines
    21642 non-axial edge lines
        0 degenerate edges
    28742 verts added for T-junctions
   143841 total verts
    22377 naturally ordered
     4488 rotated orders
     1643 can't order
        0 broken (degenerate) surfaces removed

As you can see, total verts count is higher, but not that much. It is even less than 1% of the whole value, and I'm talking about 30-40 patches added to the map, some of them, like pipes and cables, were complicated shapes. It seems that patches are affecting this stage minimally.

 

Map WITH patches, WITH ASE models.

--- FixTJunctions ---
    18642 axial edge lines
    21639 non-axial edge lines
        0 degenerate edges
    28742 verts added for T-junctions
   143821 total verts
    22327 naturally ordered
     4535 rotated orders
     1641 can't order
        0 broken (degenerate) surfaces removed

Again, adding 450 models, both ASE and md3, had marginal effect on FixTJunctions stage (total verts count is even lower, lol). It all comes down to regular brushes, both structural and detail, which are responsible for that error. This might be a problem, because I wanted to add more sections to my project, making it into a regular, proper map. At this point, I need to make a decision - investing more time in sunken project won't be a good idea, and it is still possible to change few things, simplyfing whole map. There is also an idea to change some internal, non essential brushwork to ASE models, reducing brushcount to bare minimum, but that will obviously raise amount of models used in the map, which might be a problem - if not on the FixTJunctions stage, it might come out later, during different stages of compilation. The error also might return, when adding additional rooms, even with ASE models everywhere - I still need solid brushes, for walls and stuff... What do you think? What should I do?

 

 

Ah, one more thing. As I said before, Atlantica is a curious example, with complicated geometry and high brushcount. Using source files, which were available on jkhub, I've tried to compile that map - and it ends up with an error, not same as mine, but also on the FixTJunctions stage. How is this possible? Maybe Szico used different compiler or has found a solution to fix or to get around that problem?

[Apprentice]

Altough I rarely get the MAX_ORIGINAL_EDGES error, it doesn't deviate that much from the MAX_EDGE_LINES error I got during BSP compilation(s) and at the same FixTjunctions stage. Both have the same fault: too many lines are being drawn. The FixTJunctions stage does indeed do some questionable things, as the following images will portray.

 

In this image, the floor and ceiling (both rectangular) should supposed to be pretty straightforward, wouldn't you agree ??

 

Nope, not according to the FixTjunctions stage in q3map2 BSP compiler. Now, the same floor is being drawn in 25 lines and not counting the lines on the edges where it meets the wall. Times two because the same happens on the ceiling and you're already past the 100+ lines. This does happen quite a lot and that way, you'll hit the 65536 lines pretty easy and pretty fast.

 

In this image, I managed to solve it (actually circumvent it, it's not THAT pretty but it works) by devising a shader script. Now, the floor and ceiling are being drawn in 10 lines. This means that 90+ lines from the earlier mentioned example are now being used elsewhere or not at all. r_showtris 1 will help you in this matter by identifying where the most lines on a surface will be drawn. There is a downside to it. Using it too much will cause white sparklies being drawn on the edges of your brushes. Alternatively, you can also use the -nofixt option in you BSP compile stage but that will defintly be ugly (see my Asteroid Base - Release02 map for 'details') . . .

 

// Modified texture line
textures/<mapname>_NoTjunc/<texturename>
{
// A bit unnessacery, since the above serve the same purpose unless no image exists. I take the image and paint a red cross throughout it, so that I immedialtly recognize it in Radiant.
// The dimensions must be exact the same as the original texture!
    qer_editorimage textures/<mapname>_NoTjunc/<texturename>.tga
    q3map_notjunc
    {
// This is your original texture. Can both be stock (as shipped with the game) or custom. Works with all textures.
        map textures/<mapname>/<texturename>.tga
        rgbGen identity
    }
    {
        map $lightmap
        rgbGen identity
        blendfunc gl_dst_color gl_zero
    }
}

[Langerd]

Ok so some word from me. I remember that map i was doing and i had a lot of problems. I was noob at that time. If i remember correctly the reason of this bug was - adding too many platforms that were made from patches and brushes clone and rotated them. The last thing was putting them like the senate platforms - this big hall where yoda and sidious were fightning. I think the biggest issue was not paying attention on the optimalization and rotated brushes - the last one i think is the main issue. Brushes dont act like cubes in the 3D program. If you will take the vert tool and change the shape of simple cube brush in gtkradiant - the shape will not always go tje way we want like the prpgram is showing us the limitations.

 

Have you used the clipper? ( this tool to cut i tjink it was called like this .. i cant check the program at the moment)

 

Edit: Also cutting rotating and scaling are many times change the brushes to the state that they are not longer fitting the grid which is impprtant i believe. This also may create this issue

[kwenga]

@@Apprentice

Yep, MAX_ORIGINAL_EDGES and MAX_EDGE_LINES are very similar, but after several tests (again, trial and error, so it took hours), I somehow found the real reason. MAX_EDGE_LINES error was connected to that limit of total unique edges, which is 65536 or so. I was wrong in my previous reply, when I counted total verts, which is not the cause of said error. Its the sum of two values from FixTJunctions stage - axial edge lines and non-axial edge lines. Hitting the total limit would result in MAX_EDGE_LINES. My error, which was MAX_ORIGINAL_EDGES seems to be the indicator of another limit - and I'm pretty sure that it is non-axial edge lines limit. Nearly every diagonal line will be counted to that value, and hitting total of 25874 or above that, will interrupt FixTJunctions stage. Ah, and other important thing - only textured surfaces (not caulk, hint, triggers etc.) will add to that values.

 

As my whole map was a original - and tricky - idea, I had rooms which were rotated by default. I was sticking to the grid, building everything with 45 degree offset, cautiously and precisely - and It paid off, because there are no other bugs, everything runs smoothly. But that limit for diagonal lines, which is 1/3 of maximum value, kinda ruins it all. It seems that you should stick to the grid, building everything with squares and rectangles, if you want to make a huge map, not making the mistakes I did, by designing jk3 map in unorthodox way...

 

Using shaders may be a good idea, but it would be really time consuming - and to be fair, I don't have that many rectangular ceilings and problems similar to that on your screenshot. But thanks anyway, especially for the shader bit, It might come in handy later, if everything else fails.

 

@@Langerd

 

As I said before, I build everything manually, without cutting, rescalling or rotating brushes. Everything is clean and smooth.

 

 

Thank you both for your replies, this topic might pop up years later for someone with similar problem, and those answers will definetely add more light to this matter. For now, I'm busy, so I won't be experimenting with radiant for a while - what I did, just before I was interrupted with other stuff, was replacing many of diagonal brushes by ase objects. It saved me a lot of non-axial and axial edge lines and I think it is the way to go... as long as another error emerges from the darkness of q3map2.

[Apprentice]

As my whole map was a original - and tricky - idea, I had rooms which were rotated by default. I was sticking to the grid, building everything with 45 degree offset, cautiously and precisely - and It paid off, because there are no other bugs, everything runs smoothly. But that limit for diagonal lines, which is 1/3 of maximum value, kinda ruins it all. It seems that you should stick to the grid, building everything with squares and rectangles, if you want to make a huge map, not making the mistakes I did, by designing jk3 map in unorthodox way...

Screenshots or it didn't happen !!