Leaderboard

Hi this is Graymans son My father was a poet, a painter, a writer, and a giant nerd. He studied nuclear physics, aerospace engineering, and AI. But all he really wanted to do was play video games. He recently lost a very long war with Cancer. My dad has a little plaque you all sent him hanging on the wall next to handprints from his grandchildren. Whenever my children would call him he'd talk to them about "his boring video game stuff" according to my 8 year old... who never really understood why Grayman didn't like Pokemon as much as he did. I found a file on his computer stating that the last few levels he was working on 95%, 95%, and 50% finished. He also said working with another dev would take up too much time that he wanted to spend with his family instead. To be fair I worked with my father my entire life on random things (including Doom mods back in the day) and he never thought anything was finished. So I'd personally consider the two 95% missions to basically be done. If whoever he sent them to to Beta test wanted to share them with the development team I don't think he'd really mind and you shouldn't feel guilty if you do. I'll leave that up to you guys, but I will not be uploading them and they should not be posted publicly. The final mission will remain unfinished though. I will mention that it was going to be pretty damn good from what I read in his notes. He did ask that two levels that weren't related to the Steele missions do get uploaded to the abandoned level archive. I am in the process of doing that now. Thanks

v 0.82 .. the "I think I finally got PBR working right" update (knock on wood) ambient surfaces with real speculars do more glossy PBRs now capped the distribution term in specular PBR flow to keep it from barfing white specklies everywhere with glossy outputs, and to help control how bright glossy shines are in lighting got rid of the "divide by Pi" parts in PBR flow, because we're not dividing diffuse color by Pi (instead, dividing by " 4 * NdotV * NdotL" which seems to give better results corrected visibility specular PBR term to use NdotL like it should (not sure how I missed this before) renamed BRDF_SPECULAR to PBR_LIGHTING (PBR is what we're doing, BRDF is how we're doing it) added #define PBR_REALISTIC which (when set to 1) will keep the multipliers usually used to tweak outputs (like speculars) to 1.0 so pure PBR outputs are shown without anything tweaking them after-the-fact (the idea of this is to maybe tweak the PBR outputs in the future to "enhance" the lighting to be more immersive / game-like, but still have a way to quickly switch to pure PBR. PBR is supposed to be a realistic lighting model, so mucking with it after-the-fact can alter the realism). added #define PBR_FAKESPEC_IS_REALSPEC to flip between fake specs acting like real spec lights of diffuse boost in PBR (in PBR, they do better acting like real specular lights, because PBR does direct rimlighting and rimshining w/o having to resort to extra functions. But, when you turn the fake specs into diffuse boosts, a lot of what PBR does disappears w/o much diffuse boost to show for it..unless you muck with the outputs post-PBR.. which defeats the purpose of PBR.. to have algorithms do it all w/o having to mess with too many extra variables). finally understood the whole "conservation of energy" thing, and added ks/kd ratios to balance diffuse vs specular. It's basically taking the specular PBR fresnel term and using it to determine how much light is reflected (specular) vs refracted (diffuse) based on your viewing angle, surface, etc. fake spec maps are used in PBR as speculars, but for roughness maps I went with grayscale diffuse textures. This lets them have full 0 to 1 range instead of the curved range that fake specs do. Basically, I read Epic Game's white paper on how they put PBR into UE4, and they made decisions to just keep using Lambertian Diffuse like they had been doing, and just focus on keeping it simple and where the algorithms they chose do all the work.. as opposed to shader devs or artists having to micro-manage tons of variables to tweak everything. This radically changed my thinking about PBR, and I realized it can be as simple or as complex as folks want it to be. So, I ignored a various diffuse lighting models and just kept what we had, but modified with energy conservation (kd). I realized Torrence-Cook is the main PBR model most folks use, but they swap out various sub-algorithms in it. Once I wrapped my head around that, it made more sense. I switched to using the most common algorithms tuts used, and just kept it simple to get it working. I then figured out the whole "conservation of energy" thing, b/c the ks/kd thing was confusing me for a while. (LearnOpenGL's tutorial was confusing, b/c they kept swapping back-n-forth between code and math.. and I do better when I see just a cohesive chunk of code showing how things are done). Anyways... I got it going. The goal (in my mind was) Get the damn thing working properly If it's working right, we shouldn't have to use any post-PBR multipliers to tweak speculars and brightness and other junk. The PBR algorithms should handle all of that, so we don't waste time mucking around with that. (I kept the multipliers in the code, but they're all set to 1.0 for PBR paths.. so we see a pure PBR output experience.) I had to make a few hackish decisions to get things to look decent, like clamping the distribution term (it was barfing white specks all over the place). Also, not dividing by Pi... The Pi division was confusing the heck out of me...then I came across some forum post (can't remember where) that the person said in the Lambertian Lighting Model, you divide diffuse color by pi. But, it's just assumed that light colors in the game engine piped out to shaders are already divided by pi, so nobody divides diffuse color by pi in shaders. Um.. okay? *head-scratching* But, the PBR code I was looking at (eg: Urdo3D, LearnOpenGL) were dividing the specular PBR output by Pi (learn open gl had one of the spec sub-terms also divide by Pi). I realized they were doing this, b/c it would balance out diffuse color dividing by Pi. But, we don't divide TDM diffuse by Pi. It's a bad assumption to make w/o knowing for sure. All I did was look at the results from the shaders.. if I divided diffuse color by Pi, it got really dark. So, I removed the divide by pi from the specular PBR output, too. Instead, I switched it over to a " / 4 * NdotV * NdotL" that I noticed other folks doing. This worked well to tone the final spec output without having to do Pi. (this is the big PITA about all of this.. it's like herding cats. Everyone's doing their own version of it that works for them, but they don't explain why they do certain things. No code comments or what-not in the code, and white-paper-like-discussions that hit my level of incompetence pretty fast. So, trying to mix-n-match code or using one project's code into ours can lead to funky results w/o knowing why.) Anyways... Issues: Chunky texture seams some surfaces have an ugly, chunky texture situation going on, and not sure why. When I switch PBR off, it resolves itself. So, it's something with the PBR pipeline. Something is acting like a cap or limiter or something to create the stark seams between parts. I tested various terms in the PBR, and these chunkies still occurred. Maybe it's my crappy HD 4600 doing something funky? I don't know. Only certain textures do it. If anyone can verify whether they're also having the issue, I'll be able to know if it's a code issue or gfx driver issue. Dark Spot under Player Ground specular was looking nice... before I got kD (diffuse refractive ratio) built into diffuse. Now there's a dark spot under the player. I know it's the kD value, b/c when I remove that from diffuse lighting equation, the dark spot goes away and ground speculars look better. Not sure what's up with this. I'll have to experiment, or try other formulas or something. I don't know. Speculars get Bright up near walls in Ambient PBR helps ambient specs look better, but they exacerbate the brightness of speculars as you get closer to walls more-so than non-PBR spec. Ambient specular was always a balancing act trying to make it look good both indoors and outdoors, b/c it's controlled mainly by the light color the level designer uses for the room/area. So, if they want brighter specs outside, they use a brighter light color. Darker inside, use a darker color. For PBR, I use the distribution clamp value to try to control how bright the shine is. I set it lower for ambient specs than direct specs. But, we still get cases like this, where looking up a wall in a dark area (Alberic's Curse, the inner church) has an out-of-place shine. The PBR has rim light & rim shine baked into its algorithms, so it does this super-brighting on its own. This would be a situation where spec & roughness maps would control it I guess, so maybe my PBR pipeline isn't using them well enough. Not sure. Screenshot Compares Here's some before & afters with non-PBR vs. PBR. It doesn't make a dramatic difference in scene-wide lighting. It mostly enhances things you're looking closely at by making the lighting act more realistically. PBR does it's own rim lighting and rim shine for direct lighting. (not so much for ambient lighting, so kept that as it's own light in ambient). So, in direct lighting, when PBR is on, the rim light & rim shine turn off to let PBR handle it all. Surfaces with real speculars treat PBR more like glossiness while fake specs do more rough / hazy specular. PBR makes light form around objects more realistically. The metal objects use real speculars, so they do more of a glossy shine instead of hazy/rough shine. The player lantern shines off the metals, reflecting light back. The falloff of the light adds more body/depth to the pipes & boiler. The window light also highlights the boiler more... PBR is handling all the direct rim light / rim shine here. So, no fiddling with variables to try to "get it right". The PBR algorithms have the smarts built into them. PBR enhances the lighting along the camera view. The metal lamp post pops out, because it's using specular as more of a gloss. But, the overall lighting tone has changed. The lighting on the posts to the left follows the falloff of the light source better, so instead of both posts being evenly lit, one is a bit brighter than the other. Mission 2, the weeping statue ... PBR helps the light follow the countours better. The stairs stand-out here, b/c PBR works best on things with more contours. It adds better light falloff and specular shine. The flip back-n-forth is my non-PBR shader vs PBR shader. Since my non-PBR pipe adds fake specs to diffuse brightness, it punches up colors. Since my PBR pipeline is set to do fake specs like real spec lights intead of adding them to diffuse brightness, colors seem to have toned down a bit while lighting has punched up a bit. I can post screenshots, but one of the things that makes PBR nice is how it looks when you move. The light just contours around things better. There are spots where you look straight up and go "why is that wood building super shiny?" But, that's b/c I'm doing the best I can with what I have right now. glprogs.stages.interaction.082.zip

Grayman repeatedly said that if he does not have time to release these two FMs, then the story of William Steele ends on the fifth mission. I specifically asked him about it in March and here is his answer: So unless anyone wants to ignore his will, WS6 and WS7 are dead too.

My condolences to you and your family. Your father was a great coder, mission author, and a great overall human being. (He seemed to act like our grampa here too, and always called TDM AI his children.) He had labelled "William Steele 6" as "Release Candidate 2" so that one is probably unquestionably eligible for release given grayman's extremely high standards. I will open a discussion on this internally and I have copies of the last missions added to the beta forum.

Hello grayson welcome to this community and I'm pretty sure that i'm not alone in saying that all here respected and admired your father and his work, my condolences and all the best for you and your family. stgatilov and OrbWeaver thanks for the clarification and sorry for being paranoid was just lost in translation my bad.

I interpret "no archiving 'as is'" to mean that Grayman was not going to provide unfinished beta versions to be released after his death — not that he wanted to retroactively remove the already-released missions.

Of course, it is only about the two missions which were not released. Nobody ever talked about removing already released FMs. I have added the question to my previous post.

I just wanted to share the sad news that grayman, long time developer and the author of the William Steele series, passed away recently after a battle with cancer. He was a pleasure to work with and did more for this mod than most people will ever realize. I am glad that his missions will live on.

Yes, it's source code so you need to rebuild. The code doesn't end up in the installation directory because it gets compiled into machine code and written into the "darkradiant" binary executable and its shared libraries.

Oh Mighty Builder, Please carve Graymans name in your anvil, so his name and actions will always be remembered. During your builds and constructions.

As an amusing aside to this, does anyone remember those little "find the differences between these two images" puzzles that would appear in the newspaper or various magazines at times? I learned that you could do the eye-crossing maneuver on those two images and easily spot the differences in seconds. I would try to defocus my eyes to get the two images to "overlap" thus making a third combined image where the differences kind of shimmered and stood out so you could see them really easily. I never found any use for this other than nifty childish party-trick, but I thought I'd share.

Grayman was a legendary presence. I am sure that he will be missed both here and in the real world. I cannot express enough thanks to him and enough condolences to his friends and family who will undoubtedly miss him deeply. Salute to the best of the best!

The migration to new FM database is over. FM additions and updates can no go as usual.