-
Posts
2,140 -
Joined
-
Last visited
-
Days Won
145
Content Type
Profiles
Forums
Articles
Pages
Everything posted by will2k
-
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 Seriously though, those constant updates and additions are commendable; keep up the excellent work.
-
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 ), 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? 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 ) here's a fresh screenshot
-
Trumbo Bryan Cranston is just brilliant
-
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
-
The Dubliners - Whiskey In The Jar (from 1968) Big fan of Irish traditional music; RIP the Dubliners
-
The Martian
-
Displacement Vs. Func_detail - A comparative fps study
will2k commented on will2k's article in Development
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. -
The map will have subtle coloring and hints to allow players to know their location and whereabouts on the fly. You noticed in the previous screenshot the blue color and sector C (in CT corridor), now we have red color and sector T (in T corridor) Hope this will also be useful for callouts
-
Displacement Vs. Func_detail - A comparative fps study
will2k commented on will2k's article in Development
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. -
Displacement Vs. Func_detail - A comparative fps study
will2k commented on will2k's article in Development
As usual, a big shout out to @'RZL, @Sprony, and @FMPONE for their logistical help and feedback/input. Cheers -
Displacement Vs. Func_detail - A comparative fps study
will2k commented on will2k's article in Development
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. -
no problem sharing a common issue with someone can be a relief. Well, I don't think that we are the first ones to have their work "stolen" on the workshop; the thing is Valve's support is utterly slow and frustrating and they don't seem to improve it or work on it despite them popping every 6 months and saying:"we are aware our customer support sucks hard and we are working on it". However, nothing gets done and the cycle repeats. This is unacceptable for a service-oriented company but since they are basically a monopoly in the digital distribution and content delivery, the customer has no leverage or bargaining powers.
-
What is the question?Ever since the dawn of humanity, this question was the center of a colossal debate. Greek and Roman philosophers tried to solve it to no avail. Alchemists in the Middle Ages gave it a go and failed miserably. Even Industrial Age scientists touched on the subject with no big breakthrough. Luckily for everyone, I am here today to answer this question and put an end to a centuries-long argument: What is better in terms of fps, func_detail or displacement, in the context of the Source engine? If you were expecting an existential question, I am deeply sorry to disappoint you but hey, life is full of disappointment. The studyThis is going to be a short but sweet article; fewer words, more numbers and screenshots. The study is pretty straightforward and systematic. To make things fair and square, I will create 2 exactly identical test maps: In one, everything will be turned to func_detail while the other will have everything switched to displacements. I will then proceed to record the localized fps in these maps from a preset location and compare. Pretty simple, isn’t it? Well, it should be as the whole purpose of this study is to compare func_detail vs. displacement in absolute terms while keeping all other parameters constant. The casesThe first map to test is the one made of displacements. Here is the screenshot showcasing the fps. The map itself is very simple consisting of 7 identical houses placed at predetermined locations and surrounded by 4 walls. The houses are detailed enough to put some slight pressure on the rendering engine. For the skeptics among you, here is a wireframe in-game shot to show that everything is made of displacements. To refresh your memories, in Source engine wireframe mode, green is displacements, pink is brushes (world, func_detail, brush entity, etc…), blue is props, and yellow is decals/overlays. The recorded fps in this map is 289. We now move to the second map, the func_detail version to check how the frame rate is faring. Here is the awaited screenshot. Surprise, surprise. The fps is 330, much higher than the displacement version. Here’s the wireframe shot to put your mind at ease. Honestly, I was thinking the figures would be more on par as the engine handles both details and displacements pretty well, but in the end, Source is about BSP so I guess brushes would get a slightly preferential treatment over polygon meshes (conspiracy theory ensues). The question that forces itself now is: Should we rely solely on func_detail in our maps? Of course not. Both func_detail and displacement have their advantages and inconveniences and leaning exclusively on one will inevitably lead you to a dead end. The best thing to do is get the best of both worlds by using them together. In our little test map, how about we mix things up in a third version: let us make the house walls out of displacements while having the doors, windows, frames, and roofs made of func_detail. Incoming screenshot, brace yourselves. Much better, isn’t it? We have now 311 fps, a very nice middle ground between the 330 fps of func_detail and the not-so-bad 289 fps of displacements. The mandatory wireframe shot follows. So, what can we learn from all this? Well, apart from the obvious places where displacements are mandatory for the organic mesh sculpting (rock formations, cliffs, bumpy/twisted roads…), it is a good idea to spread some more displacements around your map to alleviate the total brush-count that you will inevitably hit the maximum in a highly detailed map. Your fps will remain high and you will enjoy the margin to keep adding structures to your map without fear of reaching the maximum allowed total brushes (substituting brushes with models/props is another viable solution that is not in the scope of this article). I’m a man of science and I know that one example is not enough to draw conclusions. That’s fine, I have a second test map to investigate what we established before. The concept of having 2 identical maps is still the same, however, this time, we will spice things up by adding some static/physics props and some decals here and there. We will start with the displacement version. 230 fps, not too shabby. Let’s check another angle. 220 fps, more or less, on the same level as the previous number. Now for the wireframe shot. The tree cards in the background are func_brush in both maps (the detail and displacement versions), so it’s a level playing field in this case. Now for the moment of truth you all have been waiting for: will the detail version have better fps to support my earlier findings or will I be publicly embarrassing myself? A screenshot to the rescue. I knew I was right, never breaking a sweat (apart from the nervous cold sweat I just wiped off my forehead). 255 fps for the first location A. Let’s check the other angle or location B. 250 fps. Bam, sweet victory…sorry I got carried away a bit. Ahem…Let’s get back to being scientific, shall we. Here’s the wireframe proof. Let’s recap all the action and numbers in a nicely formatted table. You can notice the fps gap between the func_detail and displacement versions in both test maps whereas the “mixed” version considerably narrowed this gap. The numbers have spoken. The bottom lineThe bottom line is, if you rely only on func_detail, you will hit the maximum brush-count allowed in Source and severely limit your map and creativity. You might also run into T-junction issues as well as parts of your geometry flickering and disappearing from certain angles in densely func_detail’ed areas. On the other side, if you stick to displacements alone, then you will have lower fps than a func_detail map version. You might also run into visible seams and un-sewn displacement issues. Having a clever distribution of both func_detail and displacement in your map is the way to go. You will have high fps, better lighting around the edges, and organic sculpting while not getting anywhere near the total brush limit; the best of both worlds.
-
Hey, it is definitely not my intention to hijack or derail your thread, but I am in the same exact situation as you are; I thought I'd very briefly share my story with you so you know you're not alone against the frustrating and un-moderated workshop. Basically 2 guys stole a map of mine and uploaded it as their own on the CSGO workshop. They took my map Cortona http://steamcommunity.com/sharedfiles/filedetails/?id=139519337 (released April 16, 2013) unchanged with my custom textures and even the custom description text I wrote, simply changed the name to Pedrizetti and uploaded it on the workshop on Jan 5 2016 claiming it's their own original creation http://steamcommunity.com/sharedfiles/filedetails/?id=593428572. They are even telling other people that it's ok to port the map to other games too. A friend of mine notified me of this on Jan 11, 2016 and I immediately flagged and reported the submission, clearly explaining the issue while providing links to my original map. One week passes and nothing happens, so on Jan 18, I post a message on the official CSGO workshop group http://steamcommunity.com/groups/CSGOMapsWorkshop (The one of Matt Wood where, ironically, I am a moderator there) to try and get the attention of Valve guys in the group. Today is February 7, almost a month has passed and nothing has been done. The stolen map is still on the workshop and no one (admin/mod/support) even contacted me if they need more info or something. I'm aware of the DMCA takedown notice but it seems it has no effect either judging by what you mentioned.(these kind of obvious issues should not need a cumbersome legal DMCA in the first place; the submission is proven stolen and therefore breaks the workshop TOS) The workshop definitely needs better moderation to protect authors' rights and some stricter rules for copyright infringers and obvious thieves. I've been a vocal advocate about this since the Arms deal update in Aug 2013: the workshop is a total jungle with near absent moderation, and support is a big fat joke; and it's not even a funny joke. Sorry for this rant and it is not my intention to hijack this thread; just to let you know that you are not alone .
-
They should have used a proper heavy metal remake of E1M1 (Same like Duke Nukem Forever did with the classic midi "Grabbag" of 1996) Something like this: If this doesn't get your adrenaline pumping, nothing will
-
Great stuff Jack, thanks for sharing I'll see what I will include without affecting CSGO mechanics/gameplay much. The map already has a non-interactive retinal scanner, so I might bring it "alive"
-
- ...last player alive in Ts, slowly approaching bombsite - peeks quietly around a corner to scout the area - Gman suddenly "appears" in front of him - player pees himself and starts firing uncontrollably - player gives away his position and is shot dead - player quits CSGO and stares at his desktop screen... But seriously, I like your idea of small HL Easter eggs; the Gman might be a bit extreme for CSGO but I'll see what I can cook in here
-
Not sure if I should expect a headcrab/vortigaunt or a terrorist running down the stairs
-
Jeff Dunham: Unhinged in Hollywood
-
Thanks. I'm really glad people are noticing the Half-Life theme on the fly; I guess my work is done
-
Thank you. The map is based on Half-Life and Opposing Force for the old school look of a recently evacuated research/military facility.
-
After nearly 2 months of extended break (holidays and whatnot), I resumed work on the map. Started detailing CT spawn
-
Listening to the new Megadeth album, Dystopia
