Compile Freezes and Long Compile Time Problem

[Lost]

Alright, the map I'm trying to get to work with a normal compile just refuses too, the only option I have is to let it run overnight, and then throughout school to see if it will go past this one spot, but it shouldn't take nearly that long, a fast compile takes about 1 minute max.

Not sure if this is something I've missed in the map that for some reason extends the normal compile time to an ungodly amount that I still don't know, or just my own computer.

If nessasary I'm willing to send the file to someone if they need to look at it. just a small simple map for a GG server we run.

it gets to this part within 2 minutes and then would take 8 hours and then pause at the 6 for portalflow from then on, not a single dot ever shows up.

and like I said the map isn't that big, real small

no leaks either if your wondering, everythings sealed tight

hoping someone knows whats going on here or can help me fix this problem cause I'd like to have a map that doesn't have shitty looking shadows lighting etc.

Lost,

[dissonance]

O___O

have you turned anything into a func_detail? try that, it might lessen the time a bit.

[Zacker]

You are probably running out of physical memory during vis and then your compile slows down big time due to the swapping.

4.5k portals for such a small map is quite much, you need to reduce the workload for vis by e.g. turning all non-vis blocking into func_detail.

[OrnateBaboon]

All of the geometry in the room looks as though it should be func_detail, since it is not vis blocking. Also, the sky box has been dragged around the whole map, which means that parts are being rendered that shouldn't. The base portal vis part hates the big skybox method, and just by properly sealing the map., you will cut loads of time off of the compile.

[ReNo]

Looks like you've sealed it all up inside a big box - thats mistake number one. Use the basic architecture of your level as the outside hull, don't just throw a box around it or you are creating a whole load more work for both VIS and RAD. If you can never be in or see a space, then it shouldn't be getting compiled into your level (yes there are exceptions but you know my point awkward people ).

Secondly, if the vast majority of the brushwork in that screenshot isn't func_detailed, then its no wonder your compile is taking so long. Go read up on leaves and what VIS is actually doing during the compile, and hopefully it will help you understand how and when to use func_details, hint brushes, area portals, and so on. Plenty of material to get started on here...

http://www.student.kun.nl/rvanhoorn/Optimization.htm

[hessi]

make the same screenshot while hiding all entities(brush and point) (using auto visgroup)

such a big room wouldnt need any visblocking if you ask me. you can see nearly everything at anytime.

[Lost]

thanks for your input guys, and no its not inside a big box, the sky box is only over that circular opening, what looks like a big box around it is the cordon box thing to remove some ruff work things I have placed outside that map. other than that everything is sealed up right against the map edges with nodraw on them.

[Dodger]

hey I have a few hints for you man!

Apply nodraw tool on all hidden textures that will not draw in the engine while you are playing.

Make skip brushes with the hint brush to optimize the map into areas

[Zacker]

Unless only blocked by an entity, then the engine will automaticly remove all hidden faces. Even the HL1 compilers/engine could do that:)

I do not recommend use hint brushes here either. Judging from the screenshot then all of the room will be rendered anyways, so hint brushes will only make things worse.

[BaRRaKID]

tie to a func_detail everything in the map that is not blocking visibility, and start using models instead of brushes.

[Lost]

Func_detail works fine

[dissonance]

make your pagefile bigger, too. four gigs or so.

[Zacker]

You need to optimize your map if you need a four GB pagefile.