Jump to content

JSadones

Members
  • Content Count

    88
  • Joined

  • Last visited

  • Days Won

    3

Reputation Activity

  1. Like
    JSadones reacted to Radu for an article, 2018: Mapcore's Year in Review   
    Keeping with tradition, I'd say it's about time we took a look at what our community has achieved throughout the year. If last time I was saying how 2017 was a year of immense growth, then 2018 was surely one of significant change. And it hasn't been without its troubles and anxious moments. No change ever is, but I believe it to be for the best. We've seen some of our friends become parents, change work fields or get their first job in the industry. We've even seen a few pursue their dream projects. And for that, we have to applaud them. It takes courage to keep moving forward and to realise when it's time for something new. In the meantime, I hope this article inspires you and I wish everyone 
    good luck!
     
    2018: Mapcore's Year in Review
     

    SteamVR - Gulping Goat Space Farm
    by @Steve, @marnamai, @The Horse Strangler, @Sersch and others at Scraggy Rascal Studios
    produced in collaboration with Valve
    "Scraggy Rascal has been working with Valve to create all new SteamVR content, we've been given a lot of liberty to create these locations. Our goal was to create interesting and fun locations for the player to explore. These projects, over the last couple months, have been a crash course in Source 2,VR, project management, delivering within deadlines, working together as a team and personal growth. It has been an invaluable experience and great opportunity ... and we're just getting started!" - marnamai
     

    Darksiders III - Art
    by @The Horse Strangler and others at Gunfire Games
    "Probably one of the biggest challenges the artists and designers faced on Darksiders 3 was working with both a platforming and fully connected streamed world. This meant that everything exists all the time. While we streamed levels in and out, areas couldn't intersect and we couldn't do the classic "Small exterior, big interior" swap. This was especially challenging because of how much verticality our design must support. We had a few "vistas", but for the most part every aspect of the level was accessible. If you can see it, you will likely be able to get there, jump on it, fight around it, etc. Fury, the main playable character can double jump, swing, float, glide and even rocket jump over 10 meters high. Personally for me it completely changed how I looked at art filling up a space. Every single mesh we placed impacted design. Art was design, and design was art." - The Horse Strangler
     

    Europa
    by @[HP]
    "Europa is a relaxing narrative experience. The goal with this game is to offer just enough challenge that its rewarding to get from one area to the other for more than just the visuals by using environmental hazards, platforming sequences and light puzzles that you can beat by exploring.The game is split into linear sections and wider areas, that's at the core of the game and as you play, you keep improving your characters moving ability, which will further exploration and give you the ability to solve newer light puzzles. There's none of the typical character upgrading systems, rather, the levels will offer the incremental challenges and the sense of progression. Europa's main focus lies in environmental storytelling and immersing the player in it's universe with passive storytelling, evoking awe and bliss with colorful watercolor-like art and music." - Helder Pinto
     

    Counter-Strike: Global Offensive - Turnpike
    by @Squad
    "For a while the "Highway Restaurant" theme has been sitting in my little Concepts.txt file. When the Wingman Contest was announced, it felt like the perfect opportunity to turn this idea into a map, as its relatively small size would be fitting for the Wingman gamemode. The casual nature of Wingman made me add some elements that I would not normally add to, let's say, a Defusal map, like the TF2-esque team color coding (albeit subtle), the moving vehicles and the silly bomb target. Additionally, since the playable space is (almost) completely indoors, making it nighttime felt right, as it both emphasizes the interiors and makes for an atmospheric blorange background." - Squad
     

    Dying Light - A New Hope
    by @will2k
    "A full-fledged custom single player campaign that ties in to the original story of the main game. It will see the main protagonist, Kyle Crane,leaving the City for the countryside to search for a specific elusive medicinal herb and bring it back to Dr. Camden who believes it could be the cure to the Harran Virus. This campaign is a one man show as I’m doing everything myself: level design, environment art/detailing, story creation, scripting/quest creation, custom dialog, custom audio, custom materials/textures, custom foliage systems, custom brushes for terrain painting/sculpting, lighting, manual nav mesh tuning, scripted NPCs…" - will2k
     

    Prodeus
    by @General Vivi and Michael Voeller
    "Prodeus is the first person shooter of old, re-imagined using modern rendering techniques. Oh, and tons of blood, gore, and secrets. Creating Prodeus has meant a lot to us over the last year. It feels great to finally be doing something for ourselves. It can be pretty ambitious at times since there are just two of us, but I’m confident we can pull it off. Keep an eye out for the end of February for a big announcement." - General Vivi
     

    Counter-Strike: Global Offensive - Ruby
    by @catfood
    "When I was on vacation in Portugal years ago I was so impressed by the city Lisbon that I really wanted to build a map that has the same vibe. At the time I was already working on different projects so I decided whenever I got enough time to work on a map this size I would go back. So early 2017 the moment was finally there, I went back to Lisbon to shoot (~2000) reference photos then made a list of things that are iconic for Lisbon and started working on Ruby. Adding a lot of height differation, warm colors, tile patterns and ofcourse trams was essentiental to get the Lisbon vibe." - catfood
     

    Subnautica
    by @dux, @PogoP and others at Unknown Worlds Entertainment
    "A mix of Survival, story, mystery, resource gathering, base building with some accidental horror and plenty of deep, deep water. We had not long finished up with Natural Selection 2 and were hungry to develop a different kind of game. During development we were (and still are) a small team but the game kept getting bigger and grew into something far larger in scope than originally planned. So we soon realised that what we had could be turned into something really unique if we put our heads down and just cranked on it." - dux
     

    Unreal Tournament 4 - Chamber
    by @Ubuska
    "I used Halo and Warframe artstyle as a reference. The goal of this project was to make fun and cool looking map with 100% custom art that is 100 mb in file size. To achieve that I used several advanced techniques such as custom vertex normals, deferred mesh decals, no bake, tiling base materials and masks. There are basically 5 or so texture maps used in the entire map,  most of the filesize space was taken by lightmaps. I learned a lot doing this project in terms of composition, art direction and optimization. Hope you enjoy this map as much as I do!" - Ubuska
     

    Counter-Strike: Global Offensive - Pitstop
    by @Quotingmc and Quadratic
    "It is not often that CS: GO receives a new game-mode, especially one as competitively focused as Wingman. I was understandably pleased at the announcement of the 2018 CSMapMakers contest for the mode. Pitstop was my entry where I set out to create a thematically bold centre piece for my portfolio. With the help of my teammate Quadratic and support from multiple Mapcore members, I learnt a lot about taking a level from a simple blockout to completion; I can say for certain I’m thrilled with the end result!" - Quoting
     

    Black Mesa - Xen
    by @JeanPaul, Adam Engels and others at Crowbar Collective
    "While building Xen we had to design, iterate, and iterate (then iterate some more). We took what we thought we knew, and put it to the test. We learned how design and scope work together, and how to build momentum as a team. We are extremely proud of what we have accomplished over the year(s)! Despite the long and occasionally frustrating timeline, it has been a real testament to the commitment that this team and this community have for Half-Life." - Adam Engels
     

    Unreal Engine 4 scene
    by @Vorontsov
    "So I decided I would step out of my comfort zone and create a small environment in an engine I've never used before, UE4. Although I think I did a fairly decent job at the time there were ultimately many nuances I could have done better, but that is the artist dilemma. This project taught me the value of properly blocking out your environment, gathering as many references as you can and to have patience and not rush through assets, when breaking any of these rules I was punished for it. Stay tuned for my next project which will be a giant mech, coming soon Valve time TM." - Vorontsov
     

    Counter-Strike: Global Offensive - Opal
    by @MikeGon
    "My goal with this project was to make a fun and compact defuse map, with a simple level flow, ample verticality, and an overlapped layout! I wanted to have interior and exterior, and break the grid a lot, to avoid having that "90 degrees grid" feel in the layout. I needed to have a vista on one side of the map to help with orientation, so I decided to make it a coastal town, inspired by those found on the island of Skopelos, Greece. Expect more updates in the near future, as I'm not yet satisfied with it. Since this is my only CSGO map, I want to put all my time and effort into it, and focus on quality instead of quantity. Thank you everybody for your support and feedback! <3" - MikeGon
     

    Insurgency: Sandstorm - Precinct
    by @Xanthi, @Squad, @Jonny Phive, @LATTEH, @Steppenwolf and others at New World Interactive
    "Precinct, was a fun and challenging map to work on. We decided early on to melt District and Contact two of our very nostalgic maps together into a single large-scale urban environment. The goal was to preserve the nostalgic feeling and at the same time create something unique and fresh not just a 1:1 copy. In the block-out stage we started playing with different terrain heights, which eventually was the key to accomplish our goal. Terrain height was a bit of a trial and error process; I remember driving up a hill and not having enough torque, oops!!" -Xanthi
     

    Counter-Strike: Global Offensive - Killhouse
    by @FMPONE
    "Killhouse showcases brutal duels, player reaction times, and close-quarters combat. A highly vertical layout ensures the sort of unpredictability and replayability ideal for CS:GO’s 2vs.2 "Wingman" game-mode." - FMPONE
     

    Counter-Strike: Global Offensive - Station
    by @Roald and @untor
    "All experiences contribute to where I am at this point. I am just a hobbiest but I think I learned alot about level design just by doing it and enjoying it. Overal my goal is to improve myself on level design, but also enviorment art. I think I archieved a goal on level design and it's now time to continue on enviorment art. This is where untor morozov comes in. I have met untor a while ago. He made this map 'Waterfall' which was pretty populair. I liked his designs and added him as a friend. When I had this wingman map going on with positive feedback I just contacted him again to work on it with me and since this moment we have had a incredible teamwork. I am gameplay orientated and he is art orientated so we were a great couple. We just enjoyed work on this project and respected eachother and had alot of fun." - Roald
     

    The Gap
    by @Yanzl and Sara Lukanc
    "The Gap is a sci-fi thriller first person narrative exploration video game. You play as Joshua Hayes, a neuroscientist trying to figure out what happened, barely remembering anything about his past. It started as a project for our BA thesis and has now grown into a standalone game. It's also my first "real" indie game project, helping me learn a lot about Unreal Engine 4 and game development in general." - Yanzl
     

    Counter-Strike: Global Offensive - Alexandra remake
    by @Serialmapper
    "My first successful map was born 10 years ago for CS1.6. It was done in just 4 days. Since then it has been ported/improved several times on CS:S then finally on CS:GO. It always had a "dust" theme. Initially i wanted to remake it with an "inferno" style but when the new dust2 came i switched the plan to use the new assets. The map was and is frequently played on public servers especially in Eastern Europe so i had plenty of feedback to improve it. For some it's just another "dust" map, but for me it's my dust2." - Serialmapper
     

    Far Cry 5 - Wetland Turmoil
    by @grapen
    "I wanted to try working with location design in an (imaginary) open world game for the first time, so I made this backwater cabin neighborhood. At the time I also wanted to see what the limits were in Farcry Arcade and how far I could push it. The level has fixed spawns (a limitation of the editor), but I toyed with the idea of making it work regardless from which direction the player would have approached it. The pathing and player guidance is more or less shaped like the number eight, with the church acting as an outlook. Your task is to eliminate all the bad guys. In the end I wanted to do so much more, but couldn't due to technical limitations. All in all it was a fun experience to make it." - grapen
     

    Counter-Strike: Global Offensive - Trailerpark
    by @OrnateBaboon and @Skybex
    "We wanted to make a map for CSGO, using a theme that had not been seen in any previous version of Counter-Strike.The map had to incorporate everyday plausibility, provide for enough variety so that things remained visually interesting,  but also be flexible enough to allow for the use of low geometry for easy grenade strategies. Being able to immediately recognize a theme in a map is always important, so with all this criteria in mind, A trailer park fitted the bill perfectly. There is still some way to go before a full release, but 2018 was a great year for progress on this project." - OrnateBaboon
     

    Unreal Engine 4 scene
    by @Corvus
    "I was inspired by games like stalker and the last of us. The goal was to make something photoreal with a lot of foliage. It took a couple of iterations but I think I achieved the goal in the end. While making this project I've had to learn a lot about Speedtree to make all the foliage, it was a really cool experience. Right now I'm in the army so unfortunately I can't make any more scenes right now, but after I'll come back I'll try to make more scenes like that." - Corvus
     

    Overwatch - Busan
    by @Minos, @[HP], @PhilipK, @IxenonI, Phil Wang, Lucas Annunziata and others at Blizzard Entertainment
    "Busan was a challenging map to make. Due to the game having 12 different heroes on screen we have a somewhat limited memory budget for maps, that includes all models, textures, effects, collision data, lighting information, etc... Fitting three radically different areas (Downtown, Sanctuary and MEKA Base) into one single map budget required us to find new ways to optimize our work. In the end, we were even squeezing kilobytes out of collision data to make it all fit, no kidding! But the result speaks for itself, the map was fun to work on and we are very proud of what we accomplished!" - Minos
     

    Counter-Strike: Global Offensive - Highlands
    by @ElectroSheep, @El Moroes and @'RZL
    "We wanted to make a map in Scotland because, thanks to dishonored 2, we were browsing a lot of references froms this area and we really loved it. I also went myself here in holliday after that. We asked one of our close friends to make some special props, like the police van, the taxi, the phonebox and some others. Unfortunatly the hard development of Dishonored 2 put us in a difficult state where we weren't able to work on the map. So we lost motivation. Then RZL contacted us because he didn't want the project to die so we gave him the keys. And RZL became busy too ^^. Life sometime say NO I guess, hehe. Now Highlands Is my only advanced project I still didn't finished and I'm ready to give it a try, I hope." - ElectroSheep
    "Highlands...is this map is a joke? Certainly no but we can say that the development is quite longer than what we expected. Perhaps we learn well how the famous "Valve time" works? :p No seriously I think we can explain that with the motivation. Of course we were motivated to create something cool with this map but with the time and, I think, with what we live in our life we never took the time to do it correctly...I mean we never had a constant rythm on the map. This (and other personal things) led to the current statut of the map; a still "work in progress" map started in 2014. But ElectroSheep came back and his goal is to finish it, and because he's right, I'll come back too to help him. Just, be patient (again) ;)" - El Moroes
     

    Battlefield V - Fjell
    by @Puddy, @Pampers and others at DICE
    "Fjell was an explosive experiment which paired a new Battlefield dynamic, planes and infantry only, with an epic gosh darn mountain top. Tackling this design combination was like dealing with a bear after you've kicked it in the balls. It was a fun challenge and even though its extreme gameplay is quite polarizing when compared to more middle-of-the-road maps, I am happy that we went there!" - Puddy
     

    Counter-Strike: Global Offensive - Iris
    by @BubkeZ and @Oliver
    "Iris was born out of a shared interest in the TV-show "Seinfeld", funnily enough. One day BubkeZ noticed I had changed my Steam profile picture to a photo of "George Costanza" and just like that the wheels were in motion! In the beginning, BubkeZ had the vision of an old city environment with lots of dirty alleyways and brick architecture. We didn't want to fall in the trap of making the map look too bleak, so we came up with the idea of making a mid-century town set in autumn. While the map certainly have visual elements from the 50's, I would say the overall theme of Iris is american auto-industry. Making the old cars was definitely my favorite part of making this map!" - Oliver
     

    Unreal Engine 4 scene
    by @Brightness
    "I have always been a fan of retro and vintage, so this was like a dream to me. After watching the first season of True Detective, I immediately fell in love with the office set and the way the series was shot. I have definitely learned a lot from this project, mostly lighting techniques that can fill your scene with a story. The goal was to recreate their environment in my own style, and I'm pretty satisfied with how it turned out. I definitely wasn't expecting this much of positive feedback and I'm really thankful for this community. I want to do something with the environments, not just as a portfolio piece, but make a short film or make a small adventure game out of them." - Brightness
     

    Counter-Strike: Global Offensive - Insertion 2
    by @Oskmos
    "Being the follow up to the first Insertion it will have the same overall concept with the spawning and open-world like layout. However this time it will be a more urban setting and overall higher quality art assets. I always love to make environments that feels real. And that are familiar. Its all made up. But the details and various elements in Insertion 2 is from my childhood basically. Friends that grew up in the same place I have recognizes it aswell." - Oskmos
     
    _______________________________________________________________________________________________________________________________________________
    _______________________________________________________________________________________________________________________________________________
     
    The Door Challenge

    Submission thread
     
    Articles

    Designing Highly Replayable Stealth Levels for Payday 2

    Level Design in Max Payne: Roscoe Street Station

    Effect and Cause - Titanfall 2 Level Breakdown

    2017: Mapcore's Year in Review
     

    Hurg smiles upon you all!
  2. Like
    JSadones reacted to General Vivi for an article, The Door Challenge - 2018   
    THE DOOR CHALLENGE!
    I want to start out by welcoming you to the 2ND Door Challenge! It’s been a little over 7 Years since we held the first one! A lot has changed in our industry and new engines have made level design more accessible than ever before. With all the fresh talent coming into our industry, I think it’s important that we challenge ourselves and each other to push our creative thinking.
    This challenge is meant to be for everyone to join in, from your first time level designer to your Senior and Lead Designers! Everyone is in a different place throughout their careers and it’s always fun to hone your skills on one of the most old school puzzles of our time “Get the Door Open!”. The last time we did this we had a fantastic turn out of completed and submitted puzzles! Especially since we are focusing on JUST design and scripting and NOT on art!
    As this is a scripting challenge, you are encouraged to use Dev textures or simple greyscale materials and only what art assets are absolutely necessary to communicate key ideas. The point is to focus on your Scripting / Presentation / Storytelling / Puzzle Making skills.
    Most entries generally took a few days to build from start to finish, so don't sweat worrying about the deadline. If you would like to get a better idea, check out some of the entries from the first door challenge.
    Remembering our Past
    SOLEVAL - First Place
      Magnar Jenssen - Participation
      Robert Yang - Participation
    Jason Mojica - Participation
    Rules and QA
    Build a puzzle and craft a story to creatively open “The Door”! It doesn't matter whether you're entering, exiting, or just moving from one room to another - just get that DOOR OPEN!
    Acceptable Engines : UE4 / Unity / Source SDK
    For UE4 or Unity, you will be REQUIRED to provide an EXE of your game
    For Source SDK, a simple bsp will do with info on the game you built it in. (Eg. Half-life 2, Portal 2, CS:GO, TF2)
    We encourage you DON’T use Art unless needed to sell your idea. Simple meshes / Dev textures / grey textures should do fine.
    You are ALLOWED to use Templates to start yourself off. Example: UE4 has a FPS , Third Person , and VR template.
    You are ALLOWED to use existing scripting/ blueprints or Code to help you make your puzzle.
    You CAN choose - First person, Third Person , Virtual Reality (VR)
    DON’T submit anything larger than 250 mbs , we want simple entries that everyone can download.
     
    The challenge will begin Friday, August 10th, and end Sunday, September 16th at 11:59PM US CENTRAL time (GMT -6)
     
    Must Haves :
    A zip file including your EXE or map file
    2 screenshots of your scene (ATTACHED! This will help us archive our entries for posterity)
    A video showing the puzzle's intended solution (hosted on youtube would be fine)
     
    Optional :
    Full Name (optional)
    Website or Portfolio (optional)
    The original level source (and any other relevant files) for inquiring minds to examine your scripting
     
    Judging : We will start judging the day after closing, Everyone will get 3 votes and then we will vote on the top 3 one week later. Things to think about when judging or making an entry.
    Innovation - More than just a simple Door!
    Theme - How close did you stay to the idea of the challenge
    Readability - Was your idea clear and easy to understand?
    Humor - Did you make someone laugh or enjoy your entry?
    Overall - Wrap everything together! Was it awesome?
    Door - Q: How much Door you got? A: Hell yes
    Prizes
    As with the previous challenge, there will be no prize other than the pride of knowing people thought you were awesome. Woo!
     
  3. Like
    JSadones reacted to Radu for an article, 2017: Mapcore's Year in Review   
    (New logo by Yanzl)
    I'm sure that by now most of us have our sleeves rolled up and are ready to tackle yet another year, but before we move forward let's take a moment to look back at what 2017 meant for our community. It was a time of immense growth for both professionals and amateurs alike. A time when everyone seemed to have surpassed their former selves. And without slowing down, some have even managed to land their first job in the industry. I don't know what this new year holds, what challenges to overcome will arise, but I know for certain that I'm excited to see everyone become even greater!
     
    2017: Mapcore's Year in Review
     

    Overwatch - Oasis
    by Phillip K, Bram Eulaers, Helder Pinto and others
     

    Dishonored 2: Death of the Outsider - Curator level
    by electrosheep, kikette and others
     

    Payday 2 - Brooklyn Bank level
    by General Vivi
     

    Sniper Elite 4 - Regilino Viaduct
    by Beck Shaw and others
     

    Counter-Strike: Global Offensive - Offtime
    by Squad
     

    Team Fortress 2 - Shoreleave
    Art pass, props and sound by Freyja
     

    Wolfenstein II: The New Colossus - Farmhouse
    Modeled, textured and composed by BJA
     

    Half-Life 2: Downfall
    by marnamai
     

    Counter-Strike: Global Offensive - Studio
    by ZelZStorm, TanookiSuit3 and Hollandje
     

    Portal 2 - Refraction
    by Stract
     

    Counter Strike: Global Offensive - Breach
    by Yanzl and Puddy
     

    Counter-Strike: Global Offensive - Berth
    by grapen
     

    Counter-Strike: Global Offensive - Kaizen
    by Andre Valera and Jakuza
     

    Counter-Strike: Global Offensive - Asylum
    by Libertines
     

    Half-Life 2: Episode 2 - FusionVille: The Shadow over Ravensmouth
    by Klems
     

    Unreal Engine 4 scene
    by Dario Pinto
     

    Counter-Strike: Global Offensive - Grind
    by The Horse Strangler, `RZL and MaanMan
     

    Counter-Strike: Global Offensive - Aurelia remake
    by Serialmapper
     

    Counter-Strike: Global Offensive - Tangerine
    by Harry Poster
     

    Counter-Strike: Global Offensive - Abbey
    by Lizard and TheWhaleMan
     

    Counter-Strike: Global Offensive - Apollo
    by Vaya, CrTech, Vorontsov, JSadones
     

    Counter-Strike: Global Offensive - Sirius
    by El Exodus
     

    Unreal Engine 4 scene
    by Corvus
     

    Counter-Strike: Global Offensive - Subzero
    by FMPONE
     

    Counter-Strike: Global Offensive - Biome
    by jd40
  4. Like
    JSadones reacted to leplubodeslapin for an article, Source Lighting Technical Analysis: Part One   
    After the announcement of the Reddit + Mapcore mapping contest, the website has welcomed many newcomers. A proof that, even if it is a twelve year old game engine, Source engine attracts map makers, and there are lots of reasons for that. It is common knowledge that technology has moved forward since 2003, and many new game engines have found various techniques and methods to improve their renderings, making the Source Engine older and older. Nevertheless, it still has its very specific visual aspect that makes it appealing. The lighting system in Source is most definitely one of the key aspects to that, and at the end of this article you will know why.
     
    About the reality...
    Light in the real world is still a subject with a lot of pending questions, we do not know exactly what it is, but we have a good idea of how it behaves. The most common physic model of light element is the photon, symbolized as a single-point particle moving in space. The more photons there are, the more powerful light is. But light is in the same time a wave, depending on the wavelengths light can have all kind of color properties (monochrome or combined colors). Light travels through space without especially needing matter to travel (the space is the best example; even without matter the sun can still light the earth). And when it encounters matter, different kind of things can happen:
    Light can bounce and continue its travel to another direction Light can be absorbed by the matter (and the energy can be transformed to heat) Light can go through the matter, for example with air or water, some properties might change but it goes through it And all these things can be combined or happen individually. If you can see any object outside, it is only because a massive amount of photons traveled into space, through the earth’s atmosphere, bounced on all the surfaces of the object you are looking at, and finally came into your eyes.
    How can such a complex physical behavior from nature be simulated and integrated into virtual 3D renderings?
    One of the oldest method is still used today because of its accuracy: the ray-tracing method. Just to be clear, it is NOT used in game engines because it is incredibly expensive, but I believe it is important to know how and why it has been made the way it is, since it probably influenced the way lighting is handled in Source and most videogame engines. Instead of simulating enormous amount of photons traveling from the lights to the eye/camera, it does the exact opposite. If you want a picture with a 1000x1000 resolution, you will only need to simulate the travel of 1 000 000 photons (or “rays”), 1 for each pixel. Each ray is calculated individually until it reaches the light origins, and at the end the result is 1 pixel color integrated in the full picture. 
    By using the laws of physics we discovered centuries ago, we can obtain a physically-accurate rendering that looks incredibly realistic. This method is used almost everywhere, from architectural renderings to movies. As an example, you can watch The Third & The Seventh by Alex Roman, one of the most famous CGI videos of all time. And because it is an efficient way to render 3D virtual elements with great lighting, it will influence other methods, such as the lightmap baking method.
     
    Lightmap baking
    OKAY LET’S FINALLY TALK ABOUT THE SOURCE ENGINE, ALRIGHT!
    A “lightmap” is a grid that is added on every single brush face you have on your map. The squares defined by the grid are called Luxels (they are kind of “lighting pixels”). Each luxel get its 2 own properties: a color and a brightness. You can see the lightmap grids in hammer by switching your 3D preview to 3D lightmap grid mode.

    You can also see them in-game with the console command mat_luxels 1 (without and with).
    During the compilation process, a program named VRAD.exe is used. Its role is to find the color and brightness to apply for every single luxel in your map. Light starts from the light entities and from the sky (from the tools/toolsskybox texture actually, using the parameter values that has been filled in the light_environment entity), travels through space and when it meets a brush face:
    It is partially absorbed in the lightmap grid A less bright ray bounces from the face Here is an animated picture to show how a lightmap grid can be filled with a single light entity:

    When you compile your map, at first the lightmaps are all full black, but progressively VRAD will compute the lightmaps with all the light entities (one by one) and combine them all at the end. Finally, the lightmaps obtained are applied to the corresponding brush faces, as an additive layer to the texture used on that face. Let us take a look at a wall texture for example.

    On the left, you have the texture as you can see it in hammer. When you compile your map, it generates the lightmaps and at the end you obtain the result on the right in-game. Unfortunately, luxels are much rougher, with a lower resolution, more like this.

    On the left you have a lightmap grid with the default luxel size of 16 units generated my VRAD, a blur filter is applied and you obtain something close to the result on the right in the game.
    In case you did not know, you can change the lightmap grid scale with the “Lightmap Scale” value with the texture tool. It is better to use values that are squares of 2, such as 16, 8, 4 or even 2. Do not go below 2, it might cause issues (with decals for example). Only use lower values than the default 16 if you think it's really useful, because you will drastically increase your map file size and compilation time with precise lightmap grids. Of course, you can also use greater values in order to optimize your map, with values such as 32, 64 or even 128 on very flat areas or surfaces that are far away from the playable areas. You can get more infos about lightmaps on Valve’s Wiki page.

    But as we said before, light also bounces from the surface until it meets another brush, using radiosity algorithms. Because of that, even if a room does not have any light entity in it, rays can bounce on the floor and light the walls/ceiling, therefore it is not full black. 
    Here’s an example:

    The maximum amount of bounces can be fixed with the VRAD command -bounce X (with X being the maximum amount of bounces allowed). The 100 default value should be more than enough.
    Another thing taken into account by VRAD is the normal direction of each luxel: if the light comes directly against the luxel or brushes against it, it will not behave in the same way. This is what we call the angle of incidence of light.

    Let us take the example of a light_spot lighting a cylinder, the light will bright gradually the surface - from fully bright at the bottom to slightly visible at the top.

    In-hammer view on the left, in-game view on the right
     
    Light Falloff laws
    One of the things that made the Source Engine lighting much more realistic than any others in 2004 is the light falloff system. Alright, we saw that light can travel through space until it meets something, but how does it travel through space? At the same brightness, whatever the distance is between the light origin and destination? Maybe sometimes yes… but most of the time no.

     
    Imagine a simple situation of a room with 1 single point light inside. The light is turned on, it produces photons that are going in all the directions around it. As you might imagine, photons are all going in their own direction and have absolutely no reason to deviate from their trajectory.
     
     
     
    At one time, let’s picture billions of photons going in all the directions possible around the light, the moment after, they are all a bit further in their own trajectory, and all the photons are still there, in this “wave”. But, as each photon follows its own trajectory, they will all spread apart, making the photon density lower and lower.
    As we said before, the more photons there are, the more powerful light is. And the highest the density, the more intense light is. Intensity of light can be expressed like this:

     
    You have to keep in mind that all of this happens in 3D, therefore the “waves” of photons aren’t circles but spheres. And the area of a sphere is its surface, expressed like this:

    (R is the radius of the sphere)
     
    If we integrate that surface area in the previous equation:

    With ♥ being a constant number. We can see the Intensity is therefore proportional to the reverse of the square of the distance between the photons and their light origin. 
    So, the further light travels, the lower is its intensity. And the falloff is proportional to the inverse of the square of the distance.
    Consequently, the corners of our room will get darker, because they are farther away from the light (plus they don’t directly face the light, the angle of incidence is lower than the walls/floor/ceiling).

    This is what we call the Inverse-Square law, it’s a very well-known behavior of the light in the field of photography and cinema. People have to deal with it to make sure to get the best exposure they can get.
    This law is true when light spreads in all possible directions, but you can also focus light in one direction and reduce the spread, with lenses for example. This is why, when Valve decided to integrate a lighting falloff law in their engine, they decided to use a method not only following the inverse-square law but also giving to mapmakers the opportunity to alter the law for each light entity.
     
    Constant, Linear, Quadratic... Wait, what?
    In math, there is a very frequent type of functions, named polynomial functions. The concept is simple, it’s a sum of several terms, like this:

    Every time, there is a constant factor (the “a” thing, a0 being the first one, a1 the second one, a2 the third one...), multiplied with the variable x at a certain degree:
    x^0 = 1 : degree 0 x^1 = x : degree 1 x^2 : degree 2 x^3 : degree 3 ... And
    a0 is the constant named “constant coefficient” (associated to degree 0) a1 is the constant named “linear coefficient” (associated to degree 1) a2 is the constant named “quadratic coefficient” (associated to degree 2) Usually, the function has an end, and we call it by the highest degree of x it uses. For example, a “polynomial of the second degree” is written:

    Then, if we take the expression from the inverse-square law, which was:

    With a2 = 1 and D being the variable of distance from the light origin.
    In Source, the constant ♥ is actually the brightness (the value you configure here).
    It is simply an inverse polynomial of the second degree, with a0 and a1 equal to zero. And we could write it like this:

    Or...

    And here you have it! This is approximately the equation used by VRAD to determine the intensity of light for each luxel during the compilation. And you can alter it by changing the values of the 3 variables constant, linear and quadratic, for any of your light / light_spot entity in your level.
    Actually you set proportions of each variable against the other two, and only a percentage for each variable is saved. For example:

    Another example:

    By default, constant and linear are set to 0 and quadratic to 1, which means a 100%quadratic lighting attenuation. Therefore, by default lights in Source Engine follows the classic Inverse-Square law.
    If you look at the page dedicated to the constant-linear-quadratic falloff system on Valve’s Wiki, it’s explained that the intensity of light is boosted by 100 for the linear part of equation and 10 000 for the quadratic part of equation. This is due to the fact that inverse formulas in equations always drop drastically at the beginning, and therefore a light with a brightness of 200 would only be efficient in a distance of 5 units and therefore completely pointless.

    You would have to boost your brightness a lot in hammer to make the light visible, that's what Valve decided to make automatically.
    The following equation is a personal guess of what could be the one used by VRAD:

    With constant, linear and quadratic being percentage values. The blue part is here to determine the brightness to apply, allowing to boost the value set in hammer if it is as least partially using linear or quadratic falloff. The orange part is the falloff part of equation, making the brightness attenuation depending of the distance the point studied is from the light origin. 
    The best way to see how this equation works is to visualize it in a 2D graph: 
    https://www.desmos.com/calculator/1oboly7cl0
    This website provides a great way to see 2D graphics associated to functions. On the left, you can find all the elements needed with at first the inputs (in a folder named “INPUTS”), which are:
    a0 is the Constant coefficient that you enter in hammer  a1 is the Linear coefficient a2 is the Quadratic coefficient B is the Brightness coefficient In another folder are the 3 coefficients constant, linear and quadratic, automatically transformed into a percentage form. And finally, the function I(D) is the Intensity function depending on the distance D. The drawing of the function is visible in the rest of the webpage. 
    Try to interact with it!
    This concludes the first part, the second part will come in about two weeks. We will see some examples of application of this Constant-Linear-Quadratic Falloff system, and a simpler alternative. We will also see how lighting works on models and dynamic lighting systems integrated in source games.Thank you for reading!
     
    Part Two : link
  5. Like
    JSadones reacted to will2k for an article, Optimizing An Open Map in Source Engine   
    An open map?
    Source engine, which is funnily a Quake engine on steroids (a bit of exaggeration but still), inherited the same limitations of its parents in terms of visibility calculations: BSP and PVS. This fact makes Source, as was Quake engine before, more suitable to rooms and hallways separated by portals where the BSP shines in all its glory.
    Inheritably, Source does not like large open maps where the PVS is of considerable size and the over-rendering is a real issue.
    If you work with Source engine, then you already know the importance of optimization in a large, detailed map. Optimization becomes even more imperative when the said map is open.
    What’s an open map? Good question. The word “open” is an umbrella term to denote any map that does not have traditional hallways and corridors that connect indoors to outdoors. The map is mostly large, outdoors with an unbroken skyline; in other words, the same stuff that source engine nightmares are made of in terms of PVS and BSP.
    In a traditional “hallway’d” map with twisted corridors leading to open areas followed by other hallways, and even if you “forgot” to place hints and areaportals, the geometry itself allows the engine to cut visleaves and limit visibility; granted the visleaves’ cuts will be subpar and messy and the PVS will be in excess, but still, the visibility and fps will be relatively under control. A twisted hallway is a remedy to long sight lines after all.
    In an open map, and without hallways and enough geometry to help the engine, the PVS risks to be huge and the whole map could be rendered at once from any point (over-rendering). We are talking here about a severe fps killer and a potential slideshow on a medium to low range computer. Source does not like over-rendering; I repeat, Source does not like over-rendering.
    I believe a screenshot should be welcome at this stage to illustrate an open map. I’ve chosen a nice medium-size map from CSGO to showcase the issue: de_stmarc.

    The shot is taken in Hammer obviously, and you can immediately see that the skybox is one big unbroken body from one edge of the map to the opposite one. This is the classic definition of open map.
    Let’s see this map in 2D view from the side.

    I have highlighted the skybox in blue so you could see the continuous sky body all over the map. Please note that an open map can have varying skybox shapes but I’ve chosen the simple and classic one to showcase my point where it is easier to see and visualize the concept of open map.
    In contrast, a “traditional” map will have several skyboxes, often not connected directly but rather through a system of indoor rooms or hallways, varying in size and shape.
    I will have my map de_forlorn as example here.

    I have also highlighted the skybox in blue and you can easily notice several skyboxes for CT spawn, T spawn, and Mid/bombsites. These skyboxes are not directly connected to each other but the areas related to them are linked on the lower levels through various indoor locations, some vast (like garage, tunnels…) and some small (like lab hallway…).
    If you are not that comfortable with source optimization or feel that certain terms are alien to you, then please read my previous optimization papers and articles before proceeding further in this article (Previous papers can be found here Source Engine Optimization roadmap).
    The necessary tools
    I’m not revealing a secret when I tell you that the same tools used to optimize any map in Source are exactly the same ones used for optimizing an open map. If you were expecting some magical additional tools, I’m sorry to bust your bubble.
    Since the tools are the same (nodraw, func_detail, props, hints, areaportals, occluders…), it is more about how to use them in open maps that makes all the difference.
    So, how to properly optimize an open map? Well, you could always pay me to do so for you (joking…not…maybe…I dunno!!)
    If the above option is off the table, then read on the rest of this article .
    Horizontal hints
    While in a traditional map one might get away without using horizontal hints, it is virtually impossible to skip them (pun intended) in an open map unless you want to witness single digit fps burning your eyes on the screen. They are of utmost importance to negate the "tall visleaves across the map" issue.
    In a traditional map, even if you bypass adding horizontal hints, the damage in fps will mostly be local since the skyboxes are not connected and areas are mostly autonomous in terms of PVS. In case of my map “Forlorn” and referring to the 2D diagram above, if I remove horizontal hints from CT spawn, then only this area will suffer from tall visleaves and over-rendering. Obviously, this is not cool in terms of optimization, but at least the effect will be somehow restricted to this area only.
    In the case of “Stmarc”, you can certainly see that not including horizontal hints will have tall visleaves seen from across the map as the skybox is one unit. The PVS will grow exponentially and the over-rendering will take its toll on the engine.
    Let’s move on to some screenshots and diagrams, shall we.

    This is our glorious open map in side view. The blue lines denote the skybox, the dark grey one is the ground, and the green rectangles represent solid regular world brushes such as building bases for example. The red starfish little-man-with-arms-wide-open is the player. The orange hollow rectangles denote the various visleaves that the engine would probably create in the map (most go from ground level to skybox level and this is what I refer to as “tall visleaf”).
    If you know your optimization, then you certainly remember that BSP relies on “visibility from a region” approach (for a refresher, please consult my papers Demystifying Source Engine Visleaves and Source Engine PVS - A Closer Look. This simply translates to the following: the player is in visleaf A and visleaf A has direct line of sight to visleaves B, C, D, E, F, and G. The PVS for A in this case would be stored as BCDEFG. Once the engine recognizes that the player is in A, and regardless of the exact position in A, it will proceed to render the whole PVS content. Everything in visleaves BCDEFG will be rendered even though the player is at the extreme end of A and has no line of sight to most of this content.
    You can immediately notice the extent of damage you will inflict on your open map if you neglect adding horizontal hints: excess PVS with additional useless content to be rendered at all times.
    Now that we established the importance of these horizontal hints in open maps, the question remains: where shall I put these hints?
    In the diagram above, the most logical places would be on top of the 3 green rectangles.

    We added 3 horizontal hints (H1, H2, H3) on top of the 3 regular brushes in our map (the hint face neatly resting on the top of the regular brush while other faces are textured with “skip”). This will create more visleaves as can be clearly seen in the above diagram, and vvis will take more time to calculate visibility due to the increased number of leaves and portals but this is done for the greater good of humanity your map’s fps.
    Now the player is in visleaf A1 and the PVS is reduced to (sit tight in your chair) A2, A3, A4, B1, B2, C3, C4, D1, E4, F3. On top of the nice result of a greatly reduced PVS (and therefore content to render), keep in mind that leaves A4, B2, C4, D1, E4, and F3 are mostly empty since they are way up touching the skybox.
    Some folks will start complaining and whining: what the hell dude, I don’t have 3 green rectangles in my map; where would I put my hints?? My answer would be: deal with it!!
    Joking aside, open maps will greatly differ in size, shape, geometry, and layout. What you need to do is choose 1 to 5 common height locations in your map where you would implement these hints. Medium maps with mostly uniform building heights can get away with 1 horizontal hint, while complex, large maps with various building heights can do with 4-5 hints.
    If your map has a hill made of displacements that separates 2 parts of the map, then it is also a candidate for horizontal hints. You just need to insert a nodraw regular world brush inside the displacement to be used as support for the horizontal hint (the same technique can be used if you have a big non-enterable hollow building made mostly of func_detail/props/displacements).
    Vertical/corner hints
    These might not come into play as much as their horizontal siblings, however they could see a growing potential use depending on the map’s layout, geometry tightness versus openness.
    I cannot go through all combinations of open maps obviously to show you how to lay vertical and corner hints; what I will do is choose one diagram representing a typical open map scenario with some scattered houses, streets, and surrounding fields. Once you see how I proceed with these hints, it will become a lot easier for you to implement them in your own map regardless of the differing geometry and layout.

    Here’s our typical map viewed from top with grey lines being map borders, green rectangles being houses (solid world brushes), and our tiny red player at the rightmost part of the map. The map has a main street that goes in the middle between houses but the player is not restricted to this path only.
    The diagram below shows how I would proceed with my hints for such setup.

    This is basically what you get when you give a 5-year-old some crayons.
    Seriously though, I just gave each hint a different color so you could discern them on the spot, otherwise it would be hard to tell where each one starts and ends.
    Most of these hints go from one side of the map to the other while going from ground level to skybox top; don’t be afraid of having big hints that cross your entire map.
    Notice that we have both straight vertical hints (shown from above in the diagram obviously) and corner hints; what I did is that I compartmentalized the map so wherever the player is, chances are they will have the least amount of leaves to render in the PVS (this is just a basic hint system and more fine tuning and additions could be done but you get the gist of it).
    To get more details on hint placement, please refer to my paper Hints about Hints - Practical guide on hint brushes placement
    Areaportals
    If your map has enterable buildings, then it is imperative to separate indoors from outdoors using areaportals; this is top priority.
    Make sure to slap an areaportal on each door, doorway, cellar door, window, roof opening, chimney, etc. that leads inside the house in question.
    What about outdoor areaportals? Good call. In an open map without much regular world brushes to maneuver, it could get very tricky to set up an outdoor areaportal system to separate areas. However, you should always strive to have one, even if it is one or two areaportals across the map. The reason is very simple: the view frustum culling effect, which, coupled with hints, will yield the best results in cutting visibility around the map.
    Continuing with our previous diagram, a simple outdoor areaportal system setup could be as follows (top view).

    This setup will make sure that the map is split into 4 areas and whenever you are in one of them as player, the view frustum culling effect will kick in to cull as much detail as possible from the other areas.
    Let me show you the setup from a side view to make it easier to visualize.

    This is the same areaportal that was closest to the player in the top down view diagram but this time viewed from the side. Unlike hints where it’s fine to have one big hint going across the map, for areaportals, it is best to have several smaller ones that tightly follow the contour of the geometry eventually forming one big areaportal system.
    Another possibility for outdoor areaportal system is to have a combination of vertical and horizontal (yes horizontal) areaportals.
    If your map is a village for example with a highly detailed central square where most of the action takes place, a potential system could be made of several vertical areaportals that sit in every entrance to the square from adjacent streets, and a horizontal areaportal that “seals” the area and works as a “roof”.
    For a practical guide on areaportals placement, please check out my article Practical guide on areaportals placement
    Props fade distance
    This is a really, really important tool when optimizing large open maps. In case you got distracted while I was making the announcement, I’ll go again: props fading is definitely vital when tackling open maps optimization.
    What you need to do is to set an aggressive fade distance for all trivial props that do not contribute to gameplay. Players will look closely at how detailed your map is when they check it out solo on the first run; however, when the action starts and the round is underway, adrenaline, focus, and tunnel vision kick in, and all the details become a blur.
    During an intense firefight, players will not notice small props and details up close, let alone at a distance. We need to use this to our advantage to fade props thus releasing engine overhead; a faded prop is not rendered anymore and engine resources will be freed and allocated elsewhere.
    Your map geometry will dictate the proper fade distances, but as a rough guideline, small props could have a fade distance anywhere from 800 to 1200 units (flower pot on a window sill, small bucket at the back door, a bottle on the sidewalk…), while medium props could do with 1400-1800 range (a shrub, a power box on the wall, an antenna on the roof, wood plank, gutter pipe, fire hydrant…).
    Be very careful though not to prematurely fade critical props used for cover or game tactics (car in the middle of the street, sandbags, stack of crates, dumpster on the sidewalk…).
    Cheap assets
    Many people forget about this technique which is more than needed when it comes to open maps that tend to have larger average PVS than traditional maps.
    I showcased in a previous article of mine the fps cost of cheap and expensive assets (Source FPS Cost of Cheap and Expensive Assets).
    Get in the habit of using the low-poly model version as well as the cheap texture version in the distant non-playable areas and the high unreachable areas where players won’t have much of close contact with the environment. Potential candidates could include a distant field, the unreachable opposite bank of a river, a garden behind hedges/walls, high rooftops, the 3D sky…).
    Fog/Far-z clip plane
    This technique, when correctly used, can provide a big boost to your frame rate as parts of the world beyond the opaque fog won’t be rendered at all.
    For this technique to work properly, your map should have a foggy/rainy/stormy/dusty/hazy/night setting (use as applicable) where a fully opaque fog won’t appear out of place. Obviously, if your map takes place in a sunny and clear day, this technique won’t work much and it will look inappropriate.
    Using this is simple: For example, if your map is set in a rainy and foggy day, you just need to set the fog end distance while having its density set to 1. You will then set the far-z clip plane to something slightly higher than the maximum fog distance (if the fog end distance is 8000 units for example, the far-z could be set to 8200).
    3D skybox
    This is another good technique to reduce engine overhead and the cost of rendering.  
    It is true that the 3D sky is used to expand the limits of your level and decorate its surrounding, however, since it is built at 1/16 scale (and expanded in-game), it is also a nice way to decrease rendering costs. Use this to your own advantage and relocate assets in the non-playable areas with limited player interaction to the 3D sky.
    One thing to keep in mind though, the 3D sky’s visleaf is rendered at all times on top of the PVS in the playable area. Do not go overboard and make an extra complex, highly expensive 3D sky or you would be defeating the purpose of this optimization technique.
    Occluders
    You thought I forgot about occluders? Not a chance as these are the big guns when it comes to large open maps with little world brushes to use for other optimization techniques.
    Let’s clear one thing first; if your map is made mostly of brushwork and displacements with little to no props, then there is absolutely no need to resort to occluders as they’d be totally useless in this case. Only when the map is loaded with models and props in an open setup with little regular world brushes that occluders come to play in force.
    To place occluders, you would search for areas where these occluders could make the most impact (low fps, high traffic, props abundance) since they run in real time and are expensive, otherwise their cost would outweigh their benefit in terms of frame rate variation.
    Remember that occluders rely on the player’s position and field of view relative to the occluder to calculate what gets culled. You need to place them in a way to maximize the number of props to be culled behind them when the player stands in front of these occluders.
    Let’s see some examples.

    We go back to our famous top down diagram; the occluder is dark blue placed on the left wall of the large house while the little black stars represent various props and models. The 2 diagonal black lines denote the player’s FOV relative to the occluder. Anything behind the occluder and within the view frustum will be culled.
    That’s nice; we are able to cull 4 props but is it enough? It is not optimal as we can still do better. What if we move the occluder to the right wall of the house?

    Much better if you ask me. 5 additional props were added to the culling process meaning less overhead and fewer resources to render for the engine. That is why I said earlier it is all about maximizing the impact of the occluder by placing it in a way relative to the player’s position that maximizes the number of culled models.
    Here’s another example (still top down view).

    The player has moved to the middle of the central street, and beyond that L-shaped house is an open field with a lot of props scattered around. One way to implement occluders is as showcased in the above diagram. Notice how I arranged 2 perpendicular occluders along the walls for the maximum occlusion effect as all of these props in the field are not rendered from that player location.
    Another way to arrange occluders in this case would be diagonally across the L-shaped house (split into 2 or 3 occluders if needed to accommodate the nearby geometry; they can be floating without the need to seal an area).
    If you’re feeling brave enough (you should be after reaching this far in this article), you could also add an extra occluder along the wall of the house to the left of the L-shaped house to further enhance the view frustum occlusion effect and cover more props in the field.
    The most common places to add occluders in open maps include a displacement hill that separates parts of the map, a hedge that stands between a street and a field full of props, a floating wall between a house garden and the street, the walls of a large house, the walls of a tall building, a ceiling when it separates multiple levels…
    To read more about occluders placement and cost, please consult my article Practical guide on occluders placement
    In conclusion
    The foundation of optimization in Source engine will be the same whether it is a traditional map or an open one. You will heavily rely on func_detail, nodraw, displacement, props… to achieve your goals but it is the way you use these tools in an open map that makes all the difference.
    One might get away with being a bit sloppy with optimization in a traditional map, however, make no mistake that an open map won’t be any forgiving if you decide to skip a beat in your optimization system.
    Talking about different open maps and formulating varying optimization systems for them could fill articles; I hope this article has shed enough light on the open maps optimization approach to let you easily design a system for your own map.
  6. Like
    JSadones reacted to will2k for an article, Source FPS Cost of Cheap and Expensive Assets   
    A new question?
    After successfully solving the eternal mystery of func_detail vs. displacement in my last article (here), I was contacted by the High Council of Source Engine Optimization. Apparently, there seems to be another enigma to be uncovered and a major question to be answered.
    What is the fps cost of cheap and expensive assets in Source engine? Is there a significant difference between the two in terms of frame rate? (that’s 2 questions but I’ll let this one slide)
    The study
    As with the last article, this one is also going to be a short but sweet article; fewer words, more numbers and screenshots. The systematic approach is also going to be very similar: 2 similar test maps where one contains expensive assets while the other has cheap versions of these assets. The assets will be the same and will be located in the same locations in both test maps.
    The recent assets added with the new de_nuke update in CSGO will be the perfect candidates for our study as Valve made most of these in cheap and expensive versions. For props, the expensive version is high-poly models while the cheap one is low-poly. For textures, the expensive version gets a normal map (up to 2), specular map, advanced reflections, detail map, and Phong shading in some cases; the cheap version is basically the diffuse map with the occasional detail map.
    I will record the localized fps in both versions and compare, then draw conclusions that will hopefully answer the High Council’s question(s).
    The testbeds
    The first map to test is the one made of cheap assets. It’s basically a simple map consisting of 4 walls and a floor on which are spread several props and textured blocks at predetermined locations. Textures are mostly concrete while props contain crates, cars, pipes, wires, doors, and vents.

    The fps recorded is 330 fps. The expensive version is exactly the same but with props replaced with their high poly versions and textures swapped with their expensive versions.

    The fps is now 286 fps; interesting. All right, let me call the High Council to relay the news.
    Hold your horses right there. We are men of Science and you know that…yes, yes, I know, one map is not enough to draw conclusions.
    I’m going to take this map and quadruple it, in area and in content, and test again (Nobel prize here I come). The new map will have 4 times the amount of props and textured brushes (the same ones of the initial map cloned into the new areas) as well as having its total area increased fourfold. We start with the cheap version that we will refer to as test map (4x).

    The fps decreased to 279 (from the 330 in the simple cheap map) due to the extra content that the engine has to render. Our main point of concern would still be to compare this version against the expensive one.
    You know the drill by now; we will also create the (4x) expensive version.

    The fps is 229. The decrease in (4x) version is more or less in line with the one in the simple version. Let’s recap in a table for easier viewing.

    As you can see, the fps dropped 44 fps in the simple version and 50 fps in the 4x version, between the cheap and expensive maps respectively.
    We can draw 2 conclusions from the above table:
    There is a significant drop between the cheap and expensive version (44/50fps), and there is also a substantial drop within the same version (51/57fps) when you add much more content that is all visible in the PVS.
    These results can shed some light on the latest update of de_nuke where the overall fps is lower than the rest of the stock maps in CSGO. The high amount of props/details that can be seen/rendered from one location coupled with the expensive assets in the playable area contribute to further decrease in the overall fps in that map (in addition to the open skybox/layout). I have tackled a revised optimization system for de_nuke in a topic of mine last month that can be read here (https://www.mapcore.org/topic/19909-de_nuke-a-revised-optimization-system/)
    As a bonus, I’ll throw in the compile times of the above maps so you can witness the effect of cheap vs. expensive, and the additional content in (4x) versions, on the compile time, especially on vrad since it will mostly be affected by the extra faces in the high poly models and the additional vmt switches in the expensive materials.

    You can clearly see that vrad times increased considerably between the cheap and the expensive versions, as well as within the same version when we quadrupled the area/content.
    Now if you’ll excuse me, I still have a phone call to make; the grand council woman cannot wait any longer.
    The final cost
    Expensive assets bring visual eye candy to the map in hand which is a necessity in today’s ever-growing and continuously pushed graphics boundaries. Relying on low poly models and cheap textures won’t fare well on the visual fidelity front. However, expensive assets come at a cost of taxing the rendering engine and decreasing the overall fps in the map.
    These expensive assets are a requisite if you want your map to shine (pun intended) but one has to be careful not to overuse them. Use them wisely in the playable area and resort to cheap versions when decorating the non-playable areas of the map or any place that the player cannot see up close to discern the difference.
     
×
×
  • Create New...