New Lighting

Remember it never hurts to ask, but you might not get it.
User avatar
Marscaleb
Posts: 83
Joined: Sat Jun 25, 2016 12:57 pm
Location: California or Utah
Gender: None specified
Contact:

New Lighting

Postby Marscaleb » Tue Sep 05, 2017 11:07 pm

So, this is a feature I must admit I really do not expect to get added, since I'm fairly sure it would simply require way too much work and overhaul to the engine. But I thought, well, I might as well mention it just in case it isn't as big of a thing as I thought.

Static lighting.

The dynamic lights in here are nice, and I love the idea of using them to light up an otherwise dark area. But dynamic lights present two problems. One, they can be turned off, and if I design a level that expects the player to see only by way of dynamic lights, well that's gonna be a problem. Two, there is a performance barrier if I go too crazy with them. Some folks might be playing on weaker computers, or maybe I want a dreamcast version.
If I had static lighting, I could go overboard with much more complex lights and not worry about performance at game time, plus they really wouldn't need to be something that can be switched off, or at the very least, people are more likely to leave them on since they don't change the experience of regular doom.

Of course, this feature brings with it a host of issues in implementing it.
I don't know anything about the fundamental methods of lighting in the engine, so I don't know how to handle lighting data nor rendering. I thought at first that maybe some simple static lights could be created just as dynamic lights are, but they just get calculated once and thus don't add any overhead to gameplay. But as I thought about it I began to suspect that the way lighting works doesn't allow for that to be a possibility.

As for how things work for editing, well obviously this would require a UDMF map format. That could allow a given surface to store some lighting data. A full-on light-map would probably be unrealistic, but lightmaps could be saved in a separate file, or possibly even added into the same wad as the level, and map file could store data to identify what lightmap data to use, and what resolution of lightap to render for that surface. Oh, and if a given surface should calculate its lighting according to a given tag/sector/line being active, like a door being open or a lift being lowered.
This still leaves the question of specifying when lightmaps need to be rendered. I thought at first the engine could check for them and build them when the game starts. But this would require either that they are built before every game session (uhg) or there would need to be some way for the engine to tell that the current lightmap data is out of date. But it can't just compare the time it was last rendered to the last time the file was modified, because then any slight change to a wad would result in lightmaps being rendered again, even if the map wasn't altered. I really can't think of a way to handle this without having a completely separate program that renders and saves all the lighting.

Well... That's my crazy thought. I don't think it's gonna happen but I wanted to get it off my chest.

EDIT: To be fair, I'd probably be happier with Doom64-style gradient color lighting; this was just one of those thoughts I had to get out because it was bugging me.

User avatar
Coraline
Site Admin
Posts: 736
Joined: Fri Jun 08, 2012 11:22 am
Gender: Female
Contact:

Re: New Lighting

Postby Coraline » Mon Sep 11, 2017 1:32 pm

I think static lightmaps are a good idea, and I know at one point EDGE had code for it:


Code: Select all

static void SetupLightMap(lighting_model_e model)
{
   for (i=0; i < 256; i++)
   {
      // Approximation of standard Doom lighting:
      // (based on side-by-side comparison)
      //    [0,72] --> [0,16]
      //    [72,112] --> [16,56]
      //    [112,255] --> [56,255]

      if (i <= 72)
         rgl_light_map[i] = i * 16 / 72;
      else if (i <= 112)
         rgl_light_map[i] = 16 + (i - 72) * 40 / 40;
      else if (i < 255)
         rgl_light_map[i] = 56 + (i - 112) * 200 / 144;
      else
         rgl_light_map[i] = 255;
   }
}


There exists some code as well to handle them -- I'll look into it ;)
\(סּںסּَ` )/ۜ


Return to “Feature Suggestions”

Who is online

Users browsing this forum: No registered users and 1 guest