will2k

2 hours ago, Sjonsson said:

Today I have read this article,  Man Vs. Engine and all other writings by you referred in this article and I have to tell you it's nothing but fantastic piece(s) of work, both cohesive and inclusive. Whenever I see guys like you giving away so much to a community, no matter if it resides at GameBanana, Mapcore or somewhere else, I get this happy feeling and inspiration to do the same some day.

I'd like you to know that next week I will start up an 8 weeks long HL2 campaign project with my level design class consisting of 14 students and a lot of your work will be mandatory reads. 

Thank you so much for this, helps out immensely!  

Oh, thank you your comment made my day

This is extra motivation to keep writing new articles and papers

10 hours ago, Pink Flamingo said:

Very nice article. These informations are so valuable for a newbie map creator. Thank you.

Thanks glad you found this article and previous ones helpful for your journey in optimization.

3 hours ago, GenoCide said:

Thank you Will.

Hey thanks buddy

7 hours ago, Squad said:

Another fine article Great job, will2k!

Thanks Squad, always appreciate your cheers and support

7 hours ago, Vaya said:

Great timing will. Thank you for doing this

Thanks Vaya; your optimization questions about open maps were an additional motivation to concentrate on writing and finishing this article

7 hours ago, Quotingmc said:

As a complete noob at optimisation, this article is great for me!

Thanks, glad to hear

1 hour ago, Shibou said:

Again very usefull as all your other articles, yet even more straight foward and I think easier to understand for everyone who's new to optimizing a map at source.

Well done, great job!

Thank you

4 minutes ago, FMPONE said:

Amazing stuff Will, no one can question your credentials as the Source mapping optimization GOD

Thanks Shawn I see you updated my grade to optimization God feels good

Seriously though, I just believe in sharing my humble knowledge for the greater good of the community. I do know a thing or two about Source but there are many things that I don't; and I still learn new things from virtually everyone around me in the community

If anyone has questions related to this article, please feel free to post them here and I'll try my best to reply and clarify.

Cheers

4 hours ago, leplubodeslapin said:

It did, but it doesn't work on CSGO anymore (maybe because of gameplay balance issues, dunno)

Thanks for the info

I don't think a prop transition from high to low poly in-game would make such a big difference on gameplay (overall shape, color, size, collisions...are basically the same). Maybe it was something to do with the new modified engine in CSGO? or they got lazy and didn't implement it back in the new Source .

As Pampers mentioned, having LOD would help a lot with frame rate especially on the new de_nuke. One could set a prop to fall back to low poly at 512-1024 units from player depending on size then implement props fade distance at 1600 units (just an example) for the ultimate fps saver.

Thanks everyone for the comments and the active discussion

@Pampers: Source should be already relegated to the "classics" category instead of still being in the "active engines" category; it's long overdue in 2016

I'm no modeler or 3D artist, but out of curiosity, doesn't source use LOD? or did you mean it's an inefficient system in Source?

@ laminutederire: I'll list some of the props used in the test maps along with their triangle count to give you an idea (both high and low poly versions)

• nuke_sedan02        4608
• nuke_sedan02_low    1990

• nuke_roof_ac02        1712
• nuke_roof_ac02_low    621

• metal_crate_001_128x112x256        5555
• metal_crate_001_128x112x256_low        2623

• metal_door_002        1032
• metal_door_002_low    582

• metal_pipe_001d_corner_large        832
• metal_pipe_001d_corner_large_low    224

@ leplubodeslapin : Salut Sylvain. There will always be room for in-depth follow-up articles

The main purpose of this short article was to showcase that there is a significant effect on fps when "over-using" expensive assets especially after the new de_nuke update.

14 hours ago, Shibou said:

Again a very use- and helpful article. Thank you.

Thank you . Glad you liked these articles and found them helpful.

13 hours ago, seir said:

Nice article! It would be great if you could profile and investigate how frame renders with a certain assets so you could actually tell that this model is X poly, has a pretty heavy material that has screen space reflection and performance depends on the object size on screen, material drawcalls, if it's grabbing heavy textures etc. Microsoft have PIX tool, I bet there's one for PC too. There was a Crytek profiling tool but I can't find it  That data would be suuuper useful.

Thanks seir

The points you mentioned are a bit advanced and could be the topic of a future article that goes further deep in the study; bear in mind I'm no programmer but it will be interesting and useful as you mentioned. Will keep this in mind for future articles that I plan to write

As for PIX, AFAIK it is now deprecated and it is currently part of the windows SDK, more precisely the Microsoft Visual Studio called Visual Studio Graphics Debugger. I will see if there are other alternatives for the PC as you mentioned the Crytek one, so there's bound to be others 

Thanks again for the insights.

3 hours ago, Vaya said:

Great work as always

Thanks for the uplifting comment and the continuous support

Thank you

Well, there is a chance that someone at Valve read this article and the corresponding active discussion going on and decided to throw something in the way of hostage rescue designers ; after all, everyone on reddit claims that Valve "reads their comments".

I pretty much like the first output "onfirstpickedup" and I can see numerous possibilities (like toggling random rescue zones that were hidden in the start of the match, etc...).

I just opened steam and noticed a huge 1.6GB update that is downloading now so I haven't got the chance to toy around these outputs but it is certainly something to look forward to

Thanks

This question is better directed to Valve but I believe that Source "piggybacks" the brush face directly like @esspho mentioned without storing an external displacement map. If someone has an in-depth knowledge of the inner workings of Source displacements, please chime in (I think a Valve programmer is here on mapcore but he doesn't visit anymore)

Thank you glad you liked it.

Hi ics

For displacements, it is always a better idea to have some sort of "modular design" where different pieces make up the big structure. It is easier for displacements manipulation and texture application. The roofs you mentioned are made of 12 different brushes and the house body itself is made of many individual brushes turned-displacement, to make each wall side, door frame, window, etc.

However, from an optimization and frame rate point of view, it doesn't matter. If you make a displacement cube out of one cube brush (turning the 6 faces into displacement) or you make it out of 6 individual displacement faces sewn together, you will get the same fps.

I already tested this with 2 similar maps (1 modular and the other is block-based as in the house made of 1 brush and the roof as well); the frame rate is the same as Source renders the displacements faces in batches. One just has to make sure not to turn unneeded faces into displacements in both cases.

As usual, a big shout out to @'RZL, @Sprony, and @FMPONE for their logistical help and feedback/input. Cheers

Thanks Tyker

Every displacement in the screenshots is a power 3 (power 4 is better avoided in Source). Power 2 was also tested and the fps remained the same (in the range of 288-292).

Jack thanks for dropping by.

Both func_detail and displacement versions had the same vvis time, visleaves and portals figures; they also had roughly on-par times for vbsp. There is no preference for vis since they are both ignored for visibility calculations.

you're welcome.

@Vaya: hey buddy, welcome back.

I still believe layout tweaks will solve most of the hostage rescue issue. However, in the event that some scripting needs to be done, then it will probably be a new game mode (probably non-official third-party mode, not from Valve themselves). In this case, the new game mode will have its own set of rules for rescuing the hostages that will include where to go/stay after reaching the hostages. It's way too early now to envision this , but this is how I see it working in a distant future, if needed.

Despite being outdated and limiting, Source still got some tricks up its sleeve.

You can create totally new gamemodes for CSGO using Vscripts; that's why I said in an earlier comment that we should start by using simple layout tweaks for hostage rescue scenario. If nothing works out, we can then turn to maybe scripting a new alternative gamemode

Here you go

An Introduction to VScripts - Part 1

An Introduction to VScripts - Part 2

I'm back

Thanks everyone for keeping the ideas and suggestions flowing; the stream of good ideas was awesome and kinda exceeded my initial expectations

@El_Exodus's idea of having the rescue zone in a relatively new area of the map not initially accessible sounds good and doable. The "inconvenience" I see is the map overall size/area could grow considerably thus putting off some players. One should also note that if the new area is relatively big, then players will have to basically learn 2 layouts: the initial map where they push for hostage zones then another layout where they run for rescue zone. Just a thing to keep in mind when doing this alternative solution but it certainly deserves some test maps to see how it flows

Having CTs wait for 30-40s at hostage zones for extraction seems a good way to mimic Ts defending a planted bomb, but it will require a rewriting of the game mode from Valve (or maybe some heavy third-party Vscripts ending up in a new game mode?); I believe for the moment we should stick to simple layout tweaks to improve hostage rescue. If after plenty of test maps, we realize that nothing worked, then we could turn our way to Valve 

cheers everyone and let's see some "experimental" cs_ maps flowing.

Greetings everyone

I'm not home nowadays and don't have much access to the internet so my replies are...slow. Hopefully, I'll be back in full force by next week .

The ongoing discussion and the replies here are really insightful; when I was writing the article, and in addition to providing early solutions, my aim was also to further pick the community's brain and seeing all this discussion makes me really thrilled. A lot of great and useful ideas that push the boundaries.

What is needed now is to translate these ideas into basic blockouts/greyboxes that can be tested and iterated to perfect and fine tune. Remember that mapcore testing server is always here and the community is more than awesome when it comes to constructive feedback and help.

@laminutederire asked about timings and I can showcase the ones I used in cs_calm:

CTs need 18-20sec to reach hostage zones and 20-22sec to go back to the rescue zones (because of the reduced speed of the carrying CT). There are 3 main encounter points in wine cellar, mid and side yard. CTs need 10-12s to reach them while Ts need 8-10s for a slight defense advantage. There are also side connectors to alleviate the pressure on the encounter points and allow CTs better escape paths.

About the rescue phase, and after reading the comments in this article, I think I can throw an additional idea here. Instead of having the rescue zone near CT spawn, we could have it in mid to reduce the distance from hostage zone to hostage rescue. In calm's case, the CT will need 10-12s to reach mid instead of 20-22s for the current actual hostage rescue zone.

@Gulliver Thoday: The "epitome of realism" was sarcasm to further validate my point that CS was not about realism.

Thanks everyone for your input and ideas; keep them coming and this gives me motivational boost to keep writing more articles.

Thanks everyone for your comments and overwhelming support, greatly appreciate it . I was out of town so sorry for my late reply.

A BIG shout out to @'RZL for his logistics support and help, and thanks to @FMPONE and @Sprony for being very supportive and quick-responding as head admins

As I mentioned in the article, what I showcased is just the beginning and I'm relying and counting on the talented designers in the CSGO community and Mapcore to come up with additional ideas/suggestions to inject life to hostage rescue scenario.

What is dearly needed is more cs_maps getting published to test and refine these ideas as I said in the article's conclusion.

Get mapping