Posts by will2k

Looks awesome for an early WIP

The modular props of the new Nuke are a joy to work with; granted, the work of assembling them is tedious and time-consuming but the results will leave a grin on your face. You can virtually come up with any shape you desire especially with pipes, electrical wiring, rails, curbs and vents

Spent most of last week switching most of the props and textures on Forlorn into the new ones from Nuke (still WIP).

[Blocked Image: http://www.mediafire.com/convkey/adb0/bx8585znvvfmwgrzg.jpg]

[Blocked Image: http://www.mediafire.com/convkey/c0f6/y1h7giegg58fg1ozg.jpg]

Dramatic sunset after a rainy day

[Blocked Image: http://www.mediafire.com/convkey/dcb7/38w93sbq6ao00m3zg.jpg]

Took it today at sunset, several hours ago.

Quote from Sjonsson

I love this oldschool look! Totes agree with nikko, all nostalgia over that shit!

Thanks

There is no magical formula here; it's all about practice - you know, practice makes perfect

Reading papers and tutorials is important to get started on the right foot but equally important is to practice with test maps to try out different concepts. It also helps tremendously to review work done by other designers/games to see how they get things done.

I'm gonna throw in a couple of papers and articles that I wrote some 2-3 years ago concerning the topics you wanted help with:

Overcoming Creative Block in Level Design

The Power of Reference Photos

Planning To Win Sketching Your Level

Hope this helps to get you started, and good luck.

Quote from nikkoship

This map gives me such a warm nostalgic feeling, I love it. You nailed that Opposing Force feel.

Thanks nikko glad to hear that people are recognizing and loving the HL/OpFor nostalgic vibes on the fly.

I'm trying my best to be faithful to that theme without sacrificing CSGO core gameplay; it's a bit of a trade-off.

Quote from baem123

good job will2k

Thank you

Bombsite B...coming along nicely

[Blocked Image: http://www.mediafire.com/convkey/5c50/tqdw4sutgwx3i7qzg.jpg]

Quote from El_Exodus

That was a way longer answer than i expected! Thank for explaining! I always thought vvis on fast is so bad, that it's almost like not even calculating the visibility at all. I definitely need to learn more about Source optimization. Gonna read your papers next week!

A good question requires a good and long explanation answer

Quote from Dosentti

I'm not sure how it's possible that I have missed your papers! I have been searching for something to read about source level designing. These are great! thanks!

Thanks

The 10 papers that are in my signature are related to Source optimization; on my website, you'll find more than 20 papers/articles related to different aspects of level design/gaming in general that I have been writing since March 2012.

Quote from El_Exodus

did valve read the comments of our hostage rescue article?

Maybe... :v

Quote from El_Exodus

Nice test! Though i don't really know why you did run vvis on fast for testing the quality of optimization. This doesn't really make sense imho. I feel like you should compile with other compile settings for more accurate results despite of the long compile times.

Hey buddy

What you suggest will be unneeded, useless, and a total waste of time; too much confusion in the comments posted in this thread, and these are common misconceptions that will probably need me to write an article by itself.

I’m going to let you in on a little secret (and the viewers too); let’s call it “optimization 601 – masters degree level class”

If your map is tightly and well optimized (and I mean REALLY, REALLY well), then there is not much of a difference between full vis and fast vis. The gap in fps will be non-existing at all, you will get the same fps. If by any chance the fps will differ, then this difference will be extremely marginal.

That’s not to say that everyone should use fast vis; If you are a beginner or intermediate level in Source optimization, then never use fast vis because chances are your map in not fully optimized and the fps will take a dip with fast vis (the PVS and the content rendered will be exaggerated).

However, if you are an expert in optimization and very intimate with visleaves and PVS, then fast vis is as good as full vis when it comes to testing your optimization system. Please check my 2 detailed and in-depth articles on (visleaves) Demystifying Source Engine Visleaves and (PVS) Source Engine PVS - A Closer Look

The PVS in the fast vis version will be slightly looser than the one in the full vis edition and I emphasize on slightly; we are talking here about some 4-5 additional visleaves at best, and when you took extra care to optimize your map and kept your visleaves in check, then these extra visleaves in the PVS won’t affect your fps in any considerable way. Most of the times, the fps will be the exact same between fast and full or slightly lower in some rare cases (single digit difference at best).

I personally do not need vvis while building my optimization systems. Vbsp creating the visleaves properly is more than enough; I can calculate the visibility myself and predict the PVS on the fly by using mat_leafvis, mat_wireframe and r_lockpvs, in addition to the portal file in Hammer. A full vis or fast vis will be the same for me once my optimization system is airtight.

Now if this new found knowledge shook the optimization grounds beneath your feet :), then allow me to ease your mind with some solid screenshots and figures to showcase and verify what I just explained.

I will use my CSGO map cs_calm to demonstrate this effect, and we will need 3 versions of it: the workshop version (March 2015) that is basically a final compile (full vis, full rad), a test version compiled with fast vis and fast rad, and a second test version compiled with fast vis but with full, final rad. These versions are exactly identical, the only difference being the compile parameters.

[Blocked Image: http://www.mediafire.com/convkey/4eab/sd67a73cemxsd49zg.jpg]

In this first screenshot, on the left is the full compile version while on the right is the fast compile. The fps are the same in both versions.

Let’s check the wireframe shot to get an idea on the PVS and what’s being rendered.

[Blocked Image: http://www.mediafire.com/convkey/e028/etlmjcb5915vpi5zg.jpg]

You can see that the content rendered is the same. The only small difference in the PVS is the area behind the ladder (center of screenshot) where an additional 5 small visleaves are rendered in the fast version. Since my map is fully optimized and these additional visleaves have proper “hallway-end” areaportals, corner hints, no draw, as well as an aggressive props fade distance, the content to be rendered inside them is greatly reduced to just a couple of textured walls that have no impact on the fps.

Here is another screenshot between the full version and the second test map with fast vis but this time with full, final rad.

[Blocked Image: http://www.mediafire.com/convkey/f31a/ilrlpilrrpt59mtzg.jpg]

Again, the fps is the same (no surprise here if you understood the concept). The wireframe shot follows.

[Blocked Image: http://www.mediafire.com/convkey/50e3/5z0ao7fwj401191zg.jpg]

Again the PVS and content rendered is basically the same with the additional 5 visleaves for the fast vis; the fps is still the same.

As I said before, when your map is tightly optimized (as in “will2k’s seal of approval” optimization :D), then it doesn’t matter between full or fast vis, you will get pretty much the same fps results and can compare freely. If your map is not 100% optimized, then DO NOT use fast vis at all.

My study on Nuke is 100% valid even if I did it with fast vis; now you can see why.

Hope the above cleared things up for you and for people viewing this thread

I might be tempted to write an new article about the above.

Cheers

Note: For all the folks that are confused and have so many misconceptions about vvis, optimization, etc, please read my technical papers and articles about Source optimization in chronological order as they appear in my signature below.

(For the guys confused about hints and fast vis in the posts above, vvis has nothing to do with implementing your optimization setup, that's vbsp's job - vvis simply calculates the visibility between your leaves and creates the PVS. vbsp is the one responsible for translating your hints, areaportals, nodraw, func_detail etc into visleaves cuts during the compile). Again, read my papers and all this is explained in great details :).

The new Nuke

On February 18, 2016, Valve released the new revamped de_nuke. Alongside the map came several visual improvements to CSGO as well as a bunch of high resolution textures and models.

The map is heavily detailed both with brushes and props and Valve managed to pull a pretty decent optimization job on it. Despite the hi-res content that includes materials with 2 normal maps, specular maps, detail maps and phong, Valve made cheap versions of the textures as well as low poly models of the props to be used for distant places in the unplayable parts of the maps. This fact coupled with Valve using hint brushes, areaportals, func_detail and nodraw made the map run decently on a modern gaming rig. However, the open skybox and the huge amount of details around the map were working against it on the fps side.

Many people were complaining across forums that their fps took a big hit when playing the new Nuke. Driven by scientific curiosity, I wanted to check whether the complaints were valid: did Valve pull a sloppy job when optimizing Nuke or is it down to the players’ computers being low to mid-range and not coping with the new map/CSGO changes?

The revised optimization system

Since I know “nothing” about optimization , I decided to take a look at the map.

I deleted all the hint brushes placed by Valve and rebuilt my own hint system from scratch consisting of vertical, horizontal, and corner hints (Valve did not include corner hints). Valve did not add any outdoor areaportal and their system consisted mostly of indoor ones that separated the inside of the plant from the outside. I added a skybox brush atop the big central dome to allow for outdoor areaportal systems to be viable across the map. A new outdoor areaportal system was added. Finally, I added occluders in several places in the outside yard (Valve did not include any occluder). It was a basic optimization job (not fully tweaked) that took around 6 hours (3 hours on Sunday afternoon and 3 on Monday evening) just to test the grounds.

Due to the sheer size and complexity of the map and the recent changes in the CSGO Hammer compiling tools (vrad), compiling on full final settings was out of the question. I compiled on fast vis and fast rad with “dirty” lighting; the map won’t be as refined as a full-compile one, but it should be enough to give me an idea on the efficiency of the new optimization system versus the stock one of Valve.

Vbsp = 32 sec, vvis (fast) = 2 sec, vrad (fast, dirty light) = 3 hours and 13 min .

Vrad on final would have probably taken half a day and vvis on full would have pushed for a full day (I tried full vis for the sake of it and quit after 4 hours where vis was still immobile at portalflow 4).

Here are the results of the “impromptu” study: on the left is the screenshot showcasing the stock Valve de_Nuke (shipped with the game and certainly compiled on full) while on the right is my own version, de_nuke_will2k, compiled on fast vis and fast rad. Please excuse the black shadow patches in my version as a result of dirty fast lighting from vrad (click for full resolution screenshots).

Below is a recap of the above figures; I also added the test system specs with CSGO graphic settings.

The localized fps increase ranged between 5 and 20 fps depending on the problematic map location. To get a rounded average of the fps of almost all the locations in the map, I used the time demo technique (refer to my paper Optimization Testing in Source Engine). For stock Nuke, the average fps was 162 while for my version, the number was 168.

Conclusion

Valve did a good job optimizing Nuke albeit not a perfect one. Optimization can still be improved as I demonstrated above and fps can still be increased…but not in big increments as someone would wish for.

Remember that my version is done in fast vis (basic and rough visibility calculation) and is only more or less a basic optimization job; if I spend more time tweaking the system and adding some more areaportals, hints, and occluders in more strategical places, changing the props fade distance to more aggressive values, and then compile on full, then I would predict another 5-15 average fps increase on top of the 6 above (only a prediction that needs testing to confirm).

Nuke is the beginning and I suspect all future Valve maps (new or refurbished) will be following the same trend set by the new Nuke: hi-res content, ridiculous amount of details to render at once, open skybox with big sight lines, …

If you have a low to mid-range PC and you are struggling with Nuke’s fps, my revised optimization system will help a bit but unfortunately, it will not magically increase the fps by 100. I believe it’s about time to consider switching to a better PC; things are going to get worse from now on with newer content (assuming CSGO will remain on the current Source engine).

Cheers /emoticons/[email protected] 2x" width="15" height="15" />

Will2k

Edit 1 (February 29): I'm appending one of my detailed replies from below to clear up some misconceptions and confusion many people were having after reading the study. This basically deals with full vis vs fast vis.

Full vis Vs fast vis

Quote

Quote Nice test! Though i don't really know why you did run vvis on fast for testing the quality of optimization. This doesn't really make sense imho. I feel like you should compile with other compile settings for more accurate results despite of the long compile times.

Hey buddy

What you suggest will be unneeded, useless, and a total waste of time; too much confusion in the comments posted in this thread, and these are common misconceptions that will probably need me to write an article by itself.

I’m going to let you in on a little secret (and the viewers too); let’s call it “optimization 601 – masters degree level class” /emoticons/[email protected] 2x" width="15" height="15" />

If your map is tightly and well optimized (and I mean REALLY, REALLY well), then there is not much of a difference between full vis and fast vis. The gap in fps will be non-existing at all, you will get the same fps. If by any chance the fps will differ, then this difference will be extremely marginal.

That’s not to say that everyone should use fast vis; If you are a beginner or intermediate level in Source optimization, then never use fast vis because chances are your map in not fully optimized and the fps will take a dip with fast vis (the PVS and the content rendered will be exaggerated).

However, if you are an expert in optimization and very intimate with visleaves and PVS, then fast vis is as good as full vis when it comes to testing your optimization system. Please check my 2 detailed and in-depth articles on (visleaves) Demystifying Source Engine Visleaves and (PVS) Source Engine PVS - A Closer Look

The PVS in the fast vis version will be slightly looser than the one in the full vis edition and I emphasize on slightly; we are talking here about some 4-5 additional visleaves at best, and when you took extra care to optimize your map and kept your visleaves in check, then these extra visleaves in the PVS won’t affect your fps in any considerable way. Most of the times, the fps will be the exact same between fast and full or slightly lower in some rare cases (single digit difference at best).

I personally do not need vvis while building my optimization systems. Vbsp creating the visleaves properly is more than enough; I can calculate the visibility myself and predict the PVS on the fly by using mat_leafvis, mat_wireframe and r_lockpvs, in addition to the portal file in Hammer. A full vis or fast vis will be the same for me once my optimization system is airtight.

Now if this new found knowledge shook the optimization grounds beneath your feet /emoticons/[email protected] 2x" width="15" height="15" />, then allow me to ease your mind with some solid screenshots and figures to showcase and verify what I just explained.

I will use my CSGO map cs_calm to demonstrate this effect, and we will need 3 versions of it: the workshop version (March 2015) that is basically a final compile (full vis, full rad), a test version compiled with fast vis and fast rad, and a second test version compiled with fast vis but with full, final rad. These versions are exactly identical, the only difference being the compile parameters.

In this first screenshot, on the left is the full compile version while on the right is the fast compile. The fps are the same in both versions.

Let’s check the wireframe shot to get an idea on the PVS and what’s being rendered.

You can see that the content rendered is the same. The only small difference in the PVS is the area behind the ladder (center of screenshot) where an additional 5 small visleaves are rendered in the fast version. Since my map is fully optimized and these additional visleaves have proper “hallway-end” areaportals, corner hints, no draw, as well as an aggressive props fade distance, the content to be rendered inside them is greatly reduced to just a couple of textured walls that have no impact on the fps.

Here is another screenshot between the full version and the second test map with fast vis but this time with full, final rad.

Again, the fps is the same (no surprise here if you understood the concept). The wireframe shot follows.

Again the PVS and content rendered is basically the same with the additional 5 visleaves for the fast vis; the fps is still the same.

As I said before, when your map is tightly optimized (as in “will2k’s seal of approval” optimization /emoticons/[email protected] 2x" width="15" height="15" />), then it doesn’t matter between full or fast vis, you will get pretty much the same fps results and can compare freely. If your map is not 100% optimized, then DO NOT use fast vis at all.

My study on Nuke is 100% valid even if I did it with fast vis; now you can see why.

Hope the above cleared things up for you and for people viewing this thread /emoticons/[email protected] 2x" width="15" height="15" />

I might be tempted to write an new article about the above.

Cheers

Note: For all the folks that are confused and have so many misconceptions about vvis, optimization, etc, please read my technical papers and articles about Source optimization in chronological order as they appear in my signature below.

(For the guys confused about hints and fast vis in the posts, vvis has nothing to do with implementing your optimization setup, that's vbsp's job - vvis simply calculates the visibility between your leaves and creates the PVS. vbsp is the one responsible for translating your hints, areaportals, nodraw, func_detail etc into visleaves cuts during the compile). Again, read my papers and all this is explained in great details /emoticons/[email protected] 2x" width="15" height="15" />

EDIT 2 (April 22): Adding a link to 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).

Quote from sevin

Thanks for the information! How recent was the Train overhaul?

December 2014

http://blog.counter-strike.net/index.php/2014/12/11053/

Glad to be of help

Quote from sevin

The HL inspiration is readily apparent. You are a master texture artist! All the little references you're dropping in are a great touch.

I'm wondering about something a bit unrelated. When you started using the new Nuke assets, did you decompile the map or find them using console commands in-game or is there a separate folder in materials/models for the new assets? I ask because I'm having trouble decompiling the map. BSPSrc does it with no errors, but in Hammer all the models show up as errors. As far as I can tell the assets are in the .vpk so I'm at a loss. This has happened with a number of other official maps, though not all. Do you have experience with this?

Sorry for the tangential question, looking forward to beta1!

Thank you

I haven't added any new Nuke assets to the map yet, will start doing the switch today. What you see in the screenshots is mostly concrete textures from de_train (new one) and de_vertigo, in addition to many custom textures that I created myself.

As for accessing the new assets in Nuke, you have 3 ways to do so:

- The classic, old-school way: you just open the texture browser or the model viewer in Hammer, and search for "hr" (high resolution) and you will basically filter the new content from Train and Nuke (easily identifiable)

- Another way is to use the new map delivered by Valve, nuke_zoo, where they compiled all the modular assets from Nuke into one location for easier access.

- The third way is to decompile Nuke and check the custom assets there. As for you getting errors in the decompiled version, it is because Valve further combined the modular assets into new ready-to-use assets, and placed them into a new folder. Check my reply further below to Squad to see how you can easily counter this issue.

Quote from Squad

Valve just released more info about the vrad update. I'm sure you'll be interesed in it

It seems for some people it works just fine to just decompile the map and load it into Hammer, while for others it's littered with missing models (like for me). I explained it here how you can fix this (unless your problem is something else, but then just let us know).

Thanks buddy

I read the blog moments ago and it confirmed my suspicions about vrad from my previous comment; not only they changed the way static lighting for props is calculated (more rays firing) but they also changed the process for displacements lighting which is why vrad is exponentially increasing its compile time on final (even on fast, the increase is considerable).

Fun fact: I tried compiling the new nuke on fast vrad and it took...3 hours and 13 minutes to finish, just vrad time :shock:; the amount of props is insane.

For the errors you are getting on decompiled nuke, I am assuming you are using the latest version of bspsrc to do so.

As I told sevin earlier in this comment, Valve, for their ease of use and access, merged several modular assets into new ones and placed them in a new folder called "autocombine". Basically they are still the same props but Hammer will treat them as new props/new mdl's in a new directory.

What you can do is go to the last tab in bspsrc labeled "other" and tick the "extract embedded files"; this way bspsrc will decompile the map and extract the "new" custom assets along. These will be placed next to the decompiled map preserving any file/folder hierarchy; you just need to move the textures and models folders (the autocombine) into the csgo/materials and csgo/models directories respectively and the decompiled map will show no errors models.

Thanks again for dropping by and will talk to you soon about forlorn beta1

Quote from Vaya

it's a feature. you now have time to make a steak dinner now while your map loads

but seriously though, this is gonna suck when you are in the lighting tweaking phase. Source 2 Hammer (or whatever it will be called) needs to be streamlined and targeted at 2016 not 1996.

Quote from jackophant

I spy a G-Man access point on that well lit, inaccessible balcony up top

Also, maybe one of the teams could be dropped off by one of the typical VTOLs (V-22 Osprey) or just have them flying by like the guardian mission.

Sorry, every time I see your map I just start fanboying Hurry up and release something!

Touché my dear friend, spot on :P; that would be the Gman "intermittent" observation room

The helipad is there and I'm still toying around with several ideas/scenarios

I'm also itching to release something :D; will have something for you soon.

Thanks for the continuous support and uplifting cheers

Screenshot from the latest beta build of last week

[Blocked Image: http://www.mediafire.com/convkey/c245/920325b1e1z0x7xzg.jpg]

I'll start switching most textures and props to the new custom assets of Nuke; they fit perfectly well with the map's theme and geometry :).

On a interesting note, Valve has radically changed the props lighting process in vrad.

The latest compile log of the map before the update last week had vrad clocking at 7 minutes 25 seconds on full final compile. I tried re-compiling the map yesterday with the new vrad using the exact same final configuration and vrad took...wait for it,...22 min 11 sec. This is 3 times the original timing, something to keep in mind when compiling your map.

The "archaic" antics and shenanigans of Hammer are becoming more painful to work with.

My cousin sent me the link today and it was only released 2 days ago; it's only a 3 min short movie but I guess it falls under "what have you watched recently"

Half-Life and Portal fans...enjoy

Shawn, you are spoiling your software users way too much :v

Seriously though, those constant updates and additions are commendable; keep up the excellent work.

Quote from jackophant

Oooooh, do we get a list?

I was thinking you could have a bombtrigger as well: after the bomb explosion you could have the typical klaxon sound they use:

https://www.youtube.com/watch?v=wAqnrpDwaCM

When can we play this?

It's better if these Easter eggs are discovered first hand in-game so I'm not gonna spoil it with an exhaustive list but in general, so far we have interactive retinal scanners, various buttons and keypads with HL sounds, various signs subtly hinting at HL, office signs referencing HL characters (check last screenshot :v), reference to Lamarr (Kleiner's headcrab) in the vents,...(more planned)

I decided the G-man will eventually make a cameo albeit not in the playable area as to not scare the shit out of unsuspecting players as we discussed last time

The iconic HL alarm siren is another brilliant Easter egg suggestion of yours and will probably be incorporated as it fits the theme and the backstory of the map (as described in the first page of this WIP thread)

As for your question "when we can play this?"; the sound or the map? :v kidding.

Well, I don't have a fixed date yet but at some point in the near future, I will have to test the beta1 I'm currently working on, so stay tuned

On a related note, I was checking the new Nuke and the new custom assets fits perfectly with my map's theme; I was running around the map with dilated pupils like a kid in a candy store

map is progressing steadily; I have also implemented many Half-Life Easter eggs across the map with more to come (looking at you @jackophant :D)

here's a fresh screenshot

[Blocked Image: http://www.mediafire.com/convkey/06db/73s1mca5fpkebxlzg.jpg]

Trumbo

Bryan Cranston is just brilliant