structure disapears

(kilL_888) #1

hey,

im having a weird graphic bug in my new map. it also takes pretty long to compile.

can someone explain what could be wrong there?


(AnthonyDa) #2

Check your LOD group ?

(hozz) #3

Compiler bugs?

If yes: put small details into detail groups so their geometry does not change the rest of the geometry. Or export the details to models from editWorld and insert as models.

(kilL_888) #4

[QUOTE=hozz;226016]Compiler bugs?

If yes: put small details into detail groups so their geometry does not change the rest of the geometry. Or export the details to models from editWorld and insert as models.[/QUOTE]

i got a compiler bug first even with caulk hull, though there where no entities reached from outside visible. could fix this by adding another caulk hull around the first, smaller hull.

now, one hull is enough though. dunno how i fixed the first leak. i got no compiler errors, but it takes relativly long to compile for such a small map.

i have a guess why the error appears. some brushes might have bad geometry. there are 4 colums i modified with the edge tool and now i cant scale them anymore. gonna check this out this afternoon.

(.Chris.) #5

Dont scale brushwork.

(kilL_888) #6

well, i didnt mean the “scale” function. i dont scale anything. i mean just chaning the size.

anyways. the problem seems to have something to do with the high count of patches. i removed the columns in the center and the map compiled just fine.

the brushwork itself is pretty simple. the problem appears in another map too, which has also lots of patches.

is there a maximum patch value allowed in one scene? or too many subdevisions?

(hozz) #7

I meant compiler bugs as in “the result is not ok, because the compiler is not good enough”. Not an error message in the console. Nothing to do with leaks. And the geometry actually does not need to be too complicated for the compiler to fail, it’s a bit random.

In your case, looks like the patches are to blame. I suggest you export them to models when they are final, and then use these models. That should not result in errors (and may save you later performance problems). Apparently Quake-style engines can’t work with too much details in brushwork/patches, while “high” detail models are fine.

(pazur) #8

“Apparently Quake-style engines can’t work with too much details in brushwork/patches, while “high” detail models are fine”

I hope this is not entirely ture as my map has tons of details in brushwork on the main building: http://www.pazurmapping.com/pkin_gal.htm

I have to admit though that I have seen a similar problem with the disappearing brushes in one of my test complies but re-building some LOD groups helped solving it.

(kilL_888) #9

i think it also depends on what grid your working on, not sure though.

i learned one thing through my years of mapping. i tend to forget it from time to time, but its very important. compile your map from time to time and check it out. the realtime view in the editor is beautiful but you dont check the actual map anymore.

btw. i reduced the subdivisions on all patches. must be half or even quarter in size now. i also put the majoritiy of objects into detail groups and func_statics. map compiles in about 10 seconds now, before it was about 1 minute. and you have to look exactly at the patches to see a visual difference.

(pazur) #10

Yea, the rule to compile regularly is really important. A few years ago a friend asked me to help him with a RtCW map that didn’t compile. He completed a map that aborted compiling on the -vis stange. That meant it had absolutely no vis and r_speeds of about 50K (usual for q3 engine maps are like 15K). The reason for the aborting vis compile stage was that everything in the map was structure.

(pazur) #11

Today I got this ugly bug… it’s really odd. Need to play now with LOD and Detail groups to fix it.

(jRAD) #12

You’ve probably gone over the maximum number of vertices for a surface (65536). You’ll need to split your structure up into separate detail groups.

(pazur) #13

Thanks jRAD. I’m going to try that but I’m not sure what brush (or surface) hit this limit. I have a lot of small decoration elements aligned to large brushes. The decoration elements are all in detail groups and additionally some parts of them are in LOD groups. Would it help if I post a screenshot of the 2D view?

(.Chris.) #14

Looking at the screenshot, a lot of that detail would be passable as a texture, in reality when is the player going to be outside the building at such heights to notice?

(jRAD) #15

It’s not really a case of isolating a particular brush or patch - you just need to plan to divide your structure up into smaller chunks if you’re going to keep it all the same material.

(pazur) #16

I don’t get it. I had very large brushes with the same material in earlier versions of my map and it compiled and showed fine. So how large does these chunks need to be? 512x512 larger, smaller?

If I can’t solve this problem I will either give up this project or grab it as a model move to COD4 or CSS :confused: (or mabye UT as it’s free)

BTW: This error is in the console after exiting the game: GL_CheckErrors: GL_INVALID_VALUE

I start thinking that this is some weird ATI Catalyst bug (the vertice-mess looks like you would overclock your graphics card) or a corrupted .world file as I removed all large brushes and the problem is still there. I will try to take an older file and add step by step the new elements to see when it starts breaking. Another workaround that I think of is exporting the details into model files or making textures with normal maps from them (like Chris suggested).

(jRAD) #17

It’s not the physical size - it’s the number of vertices in a single surface, which is grouped by material. As you added more detail you got closer to the limit and eventually went over. It looks like the entire building is the same material, so the whole thing is going into one surface.

If you plan to keep the building the same material everywhere, then breaking up the building into several detail groups will force geometry into unique surfaces, which should each be under the limit. Try selecting each storey and putting them into a separate detail group.

(pazur) #18

Ok. Now I get it. Yes, it’s mainly one material. I thought one material would be faster for rendering. Will try what you suggested and let you know tomorrow (at work now :wink: )

(.Chris.) #19

Use a texture sheet with multiple textures within it to boost performence.

(pazur) #20

Ok, it took a bit to slice everything up (I have now about 100 detail groups - each storey has a detail group) but it still doesn’t work. :frowning: I now even get a warning in the compiler:

WARNING: idCollisionModelManagerLocal::ChopWindingWithBrush: primitive 14251 more than 256 windings

Attaching a screenshot how the bug looks like now. It’s super strange… maybe some brush or patch is corrupted?