Author Topic: Deferred Lighting and soft shadows  (Read 68637 times)

0 Members and 1 Guest are viewing this topic.

Offline DahBlount

  • Moderator
  • 29
  • Alpine ☆ Cancer Tribulation
    • Minecraft
    • Skype
    • Steam
Re: Deferred Lighting and soft shadows
My (admittedly Intelgrated) laptop is unable to render models or skyboxes. 


Intelgrated cards can't use deferred rendering, so it's recommended for Intel iGPU users to use normal builds.
<Axem> yet still more insightful than #hard-light

<Axem> jad2.23 will just be cat videos

<DahBlount> So
<DahBlount> JAD2.2 is like that
<Axem> maybe
<Axem> it can be whatever you like!
<DahBlount> A Chocolate Sundae?
<Axem> sure

My models: GTF Gilgamesh - GTD Nuadha [Redesigning] - Ningirama [WIP] - GTG Zephyrus

 

Offline Swifty

  • 210
  • I reject your fantasy & substitute my own
Re: Deferred Lighting and soft shadows
Thanks for the patch. I'll apply it shortly.

The crash when loading Icarus the second time seems to happen on the builds included with the Blue Planet distribution packages. I don't know if it's endemic only to the deferred rendering code (since the BP builds had the deferred rendering code as well) or if it also happens to regular trunk builds. If this bug happens in trunk builds, I kind of don't feel like going out of my way to fix it.

Btw users with Intel cards shouldn't be testing these builds. They should stick with the fixed function rendering pipeline.

 

Offline AdmiralRalwood

  • 211
  • The Cthulhu programmer himself!
    • Skype
    • Steam
    • Twitter
Re: Deferred Lighting and soft shadows
Thanks for the patch. I'll apply it shortly.
Testing that it did indeed fix the issue revealed another... oddity. The flash from the closing warp effect appears to apply a shine effect to the Perseus's cockpit glass... after it's already jumped out. I didn't notice it at first because I was focused on the glowpoints, but with the patch applied, it kind of stood out. My completely uninformed guess is that it has something to do with transparent textures, but I have no clue where to start looking; thought I'd let you know about it.

The crash when loading Icarus the second time seems to happen on the builds included with the Blue Planet distribution packages. I don't know if it's endemic only to the deferred rendering code (since the BP builds had the deferred rendering code as well) or if it also happens to regular trunk builds. If this bug happens in trunk builds, I kind of don't feel like going out of my way to fix it.
...Huh. The crash does happen with trunk builds. Nevermind, Swifty. :P
Ph'nglui mglw'nafh Codethulhu GitHub wgah'nagl fhtagn.

schrödinbug (noun) - a bug that manifests itself in running software after a programmer notices that the code should never have worked in the first place.

When you gaze long into BMPMAN, BMPMAN also gazes into you.

"I am one of the best FREDders on Earth" -General Battuta

<Aesaar> literary criticism is vladimir putin

<MageKing17> "There's probably a reason the code is the way it is" is a very dangerous line of thought. :P
<MageKing17> Because the "reason" often turns out to be "nobody noticed it was wrong".
(the very next day)
<MageKing17> this ****ing code did it to me again
<MageKing17> "That doesn't really make sense to me, but I'll assume it was being done for a reason."
<MageKing17> **** ME
<MageKing17> THE REASON IS PEOPLE ARE STUPID
<MageKing17> ESPECIALLY ME

<MageKing17> God damn, I do not understand how this is breaking.
<MageKing17> Everything points to "this should work fine", and yet it's clearly not working.
<MjnMixael> 2 hours later... "God damn, how did this ever work at all?!"
(...)
<MageKing17> so
<MageKing17> more than two hours
<MageKing17> but once again we have reached the inevitable conclusion
<MageKing17> How did this code ever work in the first place!?

<@The_E> Welcome to OpenGL, where standards compliance is optional, and error reporting inconsistent

<MageKing17> It was all working perfectly until I actually tried it on an actual mission.

<IronWorks> I am useful for FSO stuff again. This is a red-letter day!
* z64555 erases "Thursday" and rewrites it in red ink

<MageKing17> TIL the entire homing code is held up by shoestrings and duct tape, basically.

 

Offline Swifty

  • 210
  • I reject your fantasy & substitute my own
Re: Deferred Lighting and soft shadows
Can you elaborate on that bug involving the Peseus's cockpit glass? Like, when the ship goes through the warp plane, the cockpit glass is still being rendered while the rest of the ship is not? That's my interpretation of what you told me. Correct me if I am wrong.

 

Offline AdmiralRalwood

  • 211
  • The Cthulhu programmer himself!
    • Skype
    • Steam
    • Twitter
Re: Deferred Lighting and soft shadows
Can you elaborate on that bug involving the Peseus's cockpit glass? Like, when the ship goes through the warp plane, the cockpit glass is still being rendered while the rest of the ship is not? That's my interpretation of what you told me. Correct me if I am wrong.
I... don't think the cockpit glass is rendered, but it's also possible I just can't see it until the flash lights it up. In my last test, I also saw the squadron logos on the Ulysses after jumping, so maybe the glass is being rendered the whole time.
Ph'nglui mglw'nafh Codethulhu GitHub wgah'nagl fhtagn.

schrödinbug (noun) - a bug that manifests itself in running software after a programmer notices that the code should never have worked in the first place.

When you gaze long into BMPMAN, BMPMAN also gazes into you.

"I am one of the best FREDders on Earth" -General Battuta

<Aesaar> literary criticism is vladimir putin

<MageKing17> "There's probably a reason the code is the way it is" is a very dangerous line of thought. :P
<MageKing17> Because the "reason" often turns out to be "nobody noticed it was wrong".
(the very next day)
<MageKing17> this ****ing code did it to me again
<MageKing17> "That doesn't really make sense to me, but I'll assume it was being done for a reason."
<MageKing17> **** ME
<MageKing17> THE REASON IS PEOPLE ARE STUPID
<MageKing17> ESPECIALLY ME

<MageKing17> God damn, I do not understand how this is breaking.
<MageKing17> Everything points to "this should work fine", and yet it's clearly not working.
<MjnMixael> 2 hours later... "God damn, how did this ever work at all?!"
(...)
<MageKing17> so
<MageKing17> more than two hours
<MageKing17> but once again we have reached the inevitable conclusion
<MageKing17> How did this code ever work in the first place!?

<@The_E> Welcome to OpenGL, where standards compliance is optional, and error reporting inconsistent

<MageKing17> It was all working perfectly until I actually tried it on an actual mission.

<IronWorks> I am useful for FSO stuff again. This is a red-letter day!
* z64555 erases "Thursday" and rewrites it in red ink

<MageKing17> TIL the entire homing code is held up by shoestrings and duct tape, basically.

 

Offline Swifty

  • 210
  • I reject your fantasy & substitute my own
Re: Deferred Lighting and soft shadows
Ohh, I think I know what's happening. And I'm not happy about it.

So, with all this new pretty stuff, one of the initial problems I had was getting clip planes working nicely. Believe it or not, whenever a ship would warp in with shadow maps enabled, my entire machine would lock up, no doubt a symptom of AMD's creaky OpenGL drivers combined with us using a questionable geometry shader extension; we're using the EXT version of geometry shaders, not the ARB version because Apple hates the OpenGL Compatibility Profile.

In any case, I'm not going to point any fingers (ALL YOU VENDORS SUCK. EXCEPT NVIDIA. YOU'RE OKAY.) but I opted for a workaround which is basically emulate the clip plane calculation in the model rendering pixel shader using pixel discards.

Therein lies the rub: I failed to realize that insignias are rendered via fixed function and that clip plane code I wrote doesn't apply to them at all.

I still don't get how AMD could allow a series of OpenGL calls to lock up an entire machine. Isn't the point of having an API like OpenGL so we have all these nice CPU hogging validation functions that prevent the GPU from doing that in the first place????

 

Offline Swifty

  • 210
  • I reject your fantasy & substitute my own
Re: Deferred Lighting and soft shadows
Another build. I pretty much did a brute force method of preventing insignias from going through warp planes. It's basically a center point test which is kind of ugly but it'll do for now before I figure out how to get generic clip planes working for non-model triangles.

Another thing to note, I killed geometry shaders for trails. It's time to put it out of it's misery.  People keep reporting flickering issues with them. And upon further scrutiny, they're not giving the apparent speedup I want. So that's gone.

Geometry shaders for particles are still in though. We save a millisecond or two rendering them as points then generating the billboard in the shader.

I also refactored more of the model rendering code. Not really of any interest to end users but for the coders, I've essentially made a parameter class for the model_render function. Instead of filling our parameters into global variables for the model rendering code to read, we basically create an class object, fill it with our desired parameters, and pass it into the model rendering code. So hopefully any future additions to the model rendering code will be much more manageable without clogging the code base with more ugly ass globals.

On a sour note, I didn't realize this rendering bug until now. Ships that have transparencies on the main hull model will have a rendering hole in their models when looking through the canopy. Modern models built properly with the "-trans" method won't have problems but legacy models will. This is because the new model rendering code I wrote sorts all submodels to be drawn by state in order to efficiently reduce the number of OpenGL state changes and increase framerate. That means hulls can be drawn before child submodels which ends up filling the z-buffer before stuff underneath the transparency is drawn. This is an annoying rendering bug and I'm kind of upset that I didn't discover this sooner.

A solution is underway though. The best solution I can think of is to figure out which triangles are considered transparent or not. The only way to accomplish this is to sample the diffuse texture while building our vertex and index buffers and see which triangles have a transparent texel at their UV coord. I'm going to have to build a transparent submodel during model load using those triangles and use that submodel for the transparency pass.

http://www.mediafire.com/download/2s5szy6xdo3s62i/shadows_11046_r2.zip
« Last Edit: October 01, 2014, 03:34:34 am by Swifty »

 

Offline Echelon9

  • Moderator
  • 210
Re: Deferred Lighting and soft shadows
...
I also refactored more of the model rendering code. Not really of any interest to end users but for the coders, I've essentially made a parameter class for the model_render function. Instead of filling our parameters into global variables for the model rendering code to read, we basically create an class object, fill it with our desired parameters, and pass it into the model rendering code. So hopefully any future additions to the model rendering code will be much more manageable without clogging the code base with more ugly ass globals.
...

YES!

 

Offline Swifty

  • 210
  • I reject your fantasy & substitute my own
Re: Deferred Lighting and soft shadows
I somehow pulled it off. Transparent triangles on the root submodel of all detail models will be separated out and drawn in a separate pass which should prevent issues of seeing the hull through them. This actually fixes a lot of legacy rendering issues involving transparent polygons so I'm kind of happy with this solution. I may later extend this solution so that any submodel, not just the root submodel, can have transparent triangles without having to use the -trans suffix.

http://www.mediafire.com/download/jzsvhm1courpqkn/shadows_11046_r3.zip

 

Offline Swifty

  • 210
  • I reject your fantasy & substitute my own
Re: Deferred Lighting and soft shadows
Whoops a change I did causes a crash if environment maps are enabled. I just made new builds with a fix.

http://www.mediafire.com/download/t5fo830a0896o2b/shadows_11046_r4.zip

 

Offline DahBlount

  • Moderator
  • 29
  • Alpine ☆ Cancer Tribulation
    • Minecraft
    • Skype
    • Steam
Re: Deferred Lighting and soft shadows
Just a heads up, but glow points seem to be universally disabled in mission and $glowpointoverride: doesn't work in the F3 lab.
<Axem> yet still more insightful than #hard-light

<Axem> jad2.23 will just be cat videos

<DahBlount> So
<DahBlount> JAD2.2 is like that
<Axem> maybe
<Axem> it can be whatever you like!
<DahBlount> A Chocolate Sundae?
<Axem> sure

My models: GTF Gilgamesh - GTD Nuadha [Redesigning] - Ningirama [WIP] - GTG Zephyrus

 

Offline Swifty

  • 210
  • I reject your fantasy & substitute my own

 

Offline zookeeper

  • *knock knock* Who's there? Poe. Poe who?
  • 210
Re: Deferred Lighting and soft shadows
hopefully there won't be too many conflicts but I'll get a patch going soon.

Anything new on that front?

 

Offline Kolgena

  • 211
Re: Deferred Lighting and soft shadows
I didn't get much time to test why or how, but the weapon selection indicators (the arrows that tell u what weapon is selected) are invisible in the latest build.

 

Offline Swifty

  • 210
  • I reject your fantasy & substitute my own
Re: Deferred Lighting and soft shadows
hopefully there won't be too many conflicts but I'll get a patch going soon.

Anything new on that front?

I tried. The patch is about 700 Kb. It's honestly simpler to just checkout the branch I have on github. Hopefully it'll apply without any problems.

[attachment kidnapped by pirates]
« Last Edit: October 29, 2014, 09:26:50 pm by Swifty »

 

Offline DahBlount

  • Moderator
  • 29
  • Alpine ☆ Cancer Tribulation
    • Minecraft
    • Skype
    • Steam
Re: Deferred Lighting and soft shadows
Have you managed to fix the following problems?

In the Ship Lab, using the alternate rendering pipeline makes the model point directly away from the viewer but the thruster graphics will rotate correctly.

In ship and weapon select screens, using 3D weapons and Ships causes the models to be rendered in a different orientation than trunk.

Some models, such as the GVB Osiris aren't rendered at all and don't show up when using the wireframe view.

Glowpoints aren't clipped through subspace portals, they just appear randomly in space.


Do you think you could adjust the way beam glow lights are cast? Currently they look too strong and overpower the diffuse map.
<Axem> yet still more insightful than #hard-light

<Axem> jad2.23 will just be cat videos

<DahBlount> So
<DahBlount> JAD2.2 is like that
<Axem> maybe
<Axem> it can be whatever you like!
<DahBlount> A Chocolate Sundae?
<Axem> sure

My models: GTF Gilgamesh - GTD Nuadha [Redesigning] - Ningirama [WIP] - GTG Zephyrus

 

Offline Swifty

  • 210
  • I reject your fantasy & substitute my own
Re: Deferred Lighting and soft shadows
I don't know. Probably? There's a reason why I ask you guys to test.

 

Offline zookeeper

  • *knock knock* Who's there? Poe. Poe who?
  • 210
Re: Deferred Lighting and soft shadows
I tried. The patch is about 700 Kb. It's honestly simpler to just checkout the branch I have on github. Hopefully it'll apply without any problems.

Didn't work (got a bunch of rejected chunks, and after hand-fixing those, plenty of compile errors).

I can't tell what you mean by your checkout suggestion.

 

Offline AdmiralRalwood

  • 211
  • The Cthulhu programmer himself!
    • Skype
    • Steam
    • Twitter
Re: Deferred Lighting and soft shadows
He's saying it's easier to grab this than to make a patch.
Ph'nglui mglw'nafh Codethulhu GitHub wgah'nagl fhtagn.

schrödinbug (noun) - a bug that manifests itself in running software after a programmer notices that the code should never have worked in the first place.

When you gaze long into BMPMAN, BMPMAN also gazes into you.

"I am one of the best FREDders on Earth" -General Battuta

<Aesaar> literary criticism is vladimir putin

<MageKing17> "There's probably a reason the code is the way it is" is a very dangerous line of thought. :P
<MageKing17> Because the "reason" often turns out to be "nobody noticed it was wrong".
(the very next day)
<MageKing17> this ****ing code did it to me again
<MageKing17> "That doesn't really make sense to me, but I'll assume it was being done for a reason."
<MageKing17> **** ME
<MageKing17> THE REASON IS PEOPLE ARE STUPID
<MageKing17> ESPECIALLY ME

<MageKing17> God damn, I do not understand how this is breaking.
<MageKing17> Everything points to "this should work fine", and yet it's clearly not working.
<MjnMixael> 2 hours later... "God damn, how did this ever work at all?!"
(...)
<MageKing17> so
<MageKing17> more than two hours
<MageKing17> but once again we have reached the inevitable conclusion
<MageKing17> How did this code ever work in the first place!?

<@The_E> Welcome to OpenGL, where standards compliance is optional, and error reporting inconsistent

<MageKing17> It was all working perfectly until I actually tried it on an actual mission.

<IronWorks> I am useful for FSO stuff again. This is a red-letter day!
* z64555 erases "Thursday" and rewrites it in red ink

<MageKing17> TIL the entire homing code is held up by shoestrings and duct tape, basically.

 

Offline zookeeper

  • *knock knock* Who's there? Poe. Poe who?
  • 210
Re: Deferred Lighting and soft shadows
He's saying it's easier to grab this than to make a patch.

I assumed he probably didn't mean that since grabbing that wouldn't seem to accomplish anything.