Another MAX_EDGE_LINES issue


(ailmanki) #21

AFAIK there is no way around that, except you would improve q3map2 to use more then one thread for that particular phase where it uses only one (25%).

Maybe you have a heavy sky shader… ?


(Zeke) #22

The sky does have a shader sun in use, I never thought of lowering the quality down, it just doesn’t make sense why the sudden jump in compile time would happen. I’m still having issues getting the TJuncs count down, all in all this isn’t looking good for my map.


(ailmanki) #23

I have no idea either, but if you had been stuck at t-juncs it must been a while since you saw the light :p.
Be sure to go step by step … it is very rewarding what you do now, you learn a very lot by fixing your own map.
If you included high resolution lightmap already, then that is surely the reason … (but I guess you know that).

you can see ingame where q3map2 did cut your brushes with:
r_showtris 1


(Zeke) #24

I’ve finally managed to get a semi good quality compile out with lighting done. I had to leave it running while I went out to see some people.

There are a few issues that weren’t there before with this quality level of light that’s been used in all previous builds.

Some faces are completely black or very dark for some reason and are illuminated by the light saber in game no problem while before they were lit properly. Some tells me this links to the high compile time issue.

I managed to get the TJuncs under the limit until I removed q3map_notjunc from the shader used for the terrain meches. Is there any benefit at all from making some of the brush work in to ASE models and putting clip brushes around them?

If it actually reduces the count by removing the brush set then optimisation would be no issue as I’ve scoured the map and I’m STILL going over the limit.

Also, do patches/curves add to the TJunc/edge line phase at all? If so I can convert alot of brush work in to patches in places that would help reduce the count.

Quickly losing hope here. :frowning:


(obsidian) #25

Are you doing anything out of the ordinary with the lights? Like high resolution lightmaps or lightstyles or anything else?

Patches don’t add T-Juncs because they are dynamically changing LoDs, but converting brushes to patches for the sake of fixing your T-junctions is probably going to cause more problems than it will solve. It’s like you’re trying to fix a leaking pipe with a drill.


(Zeke) #26

There is a reason for it, I usually map for the Source Engine which doesn’t have patches and so anything that’s curved has to be made out of brushes.

The map has loads and loads of archways to fit a certain style of architecture and as I like the control of using brushes for them over patches it increased the TJ count by about 2000 Edge Lines.

The patches look fine in game and the FPS seems steady, the patches affected by LOD don’t seem to be noticable from as far as I can see.

I’ve gone and lowered the quality of my sky shader. I left the map compiling over night for nearly 12 hours to see how bad it would be. I woke up and found it on bounce 2 of 8 still.

I’m starting to run out of ideas on how else to lower the edge count and I really don’t want to make the terrain look any less detailed. :confused:


(obsidian) #27

You are using caulk, right?


(Zeke) #28

Hahahaha, of course. If it’s not visible or it’s needed for water or something along that note, it’s caulked.