I could have sworn I already made a few comments on this map but it seems this is my first. I remember the map to have a daylight setting and I think the night change was a good decision. Not so much because it's night but because the more foggy, cloudy day setting is getting a bit old with HL2 maps. Be careful with the darkness levels. Especially when making a night map you should try to make the map as bright as possible. Even if it looks a bit worse, people can't play dark maps when light is mirroring on the monitor (or when they have very bad brightness settings) which results in people rejecting these maps before even getting to play them.

I see some brush-based details that should be models/props (handrails, pipes, street laterns...). Would look a bit nicer and help performance (brush based details like this can easily make 20-50% of FPS).

Everything else looks very OK so far. Especially the parts of the skybox with the fog and darkness. Just make sure the low-res skybox models don't get too close to the player!

Lol, ok, thank for you letting that know ReNo, now I don't have to endure cold sweats anymore whenever running a compile after having placed some more models :smile:

I am getting a very high entdata amount (over 80% last time), does anyone know how to decrease the entdata without sacrificing too much models?

I wouldn't worry too much about the entdata - the percentage given seems to be odd in that everything still works fine at well over 100%. I heard from one of the guys at work that Valve told him it was safe to go to around 200%. Higher that then could cause some issues when playing the map, as entities such as bullets, players, weapons, etc... that are created during the game could cause you to breach whatever the actual limit is.

Suffice to say, 80% shouldn't be any sort of problem.

You said you could also make all func_breakable_surfs into a big entity? Wouldn't it also crack all the windows when you would damage just one?

Don't recall saying that.. :smile: That's exactly what'd happen if you tried.

I've played around with glview a bit more and I'm starting to see how things work. At first it appeared to me that the white lines around the whole place were created by the way things cut up, but upon a closer look they appeared to be boxes...are these boxes the visportals?

Exactly, they must add up to cover any and all "empty space" in a level and when weirdly shaped world geometry comes into play, vis really has to fight to cover all the blank space with convex shapes (mostly boxes) - and when it gets really bad, you end up with a lot of tiny leaves in weird shapes. Func_detailing stuff tells vis to not consider it at all and so doing that to complex geometry really simplifies things so you have clean leaves and no tiny ones, etc.

Edit 2: I have gone trough the glview and cut-ups a bit now. Most of the horribly cut ups and visbox constructions have been fixed. It's not top-of-the-notch yet but it's getting somewhere.

Great. :smile:

The portalcluster count has been lowered from 3500 something to 1881, and the numportals count dipped from 10000 something to 5639.

Very good, you've basically halved the VIS complexity of the map and a lot of that is probably tiny little leaves nobody will ever enter. That'll help a lot.

I've been messing around with the fog again and decided to remove the clip again since the map has been pretty optimized already. Without the clip the fog looks much better, stuff goes up in the fog nicely now, I decreased model fade distances too and everything works just fine

That's good to hear, I honestly don't think it'd have helped very much to keep it :smile:

I am getting a very high entdata amount (over 80% last time), does anyone know how to decrease the entdata without sacrificing too much models?

Hmm, I don't know.. your map is really huge so there's probably not much you can do.

The VMF of today is available at http://www.megaupload.com/?d=6NO2PBZS

Cool, I'll check it out when I get home and give you any more thoughts I can about VIS performace first and foremost.

I want to thank midk for helping me with this map - first of all, yes, you were right about the clip and second, that tip on the glview thing really helped me with making the map viscompile a lot faster and to understand how the visportal & cutup processes work a bit. I knew about the cutup process but the visportals I never really understood - now that I saw them I could.

No problem - glad I could help! :biggrin: Hope it all works out for you.. I'll post again soon on the new VMF.

Yay - I got glview to work...but it sure jurts me a bit to see how ugly the game cuts up stuff at the trainstation complex roof (the building with the big glass roof) - I thought this kind of architecture would only cut up the brushes it was directly connected to?

I'm going to work on func_detailling all that cuts up like you shown, I found that there aren't that incredible much spots where situations like these happen so I figure I could get that all fixed up today...I may even be able to finish up the inside detailling, I am trying to maintain a balance between usefullness and visual appearance, putting in just enough models to make an area like it's supposed to but also limiting the number of models as much as possible, creating detail brush geometry to save some much-needed entdata...entdata was at 86% last night :sad:

You said you could also make all func_breakable_surfs into a big entity? Wouldn't it also crack all the windows when you would damage just one?

Edit:

I've played around with glview a bit more and I'm starting to see how things work. At first it appeared to me that the white lines around the whole place were created by the way things cut up, but upon a closer look they appeared to be boxes...are these boxes the visportals?

If they are, then I can seriously increase performance with just a few little bit things....never thought it would be so easy

Edit 2: I have gone trough the glview and cut-ups a bit now. Most of the horribly cut ups and visbox constructions have been fixed. It's not top-of-the-notch yet but it's getting somewhere.

The portalcluster count has been lowered from 3500 something to 1881, and the numportals count dipped from 10000 something to 5639. I am running a full vis on the map now and its going somewhat faster then before. It may even compile within a day now! :razz:

Final Edit of the Day: Vis portalcounts were lowered again a bit.
I've been messing around with the fog again and decided to remove the clip again since the map has been pretty optimized already. Without the clip the fog looks much better, stuff goes up in the fog nicely now, I decreased model fade distances too and everything works just fine :smile:

I am getting a very high entdata amount (over 80% last time), does anyone know how to decrease the entdata without sacrificing too much models?

The VMF of today is available at http://www.megaupload.com/?d=6NO2PBZS

I did not complete the inside detailling yet, I did however checked out the models carefully and put an example of useable ones in the map, they're not visible in the compiled map tho :biggrin: they're just there for future selection purposes and for me to check out what kind of models there exactly are available.

That's all for today - I am going to run a vis compile overnight to see how far it comes in the time that I sleep this time. Last time it was just around 65% after 15 hours of contigous compiling and this afternoon the compile just ran easily to 50% on lower then normal priority and winamp + hammer running & consuming cpu, so I'm not that worried anymore.

I want to thank midk for helping me with this map - first of all, yes, you were right about the clip :wink: and second, that tip on the glview thing really helped me with making the map viscompile a lot faster and to understand how the visportal & cutup processes work a bit. I knew about the cutup process but the visportals I never really understood - now that I saw them I could.

The thing about prop_physics multiplayer is that some props that are quite small simply don't interact with the gravity gun or other props. The solution is to convert any props that work weirdly with prop_physics_multiplayer (should be mostly small, detail-like ones, e.g. books/binders, road signs as you mentioned etc.) to prop_physics.

snags the VMF :smile:

-- [edit] --

Okay, so I just had a quick poke around and this map is huge! :biggrin:

There is no way to stress enough how much you need to get using glview. Look at this - that's all the leaves surrounding the house. That's incomprehensibly complicated; the whole house could go func_detailed, and most CERTAINLY all the little brushes outside it that make up the little lawn area.

Func_detail a bunch of stuff, keep referring to glview, and repeating until there are no places like this. Everything should be smooth, there should be no tiny leaves and no huge tangles of leaves like this. This is one of what I'm sure are quite a number of things that are absolutely killing your compile times. The huge roof on top of the.. er.. bus station thing with all the glass on top, is another one of those things.

Spend a couple hours func_detailing and glviewing and I promise you won't be disappointed. Your compile time should drop to an hour or less if you use that time wisely.

Ok....so I've uploaded the vmf of the 23rd...that's yesterday by now here :razz:

Here's the link:

http://www.megaupload.com/?d=GQ1MLCI1

Maybe others know better ways of getting performance to the max... :smile: feel free to send me vmf's with examples of how stuff could be improved and have fun checking out my home.

The map is a single player map for now, and you will start in my room.

Yes, I noticed, there's a bug with the keyboards and some matresses. I converted func_physics to the cheaper func_physics multiplayer for performance reasons but it seems that not all models work under this. As far as I found, the sawblade and the road signs just fall down to the ground and seem entirely static.

The map is supposed to be a multiplayer map anyway so why not spare the engine from the conversions it apparently makes when loading a map in DM?

1) Well I strongly suggest getting a red light. White lights don't cast blood red light.. plain and simple. :smile: Also, the red doesn't really light the room at all. It makes a spot on the ceiling but it contributes little to the overall room lighting. You should use a light_spot to cover the room in red light and then a very dark (like 10-20 brightness) red light under the model to illuminate the ceiling area.

2) Release away. :smile:

3) Oh, feel free to keep the old setting - to get it looking right you'd really need to tweak it a few times to get it to seam with the skybox (see here and look at the screenshots).

4) Clip if you want, I'm just saying that having a huge, obvious cutoff will look very ugly and says to the player that you didn't spend enough time optimizing the correct way (which would do something like bring vvis down to a few minutes and performance way way up) and decided to just not draw stuff that's pretty far away - the lazy way out. Fog should always completely obscure the clip plane if the clip plane is used. Otherwise, it looks bad and unprofessional.. that's simply that. Also, if it runs well without VIS you can most definitely make the clip plane much farther because without vis, EVERYTHING is drawn - that will kill performance.

5) Sure, safe as anything to put up the VMF - I really respect the very few people that do, for helping out beginners to see how some things were done, and letting the world see what they've done and how they did it. If you did that I'd be happy to poke into it and see if I can give you some better optimization tips.

Lol no there wouldn't be a reason, but then again, this is not a normal house. This is a squatted storage / office complex run by a bunch of kids. We really have a red light in our living room (yes, that's our living room :biggrin: ) and it looks cool. I should indeed make it a lamp then.

I was planning on releasing a demo of the map after I am complete with furnituring & detailling the inside of the buildings, which will be soon. I am done with all the small rooms anyway, the only thing that needs to be furnitured a bit is the storage area.

For as far as fog goes, I tried a darkblue setting, but it sucked, honestly. Everything appeared...well...blue. Real life fog isn't blue, it's usually a greyish hazy colour at night, so I stay with my first fog setting.

Please do not be angry about me using such a rude clip :biggrin:
The map really needs it, there are loads, and I mean loads of models around the area. I'm finished setting fades on them and it helped a lot on increasing performance on the unvised map, so I am not really worried about the full compile's performance. The clip just makes sure that the entire map isn't drawn in it's whole at once, or in too large sections at once.

Would it be safe to upload the vmf here? People could see how the map is built n stuff, could be usefull or something.

Fluorescent lights, aha. :smile: Never heard the name "tl armature".

The problem is that it's clearly a dark (unlit) white bulb in there. Yet there's this bright red spot on the ceiling. There's no clear source of it and thus it looks weird. You ought to replace the red light with a white one (and use the other skin on the light model because it's brighter as if the light is on), or delete these fluorescent fixtures and replace it with a red lamp (I've only seen one before, those metal-grated utility/industrial ones).

Honestly, this looks like a living room or something (is it?) - there's no reason there'd be a bright red light shining in the middle of a living room anyways.