will2k

This event had a profound future effect on humanity and the whole world; fixed it for you But seriously, a nuclear disaster was then a reality instead of just a possibility and people had to deal with actual heavy consequences. The world started panicking and the fact that East Europe had similar poorly-maintained nuclear plants only made things even worse. I was in elementary school at the time and I still remember my parents and adults in the neighborhood clearly worried whether the nuclear fallout will reach us (roughly 1200 miles/1930 km from Chernobyl), especially after news started pouring down that the radioactive particles reached Sweden located at 680 miles/1100 km from the ground zero. And it was the 80s, so communication and news were slow compared to today, which made uncertainty even scarier. STALKER is awesome btw

Shawn, this is awesome I second @Squad's idea: a sticky or better yet, a spotlight? @Sprony, @FMPONE thoughts?

RIP FPS...unplayable...unacceptable.../s

The walls in the first screenshot definitely need a floor level and ceiling level trim to break the blank wall up (like in nuke or office for example) I like the outside shot's color and architecture; it screams hi-tech quirky start-up . Maybe another lighter brick texture could suit better (from train)? Readability should be very nice in this one, keep it up

So...can we synchronize on top of this tower? sorry, wrong game Looking good, keep it up

Here you go

What is this? This is a simple roadmap of my optimization papers/articles for any newcomers to Source optimization or for folks who would like to further strengthen their knowledge about the subject. The goal eventually is to produce solid, well optimized maps. I keep seeing some simple questions being asked such as “what’s a hint brush and what does it do? Where do I place an areaportal? I also see many confusion and misconceptions about Source optimization on topics such as visleaves and PVS. Many folks contact me saying “hey, I read your paper/article X but I missed/wasn’t aware of your paper Y, Z, U, V…which is an additional reason of having this roadmap in one place for people to use for navigation through the different hoops of Source optimization. The roadmap Think of this roadmap as a course syllabus depicting the various topics and logical progression of the course, in this case, Source optimization. 1- Man vs Engine This is a comprehensive paper covering the process of optimization in the Source engine and providing a systematic approach to be used for winning your optimization battles. This paper should be the first step in your optimization course and it shouldn’t take you more than an hour on a slow evening to finish the read. It is a good idea to keep the Valve developer community wiki open if you need to look up the definitions of any terms that you come across in the paper (to be on the safe side, read the entry related to visibility optimization which contains all the keywords definition like hints, areaportals, etc…). 2- Optimization Testing in Source Engine It’s a technical paper tackling the issue of methodically testing the frame rate and optimization system in the Source engine. This should be the second read after Man Vs Engine to get a solid grasp of map performance testing. Practical work: test the average fps using the timedemo technique on a map of yours (or a stock map if you do not have a finished map yet). Practice all the testing console commands that I gave in the paper to become familiar with them. 3- Demystifying Source Engine Visleaves This is an article in which I explain Source visleaves in layman's terms to allow beginners and veterans alike to understand the cornerstone of source optimization. After the first 2 papers being more hands-on and practical, this 3rd read in the roadmap is more on the theoretical side to allow one to fully understand the inner workings on Source’s BSP and visleaves systems. 4- Source Engine PVS - A Closer Look This is an in-depth technical article where I delve into more details about the PVS creation and visibility calculation and their implication on optimization in the Source engine. This 4th read is a natural follow up to the previous article and will cement your intimate knowledge of Source engine. 5- Common Misconceptions in Source Engine Optimization It’s an article in which I identify common misconceptions in Source engine optimization process to help demystify some optimization “myths” and bust them once and for all, thus allowing designers to avoid the costly pitfalls that could hinder their maps’ optimization setup. This 5th step in the roadmap should come as an easy read once you understood the previous 2 steps (visleaves and PVS) 6- Hints about Hints - Practical guide on hint brushes placement This is a technical article in which I showcase how I think about and approach hints placement in Source engine and how I systematically proceed with hint brushes with practical examples. With the theoretical side taken care of in the 3 previous steps, it’s now time to dive into the technicalities of using hint brushes properly and efficiently, and this article will amply show that. Practical work: make a small test map where you can test the different hinting techniques that I showcased in the article. Make a version with hints and one without and test in-game using mat_leafvis and mat_wireframe console commands to see hints live in action. 7- Practical guide on areaportals placement It’s a technical article that deals with the systematic placement of areaportals in the Source optimization process. This is the 2nd article in the "practical placement guide" series. As with the previous step, this one dives deeply into proper areaportal placement with solid examples. Practical work: make a small test map where you can test the different areaportals techniques/locations that I showcased in the article. Make a version with areaportals and one without and test in-game using r_drawportals, mat_leafvis, and mat_wireframe console commands to see areaportals live in action. 8- Practical guide on occluders placement It’s a technical article that tackles the systematic placement of occluders in the Source optimization process. This is the 3rd and final article in the "practical placement guide" series. Occluders have always been a grey area and a big question mark for a lot of designers, and this article will clearly showcase how to practically proceed with them in your map, if needed. Practical work: make a small test map where you can test the different occluders techniques/locations that I showcased in the article. Make a version with occluders and one without and test in-game using r_visocclusion, r_occlusion, and mat_wireframe console commands to see occluders live in action. 9- Comparative fps study in Source Engine Optimization System This is an in-depth article where I showcase the clear difference between having a solid optimization system and not having one in a Source engine map. The article will have plenty of numbers, for a complete comparative study that shows the frame rate variation with and without the optimization system in place. If you have read and followed this roadmap closely, then you are now ready to witness and understand the importance of a good optimization system and the consequences of not having an effective one on the overall frame rate. Practical work: In one of your maps, uncheck the visgroups of hints/areaportals/occluders in Hammer and save it under a different name. Compile it on final settings then compare the fps with the original version that had all the visgroups enabled to see the difference. 10- Source FPS Cost of Cheap and Expensive Assets It’s a short technical article that compares the frame rate cost of cheap vs. expensive assets in Source engine optimization. In the same spirit of the previous step, this one shines the spotlight on the cost of expensive assets so one doesn’t go wild while using them in their map, at the risk of considerably affecting frame rate. 11- Displacement Vs. Func_detail - A comparative fps study It’s a short technical article that aims at comparing the frame rate of func_detail vs. displacement in the context of the Source engine and the repercussion on their usage in maps. 12- Optimizing An Open Map in Source Engine This is a technical article that showcases how to tackle optimizing open maps in Source engine. Conclusion The roadmap presented above should cover “optimization 101” through “501” courses and cater for a broad range of Source engine users. There are no more reasons for one to feel confused and “not sure where to start/look” when it comes to Source optimization. If after reading and experimenting with all the above you still have some questions about optimization, then feel free to post here and I’ll try my best to help. Once you finish all the reading with all practical work, please pass by my office so I can schedule your final exams. Happy reading

Digging the urban architecture

Simon And Garfunkel - Mrs Robinson

Today, this thread is exactly 2 years old...YAY Some more progress shots

I really like the new art direction with all the white stone instead of colored plaster that is more typical to western parts of Mediterranean Europe. The areas surrounding site A are my favorite (I'm a sucker for trees and seaside green rolling hills ) Just a couple of quick notes: You have some floating props (chairs/tables) in patio near CT spawn - screenshot 1 Some stone textures are extremely oversized and could use a slight scale reduction (screenshot 5-house with green shutters). If the texture is left at default scale of 0.25 then you might experiment with lowering it to around 0.15-0.2 then adjust accordingly. Bomb site B has a lot of dark textures mainly black tile floor and black marble counter etc. It could use a bit of lighting up by using slightly lighter textures (check the new ones in de_nuke for example) Keep up the good work

Better Call Saul Every episode is more awesome than the previous one; the writing, the actors, the camera work are all brilliant. If you watched Breaking Bad before, then you are in for a treat with all the parallels, references, and Easter eggs that point to BB in BCS.

I was reading comments last week on another community and someone hilariously predicted that season 7 first episode

Thanks for the info I don't think a prop transition from high to low poly in-game would make such a big difference on gameplay (overall shape, color, size, collisions...are basically the same). Maybe it was something to do with the new modified engine in CSGO? or they got lazy and didn't implement it back in the new Source . As Pampers mentioned, having LOD would help a lot with frame rate especially on the new de_nuke. One could set a prop to fall back to low poly at 512-1024 units from player depending on size then implement props fade distance at 1600 units (just an example) for the ultimate fps saver.

Thanks everyone for the comments and the active discussion @Pampers: Source should be already relegated to the "classics" category instead of still being in the "active engines" category; it's long overdue in 2016 I'm no modeler or 3D artist, but out of curiosity, doesn't source use LOD? or did you mean it's an inefficient system in Source? @ laminutederire: I'll list some of the props used in the test maps along with their triangle count to give you an idea (both high and low poly versions) nuke_sedan02 4608 nuke_sedan02_low 1990 nuke_roof_ac02 1712 nuke_roof_ac02_low 621 metal_crate_001_128x112x256 5555 metal_crate_001_128x112x256_low 2623 metal_door_002 1032 metal_door_002_low 582 metal_pipe_001d_corner_large 832 metal_pipe_001d_corner_large_low 224 @ leplubodeslapin : Salut Sylvain. There will always be room for in-depth follow-up articles The main purpose of this short article was to showcase that there is a significant effect on fps when "over-using" expensive assets especially after the new de_nuke update.

I published my latest article titled Source FPS Cost of Cheap and Expensive Assets. It should shed some more light on the effect of expensive assets on Source optimization and highlight the effect on frame rate drop that was evident in the new de_nuke (high amount of expensive props/textures in the playable area).

Thank you . Glad you liked these articles and found them helpful. Thanks seir The points you mentioned are a bit advanced and could be the topic of a future article that goes further deep in the study; bear in mind I'm no programmer but it will be interesting and useful as you mentioned. Will keep this in mind for future articles that I plan to write As for PIX, AFAIK it is now deprecated and it is currently part of the windows SDK, more precisely the Microsoft Visual Studio called Visual Studio Graphics Debugger. I will see if there are other alternatives for the PC as you mentioned the Crytek one, so there's bound to be others Thanks again for the insights. Thanks for the uplifting comment and the continuous support

Too late to audition for myth busters? Seriously though, great work Shawn Despite the low turnout (it's quite normal for a 1st contest into new territory though), the entries were nice and showed craftsmanship with brushwork-only restriction and no Hammer involved I take this opportunity to congratulate the winners and best of luck for contest #2.

More progress in beta1

Season 6 finale...

IF (that's a capital if) your map is tightly optimized then there will be a slight dip in fps if you leave everything as world brushes; but if your map is not well optimized then expect a bigger hit. I have already tackled this issue in a previous paper of mine Comparative fps study in Source Engine Optimization System and you can check in the paragraph titled func_detail that the fps dropped around 10 fps when I switched my func_detail back into world brushes in a well optimized map. You are basically forcing the rendering engine to search the BSP tree with a bigger and messier PVS to render the content of leaves tagged 1 in the PVS array. The smaller and simpler the PVS, the quicker the engine can draw the information. When you start implementing hints and areaportals, your visleaves will be divided and if you already had a big number of leaves, then expect the number to even grow much bigger, further adding to the above effect. Lastly vvis will likely take forever to finish and you will rage quit long before the end Vaya gave you a nice pointer about func_detail ; don't be afraid if large chunks of the level are func_detail as long as you have backbone world brushes to cut visibility, help implement hints/areaportals/skybox brushes, and seal the level. All this is nicely explained in my paper Man vs Engine (paragraph III.5) and in my article about common misconceptions in Source optimization. Hope this helps and good luck with the map

Thanks Vaya for weighing in with all the info @Trashbang: read my optimization papers in my signature below; 2 specific articles should clear up all your questions about visleaves and PVS. Demystifying Source Engine Visleaves Source Engine PVS - A Closer Look I'll quote one line of the first article Unless the extra visleaves are practically empty (such as upper skybox leaves), additional visleaves means more content to render, therefore in general, lower fps. For hints/areaportals, check my 2 papers on "practical guide" series as well as my paper Man vs Engine for the full scoop. Knock yourself out and enjoy the read