This week has primarily been a continuation of the work started last week consisting of bug fixes, concept art for our new ships, and rough mockup meshes for the new ships. We’ve also been spending a lot of time this last week going back over all of our materials to make sure that they have proper brightness and contrast.
Part of the reason Infinity: Battlescape looks so good is that it’s using a technique called Physically Based Rendering (PBR). This means that we do a lot of fancy math stuff to ensure that our simulation adheres to the real world laws of physics, such as the law of conservation of energy, which results in a more photo-realistic looking game. This changes the way our artists have to think about creating materials relative to how they have traditionally produced game assets and so we reviewed everything to make sure that our art is cohesive and to ensure everybody is building assets the best way possible.
A problem that we’ve known about for a while has to do with how we handle High Dynamic Range (HDR) rendering. Unlike most (all?) other games we’re using realistic quantities of light. The difference in lighting environments between space and atmospheric flight is enormous. Unfortunately that creates some rather challenging problems for us. Without getting too technical we’re losing a lot of contrast when a ship is exposed to high quantities of light and it’s making it difficult for our artists to properly author their textures. Originally this was going to be fixed in the polish phase of the game but due to its impact on our art team it looks like we’ll have to address it sooner rather than later.
This week we’ve started integrating the rough 3D mockups of the new ships into the prototype. We’re looking forward to releasing a patch soon to begin collecting feedback from those of you who have pledged Developer Access as we’re confident they will require a lot of iteration between now the release of the final game!
You said you’re running into contrast issues with HDR rendering. Would an HDR monitor work well with that system? What would work for this game to support both typical monitors and HDR ones? How would it work with VR headsets (if there’s any difference)? Would a gameplay solution work, such as a cockpit filter that justifies autoadjusting for realistic lighting?
@frag971, my guess is that the issue is in their calculations, not in the manner in which the display hardware presents the results. It’s a precision problem, where in some cases huge absolute numbers are being thrown at the pipeline, but the engine is trying to retain very fine gradations in the output. So 100,000,000 lux is reaching an object, and 90,000,010 is being reflected off one surface while 90,000,001 is being reflected off an adjacent surface. Throw in HDR (let your eyes ‘adjust’) and you want to show something like 10 being reflected off the first surface and 1 being reflected off the second. But because computers are limited on precision of calculations, the current code is kicking out 10 and 5. Or perhaps even 10 and 10. The contrast is either diminished or lost entirely.
This affects texture design because those ‘surfaces’ could just be different parts of the same surface with different texture information. With things the way they are right now, the artists have to choose between accuracy in low light versus accuracy in bright light.
If my speculation is accurate, it’s the analogous problem to trying to move with centimeter precision within a space the size of a planetary system.
Yes buuuuuuuuuut. And this is a big buuuuuuuuuuut. (|)
This is a flavour drawing. While I would love to make a station that big, its probably not doable for us at this time. The amount of required detail to get the scale to look good is insane.
Such a station would likely require the same sort of procedural generation as is used for moons, but with mechanical greeble instead of terrain, and applied across the surface of a non-spherical object. Levels of detail for closer or more distant sections of the station, etc. It would be an interesting project.
At least you wouldn’t have to worry about an atmosphere…
Do they have procedural generation for structures? I heard that their objects can only have one fixed elevation value for a coordinate, which would mean that overhangs and hollow spaces are not possible.
Taking into account the small team and limited amount of time, it’s probably something best left for end dev polishing.
Nonetheless, it would look great.
