• Advertisement


Senior Moderator
  • Content count

  • Joined

  • Last visited

Everything posted by Promit

  1. The lit areas of my mesh rotate with the mesh

    fragPos = vec3(model * vec4(vertex, 1.0)); camPosition = camera; gl_Position = mvp * vec4(fragPos, 1.0); Didn't you just multiply through with model twice here? fragPos already contains model when you hit it with mvp.
  2. Because email addresses and phones get stolen all the damn time. The idea of two factor authentication is to avoid having a single point of compromise become built into a major breach.
  3. If nothing else, I consider 4 GB of memory unacceptable in a modern dev machine. I have a 4 GB surface and it struggles to actually load and build our project due to memory issues. Not struggles to run it - struggles to build it.
  4. Man, the guys above are too dire. I wrote most of this same stuff when I was fifteen, what’s with all this “this is hard to do without an engine” nonsense? Don’t know what the point is if we’re not going to help the newbies do real work. Let’s get down to it. Terrain: it’s a nice idea that might need a few tweaks. My suggestion is to look up terrain “splatting” or “splat maps”. It’s not quite what you asked for but I think it’ll be helpful. Collision: object space AABB per model, world space AABB per instance. Drawing collision: I prefer to run these and all other debug rendering through a separate render pipeline based entirely on dynamic buffers and streaming vertex rendering. This makes it a lot easier to add additional displays/modes and info. Shaders: both good choices, roll with what works
  5. Backups (online and image)

    I'm using Crashplan for Business - the personal product was discontinued recently. I'll likely change soon, as the business offering is likely not the most cost effective choice. No image support though, so if you're going to insist then no dice.
  6. OpenGL Uniforms

    https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glGetUniformLocation.xhtml Typically if you're certain you didn't make a typo, it's the part I've bolded about "active" that catches people off guard. If the shader as compiled doesn't use the uniform variable, it's considered not active and won't be assigned a location even if it's listed in the source code.
  7. I have screens that are: 3840 x 2160 2880 x 1800 <-- 16:10, some people just letterbox down to 16:9 2560 x 1440 2560 x 1080 <-- this is the bitchy one, at 21:9 1650 x 1080 I would want to be able to play on those in some sensible fashion, whether it's resized or whatever.
  8. A Common Thread

    I believe this thread has run its course. In the future, I would suggest to many of you that the way to stop a fire is to take away its oxygen, not explain why it's wrong about game development.
  9. Input on Adult Content

    I've seen games (more indie-ish stuff) that tackled the topic of sex in a reasonably mature and serious way, typically in the context of a "romance/dating sim" type of genre. Granted there's a lot of cheap porno garbage in that world too, but there are some serious attempts. I've also seen plenty of things that are just comedic or absurd, as you mentioned. God of War comes to mind as a mainstream game where the sex sequences are stupid. Something that includes it in a fluid fashion, though... that's tough. The Bioware RPGs - you mentioned DA and there are others - tend to effectively have "relationship" side quests and they're typically quite PG-13. In a broad artistic sense, of course this is possible to do properly. Many other mediums - books, film, television, theatre - have done it for ages. I'm hard pressed to identify a game that handles it with the maturity and seriousness seen in those other creative worlds, though.
  10. You've gotten some excellent answers, so let me take a different tack. At the end of the day, it's all about goals. Is your goal to: Develop the game of your dreams and bring your ideas to life? Go professionally into game design or high level programming (AI, game logic, etc)? Use an engine. This is what they are there for. Understand how everything works, and maybe eventually become a professional engine or low level developer? Build everything yourself. Obviously both are legitimate paths to choose, but they're very different.
  11. You have to understand first and foremost that GPUs haven't had any concept of 2D for quite a few years now. Your "2D" pieces are just 3D pieces that aren't very interesting geometrically. They go through the same exact pipeline in the same exact way. As long as there are valid depth values and your depth states are set up in the usual way, things get ordered in space as you'd expect. If you disable the depth buffer, then things will strictly follow draw order both across and within draw calls. There's no "to an extent". The depth buffer will solve this with pixel perfect results every time, as long as alpha blending isn't involved. Draw order, number of draw calls, doesn't matter.
  12. Can't on mobile, if you're looking for wide support. Is Metal available or run the GL ES pipeline? Is Vulkan available or run the GL ES pipeline?
  13. If you want this to work, I would start the implementation with two APIs. AZDO GL 4.5 and DX11 would be sufficient. Trust me, this will expose a lot of blindspots that you miss even if you're pretty familiar with multiple APIs. Been there, done that, have the wide-ranging commits to atone for my oversights.
  14. I wouldn't worry too much about the use of runtime polymorphism. It's way down on the list of interesting or useful problems. The key point you need to think about is, what level will the abstraction exist on? There are two equally valid ways to do this. You can create "API-level" abstractions for buffers, textures, shaders, etc and implement common interfaces for the different APIs. Or you can define high level concepts - mesh objects, materials, scene layouts, properties - and let each API implementation make its own decisions about how to translate those things into actual GPU primitives and how to render them. There are a lot of trade-offs inherent in both approaches.
  15. OpenGL Origins of Open GL libraries

    There hasn't been a DirectX SDK in more than seven years. The requisite files are built into the development environment. Same deal with OpenGL. You don't ask about the SDK any more than you ask about the SDK for iostream. The headers and libraries are there by virtue of having a sensible build environment for your target platform in the first place. Similarly, there are platform specific calls to fire the whole thing up in the first place. Once the platform implements OpenGL support, the functions are all part of that same environment.
  16. Changing uniform parameters is cheaper than changing program, and this holds true for a very large number of uniforms. Once you've changed any uniform, changing more is all blocked into one operation and the incremental cost is very small. Uniform branching in a single shader is a perfectly reasonable way to develop, though I've had performance trouble with it on certain mobile platforms. Now whether uniform branching in a single shader is a good design for readability and maintainability is up to you. The ideal case is probably to move to uniform buffer objects and swap the entire block of settings in one go. But it's certainly not inherently advantageous to have separate shaders.
  17. This is Part 1 of a series examining techniques used in game graphics and how those techniques fail to deliver a visually appealing end result. See Part 0 for a more thorough explanation of the idea behind it. High dynamic range. First experienced by most consumers in late 2005, with Valve’s Half Life 2: Lost Coast demo. Largely faked at the time due to technical limitations, but it laid the groundwork for something we take for granted in nearly every blockbuster title. The contemporaneous reviews were nothing short of gushing. We’ve been busy making a complete god awful mess of it ever since. Let’s review, very quickly. In the real world, the total contrast ratio between the brightest highlights and darkest shadows during a sunny day is on the order of 1,000,000:1. We would need 20 bits of just luminance to represent those illumination ranges, before even including color in the mix. A typical DSLR can record 12-14 bits (16,000:1 in ideal conditions). A typical screen can show 8 (curved to 600:1 or so). Your eyes… well, it’s complicated. Wikipedia claims 6.5 (100:1) static. Others disagree. Graphics programmers came up with HDR and tone mapping to solve the problem. Both film and digital cameras have this same issue, after all. They have to take enormous contrast ratios at the input, and generate sensible images at the output. So we use HDR to store the giant range for lighting computations, and tone maps to collapse the range to screen. The tone map acts as our virtual “film”, and our virtual camera is loaded with virtual film to make our virtual image. Oh, and we also throw in some eye-related effects that make no sense in cameras and don’t appear in film for good measure. Of course we do. And now, let’s marvel in the ways it goes spectacularly wrong. In order: Battlefield 1, Uncharted: Lost Legacy, Call of Duty: Infinite Warfare, and Horizon Zero Dawn. HZD is a particular offender in the “terrible tone map” category and it’s one I could point to all day long. And so we run head first into the problem that plagues games today and will drive this series throughout: at first glance, these are all very pretty 2017 games and there is nothing obviously wrong with the screenshots. But all of them feel videogamey and none of them would pass for a film or a photograph. Or even a reasonably good offline render. Or a painting. They are instantly recognizable as video games, because only video games try to pass off these trashy contrast curves as aesthetically pleasing. These images look like a kid was playing around in Photoshop and maxed the Contrast slider. Or maybe that kid was just dragging the Curves control around at random. The funny thing is, this actually has happened to movies before. Hahaha. Look at that Smaug. He looks terrible. Not terrifying. This could be an in-game screenshot any day. Is it easy to pick on Peter Jackson’s The Hobbit? Yes, it absolutely is. But I think it serves to highlight that while technical limitations are something we absolutely struggle with in games, there is a fundamental artistic component here that is actually not that easy to get right even for film industry professionals with nearly unlimited budgets. Allow me an aside here into the world of film production. In 2006, the founder of Oakley sunglasses decided the movie world was disingenuous in their claims of what digital cameras could and could not do, and set out to produce a new class of cinema camera with higher resolution, higher dynamic range, higher everything than the industry had and would exceed the technical capabilities of film in every regard. The RED One 4K was born, largely accomplishing its stated goals and being adopted almost immediately by one Peter Jackson. Meanwhile, a cine supply company founded in 1917 called Arri decided they don’t give a damn about resolution, and shipped the 2K Arri Alexa camera in 2010. How did it go? 2015 Oscars: Four of the five nominees in the cinematography category were photographed using the ARRI Alexa. Happy belated 100th birthday, Arri. So what gives? Well, in the days of film there was a lot of energy expended on developing the look of a particular film stock. It’s not just chemistry; color science and artistic qualities played heavily into designing film stocks, and good directors/cinematographers would (and still do) choose particular films to get the right feel for their productions. RED focused on exceeding the technical capabilities of film, leaving the actual color rendering largely in the hands of the studio. But Arri? Arri focused on achieving the distinctive feel and visual appeal of high quality films. They better understood that even in the big budget world of motion pictures, color rendering and luminance curves are extraordinarily difficult to nail. They perfected that piece of the puzzle and it paid off for them. Let’s bring it back to games. The reality is, the tone maps we use in games are janky, partly due to technical limitations. We’re limited to a 1D luminance response where real film produces both hue and saturation shifts. The RGB color space is a bad choice to be doing this in the first place. And because nobody in the game industry has an understanding of film chemistry, we’ve all largely settled on blindly using the same function that somebody somewhere came up with. It was Reinhard in years past, then it was Hable, now it’s ACES RRT. And it’s stop #1 on the train of Why does every game this year look exactly the goddamn same? The craziest part is we’re now at the point of real HDR televisions showing game renders with wider input ranges. Take this NVIDIA article which sees the real problem and walks right past it. The ACES tone map is destructive to chroma. Then they post a Nikon DSLR photo of a TV in HDR mode as a proxy for how much true HDR improves the viewing experience. Which is absolutely true – but then why does the LDR photo of your TV look so much better than the LDR tone map image? There’s another tone map in this chain which nobody thought to examine: Nikon’s. They have decades of expertise in doing this. Lo and behold, their curve makes a mockery of the ACES curve used in the reference render. Wanna know why that is? It’s because the ACES RRT was never designed to be an output curve in the first place. Its primary design goal is to massage differences between cameras and lenses used in set so they match better. You’re not supposed to send it to screen! It’s a preview/baseline curve which is supposed to receive a film LUT and color grading over top of it. “Oh, but real games do use a post process LUT color grade!” Yeah, and we screwed that up too. We don’t have the technical capability to run real film industry LUTs in the correct color spaces, we don’t have good tools to tune ours, they’re stuck doing double duty for both “filmic look” as well as color grading, the person doing it doesn’t have the training background, and it’s extraordinary what an actual trained human can do after the fact to fix these garbage colors. Is he cheating by doing per-shot color tuning that a dynamic scene can’t possibly accomplish? Yes, obviously. But are you really going to tell me that any of these scenes from any of these games look like they are well balanced in color, contrast, and overall feel? Of course while we’re all running left, Nintendo has always had a fascinating habit of running right. I can show any number of their games for this, but Zelda: Breath of the Wild probably exemplifies it best when it comes to HDR. No HDR. No tone map. The bloom and volumetrics are being done entirely in LDR space. (Or possibly in 10 bit. Not sure.) Because in Nintendo’s eyes, if you can’t control the final outputs of the tone mapped render in the first place, why bother? There’s none of that awful heavy handed contrast. No crushed blacks. No randomly saturated whites in the sunset, and saturation overall stays where it belongs across the luminance range. The game doesn’t do that dynamic exposure adjustment effect that nobody actually likes. Does stylized rendering help? Sure. But you know what? Somebody would paint this. It’s artistic. It’s aesthetically pleasing. It’s balanced in its transition from light to dark tones, and the over-brightness is used tastefully without annihilating half the sky in the process. Now I don’t think that everybody should walk away from HDR entirely. (Probably.) There’s too much other stuff we’ve committed to which requires it. But for god’s sake, we need to fix our tone maps. We need to find curves that are not so aggressively desaturating. We need curves that transition contrast better from crushed blacks to mid-tones to blown highlights. LUTs are garbage in, garbage out and they cannot be used to fix bad tone maps. We also need to switch to industry standard tools for authoring and using LUTs, so that artists have better control over what’s going on and can verify those LUTs outside of the rendering engine. In the meantime, the industry’s heavy hitters are just going to keep releasing this kind of over-contrasty garbage. Before I finish up, I do want to take a moment to highlight some games that I think actually handle HDR very well. First up is Resident Evil 7, which benefits from a heavily stylized look that over-emphasizes contrast by design. That’s far too much contrast for any normal image, but because we’re dealing with a horror game it’s effective in giving the whole thing an unsettling feel that fits the setting wonderfully. The player should be uncomfortable with how the light and shadows collide. This particular scene places the jarring transition right in your face, and it’s powerful. Next, at risk of seeming hypocritical I’m going to say Deus Ex: Mankind Divided (as well as its predecessor). The big caveat with DX is that some scenes work really well. The daytime outdoors scenes do not. The night time or indoor scenes that fully embrace the surrealistic feeling of the world, though, are just fantastic. Somehow the weird mix of harsh blacks and glowing highlights serves to reinforce the differences between the bright and dark spots that the game is playing with thematically throughout. It’s not a coincidence that Blade Runner 2049 has many similarities. Still too much contrast though. Lastly, I’m going to give props to Forza Horizon 3. Let’s be honest: cars are “easy mode” for HDR. They love it. But there is a specific reason this image works so well. It is low contrast. Nearly all of it lives in the mid-tones, with only a few places wandering into deep shadow (notably the trees) and almost nothing in the bright highlights. But the image is low contrast because cars themselves tend to use a lot of black accents and dark regions which are simply not visible when you crush the blacks as we’ve seen in other games. Thus the toe section of the curve is lifted much more than we normally see. Similarly, overblown highlights mean whiting out the car in the specular reflections, which are big and pretty much always image based lighting for cars. It does no good to lose all of that detail, but the entire scene benefits from the requisite decrease in contrast. The exposure level is also noticeably lower, which actually leaves room for better mid-tone saturation. (This is also a trick used by Canon cameras, whose images you see every single day.) The whole image ends up with a much softer and more pleasant look that doesn’t carry the inherent stress we find in the images I criticized at the top. If we’re looking for an exemplar for how to HDR correctly in a non-stylized context, this is the model to go by. Where does all this leave us? With a bunch of terrible looking games, mostly. There are a few technical changes we need to make right up front, from basic decreases in contrast to simple tweaks to the tone map to improved tools for LUT authoring. But as the Zelda and Forza screenshots demonstrate, and as the Hobbit screenshot warns us, this is not just a technical problem. Bad aesthetic choices are being made in the output stages of the engine that are then forced on the rest of the creative process. Engine devs are telling art directors that their choices in tone maps are one of three and two are legacy options. Is it bad art direction or bad graphics engineering? It’s both, and I suspect both departments are blaming the other for it. The tone map may be at the end of graphics pipeline, but in film production it’s the first choice you make. You can’t make a movie without loading film stock in the camera, and you only get to make that choice once (digital notwithstanding). Don’t treat your tone map as something to tweak around the edges when balancing the final output LUT. Don’t just take someone else’s conveniently packaged function. The tone map’s role exists at the beginning of the visual development process and it should be treated as part of the foundation for how the game will look and feel. Pay attention to the aesthetics and visual quality of the map upfront. In today’s games these qualities are an afterthought, and it shows. UPDATE: User “vinistois” on HackerNews shared a screenshot from GTA 5 and I looked up a few others. It’s very nicely done tone mapping. Good use of mid-tones and contrast throughout with great transitions into both extremes. You won’t quite mistake it for film, I don’t think, but it’s excellent for something that is barely even a current gen product. This is proof that we can do much better from an aesthetic perspective within current technical and stylistic constraints. Heck, this screenshot isn’t even from a PC – it’s the PS4 version. View the full article
  18. I’m about to start a series of blog posts called Games Look Bad. Before I start throwing stones from my glass house over here, I wanted to offer an explanation of what I’m doing and a defense of why I’m doing it. There’s no doubt that we’ve seen a sustained and significant period of improvement in real-time computer graphics over the past three decades. We’ve made significant advances in nearly every aspect of visual look and feel, drawing quite a bit from the film industry in the process. So why the heck do most games look so bad? Games are technically much more sophisticated than ever before, but I’m going to stake out a claim: aesthetically something has gone quite wrong, and the products don’t live up to the hype. Show me a next-gen, cutting edge game and I will show you an image that no competent film industry professional would ever deem acceptable. Why not? The answer lives at the crossroads of art and technology, a strange neglected intermediary which we in the industry tend to avoid talking about. Particularly in the last ten years, several new techniques have appeared that are foundational to practically every high end game on the market. These are well documented from a technical standpoint, and it’s generally assumed that graphics programmers who have stayed current are fluent in at least the basic goals and implementations of these techniques, if not the finer points of them. I won’t labor to build a complete list, but you likely know them: normal maps, HDR/tonemaps, physically based shading, volumetrics, DoF/bokeh, etc. What’s extremely difficult to find, though, is a discussion of how to make these techniques visually appealing. Oh sure, we’ll sort of handwave it from time to time, but graphics programmers as a set don’t like talking about visual appeal in the way that artists do. It’s much easier to build the tools and then let the artists make it pretty. Except the artists, even the tech artists, don’t always have the know-how or mathematical tools to solve that problem. Sometimes we end up borrowing our looks from someone else – how many of you have googled FilmLut.tga? How many of you are using Unreal’s tone map operator, tweaked or even verbatim? This series is going to take a sharply critical tone towards most AAA games being shipped today, because it’s my belief that there are fundamental problems with many of the techniques we’re using today that reach beyond strictly technical constraints. Graphics programmers and engines are implementing many techniques for new effects without taking the time or energy to properly refine the visual and aesthetic aspects of those effects. Marketing tells us we should be impressed by all the new features, yet when you take a step back from the fact that these are games and evaluate the images without that context, they look horrible. This is a problem that is fixable today, with current technology. I don’t know if my thesis here is particularly well developed, but it’s a good excuse for the meat of this series. I don’t want to talk about how to implement techniques. There are many people who have done an excellent job of that and you should have that background coming in. I’m going to talk about the visual choices we make in these techniques, how they make our games better, how they make our games worse, and whether we’re using them well. I’m going to encourage everyone to think critically about why and how we’re implementing the things that make modern games tick, and examine the tunnel vision that has afflicted that process maybe since the beginning. And in the process, I’m going to criticize people’s work which far exceeds my own in every respect, while largely failing to provide solutions to problems. I know that and I accept it. And that is where we shall start. View the full article
  19. Yes, with caveats. You can only Discard a buffer so many times* before the driver stalls. Think of it like this: when you are doing this, your buffer is actually three buffers internally. Each time you discard, it switches from buffer 0 to 1, 1 to 2, 2 to 3, 3 to 0. But if that switch to 0 arrives while 0 is still in use, you're going to stall. So the buffer has to be big enough that you don't do this more than once or maybe twice a frame in order for the GPU to clear pending operations. It's best to make the buffer big enough to accommodate an entire frame's rendering in one go with the occasional spill. * The limit doesn't apply to constant buffers, which are magical buffers that can service thousands of discards per frame.
  20. You don't need to rebind. There may be a hit if you Map a buffer that is still in use by the GPU, depending on the flags. Choose wisely between Discard and No Overwrite. Discard will only stall if you Map it a lot without letting frames complete. It's a good choice if you only Map that buffer once a frame. No Overwrite should not stall, but may corrupt if you overwrite in-use data. It's good for streaming purposes where you never go backwards. Remember that this still counts across frames, you should Discard once before No Overwrite, or else set GPU fences. If you're lost at this stage, take a look here: https://msdn.microsoft.com/en-us/library/windows/desktop/dn508285(v=vs.85).aspx
  21. Make the angle negative? If you're trying to figure out the direction the truck is turning by using QuaternionToAxisAngle, that's not really a good idea. What you can do is limit the angle to 180 degrees or PI radians, and subtract 360 or 2*PI from it if it comes up higher.
  22. OpenCV

    It's a very large, expansive library with many different pieces for many different things. IME the best thing to do is have a specific project in mind and pursue the information needed to do the specific tasks required to solve that project. You can't just learn OpenCV, as such, because it's too big and none of it really makes any sense without the context of trying to accomplish something.
  23. Well, if the dialogue people are demanding stuff... they're the ones paying the bills, I suppose. Wrong approach to things IMO, but whatcha gonna do.
  24. They're two different expressions of the same thing. The latter takes aspect and FoV-Y. The former takes the dimensions of the near plane. You can derive these quantities from each other with some simple trig.
  25. 3D Using Sketchup as an architectural tool?

    Moving to Visual Arts. I've seen a lot of game designers use SketchUp to do rough level layout work, since it's much faster than any conventional modeler. But everyone goes back and swaps the SketchUp outputs with real models later. It's right there in the name - sketch. Use it to get the overall shape of things, don't rely on it to do all the detail work.
  • Advertisement