[2.3] Illumination features not well documented

Discussion area about developing with Ogre2 branches (2.1, 2.2 and beyond)
Post Reply
Slamy
Gnoblar
Posts: 22
Joined: Sat Mar 27, 2021 10:49 pm
Location: Bochum, Germany
x 10

[2.3] Illumination features not well documented

Post by Slamy »

At first I was unsure whether I should open a thread like this. But now I feel it's necessary.
Ogre 2.x has an issue with its documentation. Most cool features are presented to the user through the Samples and only the Samples (or presented not at all, assuming there are more features than samples)
I love learning through example code. But these don't answer more complex questions about their compatibility with each other and their feature set.
This leads to the user feeling a little bit lost on how and why to use certain features because one is forced to experiment (and fail) a lot to learn.

Here are some questions I've asked myself during the time I've used Ogre 2.x:
  • When to use Instant Radiosity and when Voxel Cone Tracing?
    Pros and Cons to compare both.
    Should I use Instant Radiosity at all, as it is older?
  • What is the difference between IrradianceVolume and IrradianceField. Why do both exist?
    The first one uses 1 sample per direction (in total 6) and the other uses small cubemaps?
  • Instant Radiosity can be used with IrradianceVolume or only with VPLs. When to choose which?
  • VCT can be used with IrradienceField or not. Pros and Cons of each Mode to choose from?
  • Local Cubemaps have the nice feature of having Diffuse GI calculated from the cubemap.
    This feature is never explained and I've discovered it by accident through the documentation of SceneManager::setAmbientLight()
    Those can even capture the Skybox and such allow to simulate the lack of officially supported Image Based Lighting.
    Can VCT or Instant Radiosity somehow make use of the Sky or a Local Cubemap to cast rays into the scene to simulate what Blender does with Eevee?
    This is one very effective feature for realistic lighting in a scene.
    I've noticed this because my scene never really looked like it would fit in my skybox. Only with the Local Cubemaps the ambience seemed to be realistic as the color tones match now.
  • Local Cubemaps and VCT seem to be exclusive to each other?
  • Why does SSAO apply to the whole image and not just the ambient term?
    Yeah I know, Forward Rendering makes it more difficult as SSAO is easier with Deferred.
    But this is still a limitation which should be communicated as SSAO feels weird when applied to diffuse lighting.
  • Should there be a feature to import Eevee IrradianceVolumes from Blender so lighting can be baked for a scene externally?
    Those are cubemaps as well so there should be a compatibility. But I do agree that is can be probably done by an external tool or a Blender Python Script.
  • Is VCT or Instant Radiosity usable for moving lights to simulate a sun which moves slowly during the day?
    Are GPU based GI solutions really the best way to go or should it be calculated asynchronously in a CPU thread?
    I could imagine that is doesn't need a high update rate for slowly moving lights.
  • When to use PccPerPixelGridPlacement? Aren't manually crafted probes more accurate most of the time?
    Sample_PccPerPixelGridPlacement feels very basic as it doesn't really explain why this feature is good and shall be used.
Please keep in mind that I'm just an ordinary user. I haven't read lots of white papers about rendering in the last years.
I just have the feeling that I have to read lots of shader code from Pbs to understand which feature works in harmony with another feature.
A illustrated manual for lighting would help a lot.

Maybe I'm missing something. I've also checked the manual of 2.3 but reading through Class documentation doesn't help a lot ot get a feeling for the engine. I hope that this text doesn't feel toxic. English is not my main language.

Kind regards,
Slamy
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4692
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1020
Contact:

Re: [2.3] Illumination features not well documented

Post by dark_sylinc »

Your questions were so good I had to write the documentation about it (IMHO Markdown version from Github just looks better). Thanks!
Local Cubemaps and VCT seem to be exclusive to each other?
They shouldn't be, but there is a lot of overlap. If you encounter major problems they could be bugs.
VCT + Per Pixel PCC uses a special path to improve reflections.
Why does SSAO apply to the whole image and not just the ambient term?
Yeah I know, Forward Rendering makes it more difficult as SSAO is easier with Deferred.
But this is still a limitation which should be communicated as SSAO feels weird when applied to diffuse lighting.
I added this question to the 2.1 FAQ
Is VCT or Instant Radiosity usable for moving lights to simulate a sun which moves slowly during the day?
VCT and IFD are the only ones that could fit this.
I suppose Instant Radiosity could do it if carefully done in a worker thread (may need modifications to avoid race conditions?) but it was never conceived that way

Cheers and thanks for the useful questions!
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4692
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1020
Contact:

Re: [2.3] Illumination features not well documented

Post by dark_sylinc »

Slamy wrote: Tue Jun 01, 2021 5:00 pm Should there be a feature to import Eevee IrradianceVolumes from Blender so lighting can be baked for a scene externally?
Probably. Irradiance Field with Depth was developed either a littler earlier than Eevee's IrradianceVolumes or around the same time.

I never looked deep into it but they Eevee's IVs and our IFDs seemed to be the same (or almost same) thing with different names.
Slamy
Gnoblar
Posts: 22
Joined: Sat Mar 27, 2021 10:49 pm
Location: Bochum, Germany
x 10

Re: [2.3] Illumination features not well documented

Post by Slamy »

dark_sylinc wrote: Wed Jun 02, 2021 10:58 pm Your questions were so good I had to write the documentation about it (IMHO
I'm impressed how fast you were able to produce this in this short time. Thank you a lot. This is something this project needed as it gives the developer an impression on what they can do. You also have illustrated it nicely with some pictures.

I've read through the whole article and these features were completly absent from my view of this project before reading it.
  • Spherical Harmonics (no examples yet. But usage is probably not that complicated as it seems)
  • The actual use of OgreCmgenToCubemap in action.
  • The fact that PCC can be used together with Instant Radiosity and VCT (I've read it on the github markdown but have forgotten it)
  • VCT allows changing light position. (Does it really? I tried it a few days ago in a short try and it brought me down to 20 fps. But maybe I shall try again.)
I still have open questions though:
  • Does the rasterized generation of IFD also take light bounces into account? Or is it just a cubemap, produced in the likes of the PCC.
Do you have a Patreon? Or is it possible to donate?
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4692
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1020
Contact:

Re: [2.3] Illumination features not well documented

Post by dark_sylinc »

Slamy wrote: Thu Jun 03, 2021 8:15 pm I'm impressed how fast you were able to produce this in this short time. Thank you a lot.
Your questions were key to write it down as they served a general guideline on what should be covered.

It also made me realize that indeed we had so many (competing) techniques even I had trouble keeping them all in my head and started to forget about some of them.

So yes, when you brought this up I was like "oh crap, he's right, and this is important"

Fortunately I had some of this stuff scattered in support emails, so I put it together in one document.
VCT allows changing light position. (Does it really? I tried it a few days ago in a short try and it brought me down to 20 fps. But maybe I shall try again.)
Yes. Performance impact will depend on GPU compute performance, voxel resolution, number of lights and bounces (and rayMarchStepScale).

On my Radeon RX 560 updates to VCT only are quite fast

Note that if you're updating both VCT + IFD the performance impact will be higher, but you can slow down the speed at which IFD updates (takes longer but doesn't tank fps as much)

Your frame rate going to 20fps sounds more like IFD than VCT. IIRC my FPS goes to 45 while updating IFD
Does the rasterized generation of IFD also take light bounces into account? Or is it just a cubemap, produced in the likes of the PCC.
I had to think this 3 times because I had it wrong. No, you're right. IFD based on rasterization does not take multiple bounces into account
Do you have a Patreon? Or is it possible to donate?
If it's < 500 usd you can send it here.
If paypal is a no-go or for bigger amounts PM me directly
Post Reply