+- Xonotic Forums (https://forums.xonotic.org)
+-- Forum: Creating & Contributing (https://forums.xonotic.org/forumdisplay.php?fid=10)
+--- Forum: Xonotic - Development (https://forums.xonotic.org/forumdisplay.php?fid=12)
+--- Thread: More Engine Suggestions - Different Lighting Handling (/showthread.php?tid=1669)
More Engine Suggestions - Different Lighting Handling - master[mind] - 03-12-2011
Before I get flak, this only applies to non dynamic(not flashing, changing, or moving) world lights. Why are they realtime? Here is my thinking, unless shadowing is handled differently, use the shadow map independent of the realtime lighting and bake the non dynamic realtime world lights into the lightmap. It will look identical(think stormkeep) but run much faster. This doesn't apply to dynamic lights such as weapons, projectiles, and blinking electrical shorts(red planted) but it will help like crazy and keep the atmosphere the author was shooting for. I am gonna look at this one tomorrow. Maybe this affects how normal maps are handled? But what about a simple cubemap to fake it? Even a low resolution realtime cube map. Only need to sample 1563 pixels to get it looking good.
RE: More Engine Suggestions - Different Lighting Handling - Lee_Stricklin - 03-14-2011
Those are real-time? No wonder shadows are so taxing. Unreal and Unreal Tournament had baked shadows on the maps over a decade ago when they came out. Finding a way to do that would seriously boost performance in Xonotic, I wonder if that's doable.
RE: More Engine Suggestions - Different Lighting Handling - master[mind] - 03-14-2011
Environment shadows are baked into the lightmap. It's the dynamic shadows from players and objects that are being rendered by realtime world light occlusion. I say, for example, the red glow from the lava in stormkeep could baked into the lightmap and the shadow handled independently as a shadow volume. Instant performance improvement. The flickering lights would not work though. They and moving lightsources are excluded. Red Planet would become playable again.
RE: More Engine Suggestions - Different Lighting Handling - noobermin - 03-20-2011
Ahem... I AGREE COMPLETELY WITH MASTERMIND, I THINK THIS IS A GREAT IDEA AND SHOULD BE IMPLEMENTED RIGHT AWAY; AND I ASSURE YOU, I AM IN NO WAY INFLUENCED IN THIS PREFERENCE WHATSOEVER.
(pssst, how did that sound man, ok?)
Shameless bump, this is a simple idea that could save me some of those precious frames in each second.
RE: More Engine Suggestions - Different Lighting Handling - SavageX - 03-21-2011
Actually you can't bake the "dynamic" lighting into the lightmap as lightmaps can be shared between several surfaces.
Also note I don't think there's a speed difference between "light surfaces, unless the shadowmap tells otherwise" and "darken surface, unless the shadowmap tells otherwise". You'd still have to setup the light (even if it only casts shadows), render the shadowmap and run all possibly affected surfaces through the pixel shader.
Also note you'd have to come up with a color value for the shadowed areas. Well, you could try to substract the light value the dynamic light would have cast in there to approximate the original lightmap before baking the dynamic light in, but the precision of the lightmap is somewhat limited and you may run into over-/underflow.
There are good reasons why lighting is the way it is.
RE: More Engine Suggestions - Different Lighting Handling - master[mind] - 03-21-2011
(03-21-2011, 02:54 AM)SavageX Wrote: Actually you can't bake the "dynamic" lighting into the lightmap as lightmaps can be shared between several surfaces.
Also note I don't think there's a speed difference between "light surfaces, unless the shadowmap tells otherwise" and "darken surface, unless the shadowmap tells otherwise". You'd still have to setup the light (even if it only casts shadows), render the shadowmap and run all possibly affected surfaces through the pixel shader.
Also note you'd have to come up with a color value for the shadowed areas. Well, you could try to substract the light value the dynamic light would have cast in there to approximate the original lightmap before baking the dynamic light in, but the precision of the lightmap is somewhat limited and you may run into over-/underflow.
There are good reasons why lighting is the way it is.
iirc, placing lights in netradiant and generating a light map will produce the same(if not better) results as a static, non-moving, changing light source. I realize surfaces share lights, but the lightmap handles that already(or should). The red glow from the lava in stormkeep could easily be in the lightmap instead. So,
The slowness of the realtime lighting comes from having to apply a non-static lightsource to relief-mapping, normals, etc. The actual shadows(when turned on or off for me) make little difference in final FPS. Most of the hit comes from having to recalculate the entire light data for all textures in a scene for each frame. Since the lightmap is baked, that only has to be calculated once. I may not have the engine concept down, but the performance speaks for itself. The actual shadows could be rendered, without color, to a texture and applied with multiply blending on the original surface, or post process with occlusion. Either way, your only checking light data on a few points on screen, not for all textures in view. Again, maybe in theory this seems shaky, but performance comparisons prove otherwise.
RE: More Engine Suggestions - Different Lighting Handling - SavageX - 03-21-2011
All I'm saying is:
- You cannot add light to the lightmap after map-compile as the light may show up in several places because several surfaces may share parts of the lightmap
- Creating the shadowmaps is a somewhat expensive operation, as it involves rendering the scene from the light's POV (albeit geometry-only). You don't save on that.
- You still need to run the very same surfaces through the pixel-shader to evaluate the shadowmap.
So personally, I'm a bit sceptical, but also am prepared to be surprised.
Quote:Again, maybe in theory this seems shaky, but performance comparisons prove otherwise.
There's a working implementation?
RE: More Engine Suggestions - Different Lighting Handling - master[mind] - 03-21-2011
(03-21-2011, 07:44 AM)SavageX Wrote: All I'm saying is:
- You cannot add light to the lightmap after map-compile as the light may show up in several places because several surfaces may share parts of the lightmap
- Creating the shadowmaps is a somewhat expensive operation, as it involves rendering the scene from the light's POV (albeit geometry-only). You don't save on that.
- You still need to run the very same surfaces through the pixel-shader to evaluate the shadowmap.
So personally, I'm a bit sceptical, but also am prepared to be surprised.
Quote:Again, maybe in theory this seems shaky, but performance comparisons prove otherwise.
There's a working implementation?
The lights would be compiled with the map. Instead of placing a realtime world light, the light would be added and compiled in netradiant and a "shadow" object would be added from which shadows would be rendered. No lighting required.
There isn't a working implementation, I'm just comparing fps difference between shadows on and off in game. This would be handled completely differently than the current shadow method(occlusion).
See, the shadows would be...traced maybe? off the source against scene objects on a low resolution(depending on the blur desired on the shadow) then trilinear upscale and multiply blend. You just add the shadow as black. For quality, one could apply a simple blur to the upscaled image, maybe just use the current HDR blur. I would think that would work better for realtime shadows than requiring a world light and occluding out the shadow portion. It's the light that really hurts performance.
RE: More Engine Suggestions - Different Lighting Handling - rainerzufalldererste - 03-30-2011
Another thing that would be great:
Improve the performance of snow or rain
It totally kills the FPS
RE: More Engine Suggestions - Different Lighting Handling - Friskydingo - 03-30-2011
You are certainly right!
But how would one make non-realtime snow and rain effects? Would you resort to having a set of sequenced animated GIF's placed in the air?
RE: More Engine Suggestions - Different Lighting Handling - master[mind] - 03-31-2011
(03-30-2011, 03:15 PM)Friskydingo Wrote: You are certainly right!
But how would one make non-realtime snow and rain effects? Would you resort to having a set of sequenced animated GIF's placed in the air?
That could just be a post process sprite blit. The zBuffer provides depth cutoff information.
RE: More Engine Suggestions - Different Lighting Handling - noobermin - 03-31-2011
master[mind], I'm not too keen on how difficult this would be to implement it, but how about you attempt a demonstration (make a branch) and see how it fares? Do you have the time?
RE: More Engine Suggestions - Different Lighting Handling - master[mind] - 04-01-2011
Yeah, I did branch recently, I just haven't gotten around to working on it yet...I have a feeling, I have to write the entire shadow handling to get shadow volumes working...
RE: More Engine Suggestions - Different Lighting Handling - Morphed - 04-04-2011
(03-21-2011, 07:44 AM)SavageX Wrote: All I'm saying is:
- You cannot add light to the lightmap after map-compile as the light may show up in several places because several surfaces may share parts of the lightmap
how is that even possible ? how q3map2 knows that several places will have same lightining ? doesnt it need uvmap already done before baking ?