Duion said, people have tried implementing DSSDO, but this looks like a slightly different(and more accurate) technique.

Pretty much the same big potential hangup though - doesn't work with stuff outside the view. Still, probably worth looking into depending on how fast it is. Getting high quality AO + potentially cheap "good enough" GI wouldn't be a bad compromise if it's fairly fast. The other advantage it'd have over the SVOTI method i'm looking into is it'd work with dynamic objects. Hm. Maybe that could be combined....

I ended up getting less done than I'd hoped. I was getting the sRGB stuff pulled out of the PBR rnd stuff to PR, and it touches a LOT of spots, so it took me a fair while to de-tangle for a PR. There's still a tidibt or two to shore up for a real PR, but it's just about ready. Once that's in, there's some API cleanup stuff, and then just the PBR stuff itself. Then onto assets and e/c!

Speaking of the PBR branch, az worked some magic and got parallax correction working pretty nicely, which you can see here:

As you can see, the reflections on the walls pretty well closely match up to the respective direction. With it working, there's a very solid - but still cheap - reflection for the environment that keeps things grounded in the scene. From here, we'll get Screen Space Reflections added on top to catch more dynamic objects and cover over any inaccuracies in the baked reflections.

JeffR wrote:We're also looking at shifting to a single shader language that's compiled into the appropriate platform's shader language as needed. This would simplify things for those that want to manually write shaders, would cut down on duplication of common shaders we use for lighting and other baseline render behaviors, and would be easier to maintain on the shadergen side of things.

Mostly just a question of the best approach for it. We can use macros in the shaders to pretty much translate the language-specific elements(floats vs vecs, mix vs lerp, yada yada) auto-magically. There's also transpiler options, like one that the Khronos group is working on that's coming along nicely where you pass it a shader type, and it'll compile it into Spirv, which can be stored as-is, but then also compiled into HLSL, GLSL and MetalSL without any manual work. So we've got options there that are looking promising as well. But the end-goal is to standardize and simplify how much work the shader backend is to maintain(and for the end users to have to work with) so that's all looking good.

Do you have a reference for the Khronos transpiler? That sounds awesome. I assume part of the project is this: https://github.com/KhronosGroup/SPIRV-LLVM for the -> SPIR-V side of things, but I couldn't dig up anything on SPIR-V -> HLSL/GLSL/MetalSL (other than the expensive commercial stuff for Metal).

btw - worth following @morgan3d on Twitter if you're interested in rendering stuff.

JeffR wrote:We're also looking at shifting to a single shader language that's compiled into the appropriate platform's shader language as needed. This would simplify things for those that want to manually write shaders, would cut down on duplication of common shaders we use for lighting and other baseline render behaviors, and would be easier to maintain on the shadergen side of things.

Mostly just a question of the best approach for it. We can use macros in the shaders to pretty much translate the language-specific elements(floats vs vecs, mix vs lerp, yada yada) auto-magically. There's also transpiler options, like one that the Khronos group is working on that's coming along nicely where you pass it a shader type, and it'll compile it into Spirv, which can be stored as-is, but then also compiled into HLSL, GLSL and MetalSL without any manual work. So we've got options there that are looking promising as well. But the end-goal is to standardize and simplify how much work the shader backend is to maintain(and for the end users to have to work with) so that's all looking good.

Do you have a reference for the Khronos transpiler? That sounds awesome. I assume part of the project is this: https://github.com/KhronosGroup/SPIRV-LLVM for the -> SPIR-V side of things, but I couldn't dig up anything on SPIR-V -> HLSL/GLSL/MetalSL (other than the expensive commercial stuff for Metal).

btw - worth following @morgan3d on Twitter if you're interested in rendering stuff.

It's a two stage process , glslang which can take glsl & hlsl to spir-v and spirv-cross which takes spir-v back to hlsl/glsl/msl

Last weekend, or more specifically, the thursday leading up to it, I suffered a very fast, sudden harddrive failure of my main gamedev drive. The good news is I obsessively back up my stuff in several locations, so pragmatically I only lost a few hours of work in the end.

So before I continue, we're going to talk about that, because I feel it something people don't take as seriously as they should.

Backups, Loss Prevention, And YouMy setup prior to the harddrive failure was a main OS drive, main gamedev drive, backup drive(manually copied) and game drive. I then also had a 4TB archival drive with a backup task that would generate diff'd backups of my stuff as needed. This sucker ended up being what saved me from losing quite a lot of time(the backup drive would also have, but it was comparitively out of date).

Hard drive failures are far less common than they used to be, and depending on the manufacturer, and more specifically, the model type, they can be rated to last nearly a decade. My dev drive lasted me a good 5-ish years, which, given the frequency I do full pulls of T3D(thousands of files), then go compiles(hundreds more files), then install the template(hundreds more files), then delete them and do it all again, it's not a surprise that I have a good deal more wear and tear than the norm. But even then, it still means that at some point, your harddrive is going to fail, and it usually happens fast.

While there's still hope in that case of getting it to recovery experts who can do stuff like dissasemble the drive and manually read/reconstruct the data off it, that usually runs several hundred dollars or more depending on the amount to be recovered. And so prevention of loss is your best bet.

A single archive drive with some software that does regular backups is going to largely be sufficient, though I've personally started to look into building a NAS - Network Attached Storage - Server. Redundant RAID, the whole nine yards. That'll cost several hundred to build, compared to, say, 100 a simple My Cloud external harddrive will run you from any given store, but it has a lot more space, and redundant drives, so total data loss would involve something more like "meteorite flew into my house and obliterated everything". At which point your saving grace would be off-site sotrage, such as just uploading everything to FTP or github.

But for 99.999% of cases, that's going to be perfectly sufficient.

So yeah, not going to tell you guys what to use, but I'd VERY highly recommend taking a bit, doing some googling, and at least looking into some pre-made solutions that are pretty much external drives + software. Often, the major manufacturers such as Samsung, Western Digital, etc also have 2 or 4 bay variants that automatically RAID the drives for redundancy, so if an archive drive fails, you only lose data if both drives go.

It can save you a LOT of grief and time for only a $100 or so investment, and I'd really, really recommend investing.

Anyways, back to my weekends.

So, lost a little bit of data, but almost all of it was safe and cozy. I bought a new gamedev drive(1TB, a nice upgrade from my old 250gb) and got the backup restored on it.Went to get working again, and cmake refused to generate new projects - unable to find the VS compiler.

Wat.

I realized that I had various libraries installed onto my gamedev drive, and apparently windows' linkage to the install locations broke. Tried uninstalling and reinstalling cmake - nope. Uninstall and reinstall VS - nope. Used their total uninstall utility, which uninstalls anything and everything even USED by VS. Reinstalled everything clean - no nada.So, had to do a clean install of windows(probably due for one anyways, so I guess that worked out). Figure I'd take the time to move from my sad little 90gb OS drive to a 160gb I had lying around.

Go to install windows 7 - corrupts on the first reboot. Balls. Tired it again, same result. I hadn't messed with that drive in months, so it's possible the drive went bad. So drive to the store, and nab a new 120gb SSD. Go to install windows again, same issue.

So apparently the disk is damaged and a critical file is failing to copy. Awesome. Ended up having my dad bring by his thumbstick for Win10 and installing that and it worked like a charm.By sunday, I'd gotten all my stuff reinstalled and was back in action. Woo!

So during the week, we crunched on trying to get the sRGB stuff isolated and ready for a PR, and also got the D3D9-kill PR rolled in to remove it from the engine.The sRGB stuff, basically implements the sRGB texture format, which lets the hardware deal with all the linearization of images for us, letting the code be cleaner, and spend less processing power to ensure textures are in the correct linear/gamma space. So same look as the current linearized renderer we have now, but less manual effort on our part to make it happen. Win-win all around.

That's nearly done now, mostly just need to get some last bits cleaned up and reorganize how the engine handles ColorF-ColorI interplay so it's a lot harder to utilize incorrect values anywhere - which has the added bonus of making the code a good deal cleaner AND more performant. So that's cool.

Had a bit of a minor delay on progress with that on friday, however, when a big ol' storm rolled through. Ended up having 2 tornados in our area, and 80mph winds where the tornados weren't. Luckily, me and my missus have awesome house-picking skills, so our house suffered a few flickering lights, but otherwise no problems, but my sister ended up losing power and had a few trees fall over and smash their fences and stuff. So saturday was mostly about helping them get that cleaned up. Everyone's fine, and apparently even with all the chaos, no one was injured in town, but it still made for a pretty hectic weekend, haha.

So yeah, with that out of the way, this week will see the finalization of the sRGB stuff and getting that rolled in. Then a few various miscellaneous improvements pulled from my RnD and the PBR branches(as well as random stuff we've spotted while working on the sRGB bits).

For this next weekend, I've got vacation happening(which I'm spending by doing a loooot of gamedev, rather than what those normies do and GO places ) so my plan is to get the new asset pipeline stuff more or less locked in, as well as prepping the PBR stuff to be finalized and ready to be PR'd. So the next week or two should be pretty fun