duzenko

Could you commit that in svn then please?

That's what I've been wondering recently as well Why not merge nearby ambient lights into one mega-light? We already use textures for projection falloff. It makes perfect sense to slap a few lights into a single texture and voila.

I took a quick look at @MirceaKitsune's test map While I generally retain my entity vs light LOD opinion, at the same time I can see some merit in per-light LODing as well This particular test map seems to include many small entities (details) which can be tedious to manually mark one-by-one I.e. 7 lights vs 469 entities I don't think I'll be actually hiding lights but maybe skipping some interactions and/or bulk-hide entities grouped by light Still, @MirceaKitsune how did you imagine this? You didn't think scenes like this will actually turn off big nearby lights?

And how did you test these files? Is there a core material that will use them?

Congratulations, you have been the first one to discover this secret area! :) I'm pretty sure the shaders expect GL_COMPRESSED_RG_RGTC2 while GL_COMPRESSED_LUMINANCE_ALPHA_LATC2_EXT is something we'd want to drop but I don't know if we already have any ATI2 assets to convert first Disable bindless textures and enable the normal compression cvar? What do you mean? Our on-the-fly normal compression does just that - it uploads textures in RGTC2 and the shaders do reconstruct the Z component

I'll answer this if you don't mind 1, 2, 3, 6 happen on CPU and 5, 8, 9 on GPU, so they don't play the zero sum game together But see my post a few pages back - it's cheap enough to draw a distant light when it just touches a couple of triangles of wall brush - agree? It's been reiterated many times now in this thread that a light is only as expensive as the entity models it's touching You should worry about entities first. A very good point The only heavy street scene I found in my quick fly over in TPW was inside tree gardens, caused by many transparent tree leave surfaces overdrawing up close.

@peter_spySorry for interference, but I think that's the kind of language that can get you in trouble in this forums The silent committee is watching you I personally don't mind a little internet drama, but better me try to warn you than one day you just wake up and find out you're banned. Not that it would be end of the world, but still. Let's be cool.

@MirceaKitsune There seems to be communication breakdown here and on the bug tracker page As said above, I'm not planning to spend any time on hiding lights until I'm convinced it's practical By repro case I mean either an existing mission and a setviewpos for it, or a dedicated test map package file No repro case - no nothing Best regards

Could you upload a same texture for me too look at?

How did you test this?

You don't _need_ to convert your custom textures to RGTC This thread is about the core assets only

This entire charade with idEntity subclasses does not make sense to me. idEmitter, idLight, maybe more classes don't call the super's overridden Think(). We got a mess of copy-pasted poorly maintained Think's scattered across the code. As matter of fact, it's not impossible for a idLight entity to have some decals on it, unless I'm missing something

Only the entities affected I.e. the light will still shine, just its entity (e.g. the lamppost) will be hidden I'm not keen to mess with the lights themselves I think it won't hurt to leave the light interacting with a nearby wall - that's just two triangles to draw

Fixed hide_distance for light entities in svn rev 9492 @stgatilov You might want to review this change

Example I think it would be so much better for this particular light behind the wall situation

It's a good example, actually I always wondered if DR allows to clip the light volume so that the light origin is not in its center?

Awesome for speed? Can we have a benchmark setup for this? I don't argue that it would improve things, but I'm skeptical on how much it would improve

Right, simply reorder the lines on the left so that the longer lines are below

We can add this as new script function with the C++ backend

I would suggest breaking the damage stats into two lines

Lights don't draw anything by themselves If there's an entity touching the light it will still emit all its surfaces for e.g. depth pass, ambient pass, etc I understand your idea but IMHO hiding entities (or replacing them with billboards) is more beneficial overall You would have to produce a test map where distant lights is a major performance problem for me to investigate this any further

r_showSmp FFF hints that the CPU can't handle the scene complexity

Emitters seemingly fixed At revision: 9479

r_showSmp 1 - what prints? r_fboresolution 0.5 - fps changes?