[Serana]

 gpz, on 14 February 2022 - 11:42 PM, said:

It must be connected to the raytracing, since in traditional calculation the "lightsource" is not a thing for the hardware. A lightsource is just some additional vectors that contribute to the color of the pixel. For the hardware they are just some more program methods we ask to execute, only we humans call them light sources. But at ray-tracing, a light source is an important thing, because that is the origin of the ray.

It is fully linked to raytracing: https://developer.nv...xdi/get-started
Requirements are Windows 10 or later, Direct3D 12 Raytracing tier 1 or 1.1 or Vulkan with support for the raytracing extensions (GPU nVidia RTX2x00 or later, AMD Radeon RX6x00 or later).

The MonoGame library only supports Direct3D 11... but not every features of Direct3D 11 is available through MonoGame currently. Direct3D 12 needs a big rewriting of the code in MonoGame... and more recent GPUs (for nVidia, minimum is GTX4x0).
So we can expect that will never happen...

[gpz]

While MonoGame runs on DX11, actually it only supports the feature set of DX10 as a maximum. Not even BC7 textures or structured uniform buffers, multithreaded resource updates or rendering (via command lists) are available. So they would need to rewrite the code even to support DX11. :)

[Genma Saotome]

Re-write the code is certainly an unhappy phrase.

[FS.E652 091]

 Genma Saotome, on 15 February 2022 - 11:40 AM, said:

Re-write the code is certainly an unhappy phrase.

Certainly it will be unhappy because you have to waste time again, but .. let's think about it ... if rewriting the code also involves new graphics improvements, is it worth it? in my opinion yes .. because in your roadmap, many things are clear, such as light cones, and much more .. all this will require a great job of code editing, and therefore, it is an added milestone that could bring to many satisfactions

[Genma Saotome]

 FS.E652 091, on 17 February 2022 - 10:34 AM, said:

Certainly it will be unhappy because you have to waste time again, but .. let's think about it ... if rewriting the code also involves new graphics improvements, is it worth it? in my opinion yes ....

My comment was about the probability that it will occur, not the value that would be obtained.

[R H Steele]

I remember the first time I used OR when I joined ET and learned of it...was something like version 8000 and something...at that time the probability that what we are using now seemed very remote...just saying...ya never know.

[gpz]

During the rewriting of the lights handling code I noticed, that the current headlight shading is quite unrealistic. Let me show you two pictures for comparision. (I hope the pictures will appear for everyone.)

The original shader used

• linear distance range attenuation (1 - distance / range), and
  
• fully-lit pixels within the range (HLSL method step(0, projection) – means either 0 or 1), not counting the cone attenuation around the light cone edges.

http://www.kepfeltoltes.eu/images/2022/02/18/173Spot_linear_trim.png

In contrast, the PBR method for handling spot lights would be

• inverse-squared distance range attenuation (1 / distance²), which is actually how the light attenuates in real world, and
  
• proportionally lit pixels within the range, calculating how much the surface is perpendicular to the light direction (HLSL method clamp(projection, 0, 1) – means proportional within 0 and 1)

http://www.kepfeltoltes.eu/images/2022/02/18/466Spot_inverse_sqared_tr.png

Did you guys notice this, and what do you think about it?

[Niknak]

The scene shown in the 2nd illustration looks a lot more realistic to me.

[gdineshnathan]

 gpz, on 18 February 2022 - 12:44 AM, said:

Did you guys notice this, and what do you think about it?

It looks amazing to me. Can we expect this change to be released any sooner?

[gpz]

My current goal is to implement glTF and its lights extension, the "study" shown here is just a side effect.