Search In
• More options...
Find results that contain...
Find results in...

# Why not 1 / (r^2) ??

## Recommended Posts

I don't understand why John doesn't implement proper inverse squared light falloff. Maybe that extra multiplication step really makes a difference when you're trying to do lighting in real time. I'm just wondering cuz i know that in 3d Studio Max an object will look much more realistic when lit under 1/(r^2) light decay rather than 1/r.

This is one aspect of betting graphic realism for future games. And I really want to see something like that fractal LOD idea that Zaldron mentioned a ways back. Shapes could be defined by some sort of mathematical ideal and the shapes would scale in geometric accuracy depending on resolution(how close or far away the player is).

Actually, this is how the curve stuff works in Quake3 right? The engine does dynamic LOD with polys to fit them to the equation based curve, depending on where the player is, right?
What about the morphing geometry? What's that called? Like those two pulsating tubes in that one deathmatch level.

Yes, there´s LOD on the curves. It´s not too exploited in Quake3, since polys aren´t the big issue, multitexturing was always the hardest step of Quake engines rendering.

Turn off/on lightmap lighting and you´ll note *HUGE* differencies.

OK. Here´s the problem with 1/RR light falloff. First than all, it´s WAY too dark. Even the greatest animators and modelers in respected game and movie companies don´t use it too often.

Imagine, at 1 "game unit" the lighting value is 1. What does this mean? At 1 meter the textures will look just like they must look with lighting turned off. At closer values, for example 0.5, you´ll get 4 as the intensity. This is represented by oversaturing the colors, resulting in hot white.
At 2 meters, the intensity is just 0.25, at 3 meters, 0,111 (periodical).

Lights get too dark. Since lighting is based on games units, and these units are always way smaller than 1 meter, things loose intensity really fast, wich means you have to place super-strong lights, that we´ll turn white every goddamn brush near them.

1/rr is slower than the regular system : angle falloff (only logical on game with lightmaps). But that´s not the point, the point is that these kind of lights are AMAZINGLY dark.

So, you´ll say, HANG ON! Hey, that´s like the reality, and I can see my fucking hand!
Remember that the tech can´t allow us to make light reflection. Since this feature is discarded, for now, making darker light systems will mean completely dark enviroments.

Instead, making the system less realistic, by the equation 1/aR, where "R" is radius and "a" a coeficient designed to meet id desires, they can "simulate" radiosity in the game. The simulation doesn´t get as cool as plain-old RAD from the Quake engines, but I´m willing to discard that feature for one real-time lighting pipeline. And I guess everyone here does too...

I doubt that they're using 1/aR falloff, I would assume that they're using 1/(r^a) where a is a number between 1 and 2.

Mmh, could be too, altough it would be closer to 1 than 2. Anyway, every function that remotely/uniformely decays might do the trick.
The problem with 1/r^whatever is that it looks shit in the borders when several lighs are placed pretty much in the same spot. The problem is explained in one of Carmack´s plans, and it could look as awful as those "16-color"esque lightmaps of the Dark engine (Thief and SS2) that sometimes appeared when placing big lights in ever bigger enviroments.
A uniform falloff (1/aR) would not be so evident in this aspect, but it would look less realistic...

The pulsating tubes are just NURBSs with a special shader. The shader code for the water, slime and lava textures in Q3A ALSO specifies the amount of noise applied over the surface. While most shaders are just a couple of instructions on how, when and where paste textures to make kickass composites, this ones actually modify the 3D geometry.

Zaldron said:

Mmh, could be too, altough it would be closer to 1 than 2. Anyway, every function that remotely/uniformely decays might do the trick.
The problem with 1/r^whatever is that it looks shit in the borders when several lighs are placed pretty much in the same spot. The problem is explained in one of Carmack´s plans, and it could look as awful as those "16-color"esque lightmaps of the Dark engine (Thief and SS2) that sometimes appeared when placing big lights in ever bigger enviroments.
A uniform falloff (1/aR) would not be so evident in this aspect, but it would look less realistic...

1/aR would still have the banding if the lights were placed in the same spot... Carmack wants 64-bit color so stuff doesn't have to be rounded off as much.

The banding would be much obvious on 1/r^a since the outer rings are way bigger than those in the center.

How about when a wall gets hit with light (we'll work with doom 2 numbers), lets say, 180 light, it emits a light out based on it's grey scale value. So if it averages out to lets say rgb(200,200,200) it acts as a light source for (200/255)% of the light. This can be broken down further into the actual shades of walls. For instance when you enter a red room, everything will be a little more red because of the reflection.

Finally I question that 1/(r^2) formula. Think about how far away stars are. pretty damn far, and sometimes they are still pretty damn bright. And that far, far exceeds the bright. Atmosphere doesn't absorb much more light than space does (space has particles in it too).
How long until THINGS will cause shadows.. maybe they do and I didn't pay enough attention to the video... anyway.

Everything causes shadows. Put the marine next to a light, and his nose will cast a big shadow across enemies and the level.

Linguica said:

1/aR would still have the banding if the lights were placed in the same spot... Carmack wants 64-bit color so stuff doesn't have to be rounded off as much.

Can video cards or our monitors even produce 64 bit color?

Well thanks for the info Zaldron and everyone else. I just finished my technical paper and wanted to post it but I didn't anticipate explaining friggin' sprites and triangles for 10 pages to my professor who doesn't know shit about computer graphics. oh well, I kinda rushed it too and left out some stuff that I knew he wouldn't know was missing. whatever....

CRiZ said:

Can video cards or our monitors even produce 64 bit color?

64 bit framebuffers, not color depth. 32 bits would be used for color, while the other bits are used to store additional data in order to reduce the errors while processing final destination color of each pixel.
For example, a bunch of multitexturing would produce errors since you´re limited to integer RGB values, while using this extra bits you can store this extra data and finally output a better result.

Zaldron said:

Everything causes shadows. Put the marine next to a light, and his nose will cast a big shadow across enemies and the level.

will it take into account where the light is?
so that if it is horizontal and a wall is very far away you can cast an eight foot long shadow with your shnoz?

CRiZ said:

Can video cards or our monitors even produce 64 bit color?

Is there even a point?

As far as I know, human eyes can't see above what they call 24-bit anyways.