well, this thread sure took off. Anyway I do think there is a problem I havnt locked down yet, after the test and dubee complaints I can vouch that the FPS had indeed dropped, which wasnt true earlier in testing. In fact the FPS was the same before even when I had the fog and all removed, I looked at it all again trying to find the cause of the loss. My guess is maybe its the eng_restrict brush's and such I copied from the old vmf of the map, they all had the invisible brush on them(I threw them in quick like to make the map playable) and a pretty small lightmap scale and texture scale. Now I dono how many of you know but the game actually renders the invisible texture brush even though its blank. I'm not sure how much this could effect FPS, but to get the map into playable condition I was faced with many many engine hunk overflow errors, which is mostly just caused by lightmaps and too many of them too small. The answer to which is to increase the lightmap scale or remove displacements/replace them. I did all of these things, which shouldnt have been so, since I had already had the map working before under the conditions of the old 3d skybox(where I removed most the not seen displacements). I dont know whats causing it exactly to have this change(its been a long time since I had worked on mvalley before this latest go of it). But I'll try to puzzle it out. and actually just FYI I actually had an minor increase in FPS before, since no prop_static or overlays faded in the old version. 1/2 the rendering almost was wasted away on overlays that were always rendered(they fade out now). Demented, the fog has thrown your perception off, your at different heights in your screenshots(relative to the terrain). the dam and the bridges are the only large pieces of map changes for the most part(the terrain is fairly accurately reconstructed). I did lower the height of the map from the origin but thats it(to make room for taller skybox area). other than that the map positions have not altered a single unit, they are all aligned nicely to grid and I never even altered the resource file. and dubee where your looking has a great effect on your FPS, your computer does not render things behind you. so if you stare at an empty corner you'll get nearly full fps than looking at the mostly costly portions of the map. EDIT: also just FYI this map is pretty much made entirely from scratch, any good change needed a new VMF. The old vmf was pretty corrupt and work on it turned into a nightmare in no time, it was a decompiled version of the map which in my opinion decompiling is a ruination for maps. So all the terrain and everything(yes bridges too obviously) needed to be redone, so they mimic the old version pretty well, but are indeed a new patch of ground.
Like I said its really not a big loss like on the new one.. A couple things I did notice though. On the new one I can see a lot farther and in console I noticed it said something like missing a water particle. I dunno if that's missing from the map or if that's something that was taken out with pickleds pack
There are debug cvars which cause visualizing of lightmap pages that are loaded in memory. If you set lightmap scale too low and game renders a lot of them at once it may cause constant replacement of pages from the disk.
That was my point. I'm using a "bind KEY setpos x y z; setang x y z" method to get screenshots from the exact same position and you've foiled me. It's really minor, but I can't help screaming KHAAAAAAAAN.
Generally I find it pays to use a single cubemap for the whole map and put it in a dark box somewhere off-map, as source doesn't link luminosity to specular intensity, so something can be in darkness but it will still be very shiny, and it has a habit of making everything a little too shiny anyway. You would also get a big FPS increase if you removed water reflections, you shouldn't have them on a map with zero optimisation and water all over the place, especially seeing as you will usually be looking at the water such that the only thing reflected is the sky, which you'd see with a cubemap anyway, I think you can actually specify a specific texture to be used instead of cubemaps, so in theory you could make a special water texture which reflects the skybox, and then use a walled off cubemap for everything else. Also if you still have stuff textured with the invisible texture then replacing it with nodraw would probably fix the engine hunk overflow a bit, as I think it still compiles lightmaps for invisible textures and engine hunk overflow is basically source saying 'too much crap, don't want to load', and lightmaps are a fairly sizeable portion of the crap.
While it's an utterly dreadful hack, I'm inclined to agree about the shininess of everything. However, using a cubemap for water reflections with that hack wouldn't work so well. Surfaces will choose the closest cubemap for their specularity. Unless you specifically apply the darkness cubemap to every surface on the map, trouble will brew. Anyone having FPS trouble should probably have water reflection turned down anyway.
Hence why I suggested editing the water texture to specify the skybox instead of looking for the nearest cubemap. Cubemap is not a specific texture, it's like a standin that tells the compiler to insert the nearest cubemap texture into the environment map slot for all materials, however you can also manually specify a environment map in the vmt, so any texture can reflect any other texture specifically, not just the nearest cubemap. Alternatively you could make a skybox room further from the map than the dark room and tie it to the water faces manually, which would be much easier than vice versa, the map would default to the dark room texture but the water would use the specified cubemap. I also wouldn't call it a hack, considering it's really just how you would normally make that sort of texture, a cubemap is just a 360 degree render, so it's more like repurposing an existing engine feature to easily make and apply an environment map without having to make an entire different set of VMTs for each map.
