dynamic light problem on lightmapped alpha-blended brushes about quake3e HOT 12 OPEN

When I'm decided to backport ARB lighting, in frst order I'm implemented simple ProjectDlightTexture() replacement (i.e. with keeping multi-stage lighting) but it worked about 3 times slower than original lighting - which were simply unacceptable counting that it caused noticeable fps drops, and there were no way to avoid that because of too many API calls.

Current code works near-perfect with stock maps and most of the custom maps and it works faster than original lighting - which is more than enough for a real gaming client (what this project aimed all the time), not yet another tech demo with "do it at any framerate cost"

from quake3e.

Pretty sure this is noticed in my fork for ET as well which has more maps with that type of terrain.

from quake3e.

It works as deferred pass and tries to extract only single but most appropriate shader stage for lighting - thus, works fast. So this is an expected behavior.
Also, this maps lacks most of the terrain normals so engine is forced to regenerate them to make lighting work at all.
In general, lighting works good even for this map so I wouldn't consider it as a problem

from quake3e.

Sorry to hear that. I would consider this as quite essential for dynamic light. I guess someone else will have to address it then. Thanks for the response.

from quake3e.

Don't get me wrong. I am very impressed by your project and the quality of the outcome both concerning performance and the visuals. your solution surpases all other attempts I know of. I just thought that a small tweak maybe even with a cvar allowing two stage lighting would make your solution also fit as a basis for modding on q3 knowadays. I am not interested in just another slow tech demo at all. There are enough attempts like that out there and they all are unusable and worse than yours. I think for the two stage alpha blend it would just be one pass more using the alpha value and one-minus-alpha to scale the color buffer values for the two light passes. This would make q3e really the multi purpose replacement for q3. Just my two cents. Thanks a lot anyway for your great work!

from quake3e.

Please don't judge a game only by FPS. I mean, I don't want to rain on one's parade, and maybe I will make myself unpopular now, but with Q3e I have some notable microstutter, sporadic hitches/jerks and all the weird glitches vQ3A had. Even after twaeking the usual cvars (r_swapinterval etc.). Thats why 1.32b code was optimized (for nearly 20 years now)!

At ioquake they spent a lot of time to get rid of all those anoying stuff. So if you guys speak about all the 'tech demo' games what do you compare with what? What 'tech demos' do you mean? What does your test environment look like? Nowadays I always have 125 FPS on q3dm1 even with Q3A v 1.27 :)
Imo, comparisons with stock Q3a maps are pointless, even more regarding FPS. What are your test maps? tvy-bench, lun3dm5? Even those maps weren't made for 2019!

BTW, is there any chance to enable renderer2? Or do you only talk/compare the CPU renderer(s).

@coroner-gss, are you THE coroner (TCE, CQB)? If you are this coroner than I'm sure you and your team are able to make an even better renderer, but this time, please don't go closed source...
Anyways, I agree with you the multi-stage lightning is still a big problem...
2013 I opened a ticket on bugzilla https://bugzilla.icculus.org/show_bug.cgi?id=6058. Eugene C. (ec) was so kind to make a patch to partially fix the multilayered textures, unfortunately not for terrain you are talking about.
However, probably this could be a good starting point for a new RENDERER 3 by coroner!
Again, thanks for the patch Eugene!

from quake3e.

Open a new issue to discuss micro-stuttering and whatnot. Don't be turbo autistic about it.

from quake3e.

@KuehnhammerTobias renderer2 is an ioquake3 thing, even if the source is included here, it's not really something for this project as it contains no enhancement to performance over the existing. Plus, the two projects have different renderer APIs between engine<>rend, which means it still needs a new compile and separate version of each "r2" to function. Q3e has better performance overall than ioquake3 does, even in vanilla mode. and afaik they do not focus on pure optimizations anyway. Hence why this project even exists. If there's new microstutter it's likely because of bug or that you're using Windows 10 and combination of factors possibly outside of game. Keep in mind original game has some hacks built into vid drivers specifically for the original release which may not be applied in cases of alternate engines etc.

from quake3e.

@ensiform You know I always appreciate your input and probably even this time you're right. I only think that terms like "do it at any framerate cost" or "Q3e has better performance overall than ioquake3" are some kind of vague/unprecise or generalizing. I'm not really much into fixing micro-stutter in Q3e, if I remember correctly it heavily depends on DirectSound, mouse input and many other little nasty things, I really don't remember anymore. Thats why we can't open one issue to adress all possible things that can cause micro-stutter (in the past), maybe someone with a lot of time should search through bugzilla or ETLegacy issue tracker...
I simply thought argumenting against a reasonable suggestion (by coroner) by just judging a game by FPS is weird.
I was just interested how you guys do tests like speed/FPS comparisons to come to conclusions like this game is a "tech demo" and this game not? He mentioned a well known bug, not a feature imo.
Well, I am no maintainer, and it's up to ec to decide!
Yeah, renderer2 wasn't updated, so renderer2 is of no interest for Q3e?

from quake3e.

@ensiform Thanks to remind me about the renderer1 hacks. I did the 'renaming-thing', now I have less micro-stutter, and for all the FPS freaks I have 1000 FPS or so with q3a stock maps! Sorry for the intervention, I think I'm really too old now, (and honestly I don't really care much about r1 anymore), I completely forgot about the driver hacks. Will the renaming also work for ETe?
Thanks!

from quake3e.

Entirely possible, but it's not recommended for either of them unless absolutely necessary. It can break extension detection.

from quake3e.

What I referred to as tech demo with regard to FPS is something like Xreal and all its derivatives. I am not talking about microstutter but acceptable FPS on slightly aged hardware. Back then I was blown away when reading about Xreal and had really high hopes, but at least on my not so recent rig that renderer is useless. For TC(E) I was hoping for either a faster renderer with decent additive dynamic light or for something feature complete reaching the rendering capabilities of something like COD4/5, most importantly cascaded shadow maps, at a performance equal to those also more than 10 year old engines. Xreals shadowmapping is slow, at least for me. I guess that is the reason why they didn't use it as showcase even in their own final ETXreal release.

Q3e seems to reach the goal of a really fast renderer with decent dynamic light except for this small issue with the terrain. I consider this very valuable because it is some feature complete project and not something stucked halfway. Thus with the terrain two stage lighting fixed Q3e (and then maybe also ETe) these projects seem like perfect replacements of the stock engines from my perspective.

Ioquake3's renderer 2 is also great, at least the CSM, however, dynamic light has the same issue with terrain (as mentioned above). But sadly to my knowledge even more issues, e.g., with character/object lighting where the most recent dynamic light just overides the lightgrid lighting direction causing very unnatural artifacts. Sad that nobody ever picked that development up, or am I wrong? OpenJK?

Happy to further discuss these of topic things somewhere else. Could it be possible that some developers are joining to finish Ioquake3's renderer in the spirit of Q3e without getting lost in more and more features? Babysteps with finished and working features.

Anyway, here I just wanted to express how much I like this Q3e project and even how much more so if the terrain issue could be fixed :). Still hoping.

P.s.: @KuehnhammerTobias, yes I am Coroner from TC(E).

from quake3e.