Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 11/24/2021 in all areas

  1. El Moroes

    Dune

    3 points
  2. will2k

    GTA V

    Most people are calling it "the Defective edition"
    3 points
  3. will2k

    Chess

    2 points
  4. I got it a couple weeks back on ps5 and I've been having a blast! Really cool game! I bought it on a day when I was bored and I remember someone telling me it was a good game. It was pretty great because I went in knowing nothing about this game. It took a good 4 hours before I even realized I was playing a hybrid roguelike. I love that feeling of being overwhelmed in a world initially. Anyways it's been about 2-3 weeks since I got it and now I think I'm getting close to the end and I know my way around the 4 levels pretty good now but it's been super fun getting there. This game does something I love. They reduce the overall breadth of the game to have a more nuanced and detailed small area. I remember Mr Warren DeusEx (forget his last name) saying something to the effect that he would love to take the effort of a massive game and compress it down to a city block. I feel like this game does that to some degree and I love it. I'm a huge fan of smaller, more detailed, ever-changing worlds. Also I never thought I'd see the day I play an FPS with a console controller but it's a single player game and I'm a lazy old man who likes sitting on the couch and playing a game on the big TV without a lot of fiddling.
    2 points
  5. FMPONE

    mr. FMPONE

    I updated my portfolio, no particular reason just got bored of my old one and everyone had updated theirs fmpone.com
    1 point
  6. will2k

    Chess

    There is a reason you only "recently" heard about this; it's a useless crossover.
    1 point
  7. Buddy

    GTA V

    Had a laugh at the flip-off bit, shows how little they cared about the source material.
    1 point
  8. will2k

    GTA V

    1 point
  9. -HP-

    Dune

    1 point
  10. -HP-

    Far Cry 6

    They're indeed a far cry from the original game.
    1 point
  11. Bunglo

    Far Cry 6

    Far Cry, the game that had 5 sequels without having an actual sequel.
    1 point
  12. Buddy

    Far Cry 6

    I'm amazed this isn't called 'Far Cry', seems about time for a confusing reset to the original title.
    1 point
  13. Two months ago I became a dad for the first time. Mom was amazing and I can't be more proud of her and baby is doing really well. Sleep was hard at first but we're finally getting some kind of routine going and I'm getting maybe 4-6 hours of sleep at night which isn't bad and since I'm working from home it's not really an issue, no danger of me falling asleep at the wheel driving into the office! We've also been in our house for a year now, decorated thoughout and had the garden completely redeveloped so we can spend time in it and our little one with have somewhere to play outside when he's older. To top it all off I just got promoted to Assistant Lead Level Designer at Rebellion. I would never had imagined I'd get to a leadership role when I joined the industry just under 10 years ago and young me would never have thought I'd even get into the industry! Fair to say I'm pretty happy with life at the moment... just wish I had a bit more time for some games
    1 point
  14. 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.
    1 point
  15. 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.
    1 point
  16. Thanks for writting this article, i believe it's an interesting subject and what you did clearly shows that more detailed models do clearly impact performances. But i'm also a bit disappointed, you could have pushed this a lot further. There are only 2 sets of data with only 2 points for each one, which is really not enough in my opinion. For example, it just can't answer in what way the performances are decreasing with the polycount increasing. And it would have been much more interesting to see the results on a graphic instead of showing a delta, something like this for example : You could have made a sort of "test sample" model, that you could have compiled in 10 versions for example (from 500 to 50 000 tris for example, i'm not even sure you can compile that, but you get the idea!). And you can then make 11 tests and get 11 points : without the model and with 1 version of the model every single time. Then you could have used that model many times, and see if there is some instancing that makes the use of the same model many times cheaper in the same rendering. Everytime you can note the polycount in each renderings and get much more results. You could also have combined them, for example imagine if you can make a conclusion like this (which is just an example, it's totally wrong) : Ok that would be hard to trust, because lots of other stuff could skew results (depending of what shaders you used for example, as you said in your article), but that would be extremely useful for Artists and Level Designers ! It's just an idea, maybe it's not reliable but that would be nice.
    1 point
  17. Thank you . Glad you liked these articles and found them helpful. Thanks seir The points you mentioned are a bit advanced and could be the topic of a future article that goes further deep in the study; bear in mind I'm no programmer but it will be interesting and useful as you mentioned. Will keep this in mind for future articles that I plan to write As for PIX, AFAIK it is now deprecated and it is currently part of the windows SDK, more precisely the Microsoft Visual Studio called Visual Studio Graphics Debugger. I will see if there are other alternatives for the PC as you mentioned the Crytek one, so there's bound to be others Thanks again for the insights. Thanks for the uplifting comment and the continuous support
    1 point
  18. 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.
    1 point
  19. 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.
    1 point
  20. 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.
    1 point
  21. That's really neat! Well visualized. Did you also test how much the power of the displacements affected the FPS? Those in the screenshots seem to be power 4, so maybe depending on how you use them you could make them power 2 to save even more FPS?
    1 point
×
×
  • Create New...