[Convert normal maps to RGTC?]

Not sure if we need the signed format at all

IIRC it's useful for object-space normal maps only that we don't have/use

[hide_distance broken again?]

Cool, how can I test this?

[Dev builds (2.10)]

9 hours ago, HMart said:

Btw I did all in my power, trying to make AMD aware of this problem, I exposed the problem on twitter to the official driver guy and I sent two bug reports on this problem, using the driver bug report feature

Noble intentions, even though AMD has never shown any interest in user bug reports

[Convert normal maps to RGTC?]

4 hours ago, OrbWeaver said:

Sure, I'm happy to commit it.

One thing I didn't confirm however is whether the shader can correctly identify which normal maps need Z component reconstruction and which don't. If there are a mixture of precompressed RGTC files and uncompressed TGA or PNG normal maps, the shader presumably needs to know which are which (or does it just always reconstruct the Z component, regardless of whether Z information is present in the input image?)

I think ATM you need to manually set the image normal compression cvar for this to work

[Default grass particles ignore lighting and appear fully bright]

You can just use this particle now and create a bug tracker for this

It will eventually get fixed, maybe before your mission is released

[hide_distance broken again?]

10 hours ago, nbohr1more said:

Isn't that what r_shadowMapSinglePass 2 currently does for normal lights? Maybe create a cvar that does the same but only for ambient lights?

I did not follow that change but from the name of it unlikely

I meant merging lights on the DR level

[Convert normal maps to RGTC?]

Could you commit that in svn then please?

[hide_distance broken again?]

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.

[hide_distance broken again?]

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?

 

[Convert normal maps to RGTC?]

On 7/27/2021 at 10:07 PM, OrbWeaver said:

@duzenko I've uploaded the images here if you want to confirm that the formats are correct. The diffuse is DXT1 and the normal is BC5, although in this particular case I would probably keep the normal map as PNG since this is less than 10% of the size of the DDS (because it's a smooth gradient normal map which compresses well with PNG).

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

[Convert normal maps to RGTC?]

15 hours ago, OrbWeaver said:

@duzenko I'm a little confused by the game code (which I'm hoping to use as a guide).

In idImage::SelectInternalFormat(), there is a check for image_useNormalCompression which then results in the image being compressed into GL_COMPRESSED_RG_RGTC2 format:

// catch normal maps first
if ( minimumDepth == TD_BUMP ) {
	if ( allowCompress && globalImages->image_useNormalCompression.GetBool() ) {
		return GL_COMPRESSED_RG_RGTC2;
	}
	return GL_RG8;
}

But in idImage::UploadPrecompressedImage(), a different format is chosen if "ATI2" is the FOURCC:

case DDS_MAKEFOURCC( 'A', 'T', 'I', '2' ):
	internalFormat = GL_COMPRESSED_LUMINANCE_ALPHA_LATC2_EXT;
	break;

So I'm not quite sure which is the right OpenGL format to use. Surely the chosen format should be the same regardless of whether a precompressed image is loaded or if the image is dynamically compressed at runtime? Or are these two GL formats actually identical?

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

4 hours ago, Dragofer said:

I've:

• Updated my SVN for assets and source code, compiled the latest source code
• Removed the normalmap from my SVN install for one of those textures
• Exported that normalmap as a BC5 .dds with mipmaps in GIMP
• Placed that .dds normalmap in the corresponding dds/ folder
• Loaded OGDA's demomap

The console tells me that TDM failed to get a bindless texture handle on that normalmap There's no normalmap effect visible ingame.

Disable bindless textures and enable the normal compression cvar?

2 hours ago, stgatilov said:

Unfortunately, you won't be able to pass RGTC texture "as is" to renderer.

It only contains X and Y components, so Z component must be computed in shader (maybe also X and Y normalized).

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

[hide_distance broken again?]

20 hours ago, nbohr1more said:

To be clear, it is my understanding that lights still perform the following actions:

1. If a light is visible in the view frustum, visleaf, portal view, and scissor calculations

2. Gather all vertex data within the bounding box of the light

3. Skin all vertices gathered in step 2 ( expensive CPU wise )

4. Upload all skinned triangles to the GPU ( expensive regarding bus data )

5. Fill pixels for all triangles uploaded in step 4 via a depth pass

6. Calculate object silhouettes on the CPU

7. Extrude the shadow vertices on the GPU

8. Fill the stencil buffer

9. Fill the pixels that are now visible after steps 1 through 8 via the light shader

 

If so, it is your assertion that step 7 is more expensive that steps 3, 4, 5, 6, 7, 8 ?

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.

18 hours ago, kingsal said:

@MirceaKitsune @duzenko I think the proper approach here would be to open up a heavy map like TPW

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.

[hide_distance broken again?]

25 minutes ago, peter_spy said:

I'm only mean because my god you're annoying  

@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.

[hide_distance broken again?]

@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

[Convert normal maps to RGTC?]

11 hours ago, OrbWeaver said:

I took a normal map which was working, then saved it using the GIMP plugin in 3DC+ format (I also tried using the Compressonator with various formats which looked like RGTC, e.g. "ATI2N"). After this, the normal map would either show only a single channel (e.g. horizontal bumps are visible but vertical bumps are missing), or no bumps at all; I don't recall exactly which.

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

[Convert normal maps to RGTC?]

2 minutes ago, OrbWeaver said:

Supposedly yes (I believe it's equivalent to "3DC+" in the GIMP plugin), however as I mentioned I have not been able to get this to work at all with the latest build. Only plain DXT-compressed normal maps render correctly.

How did you test this?

[Convert normal maps to RGTC?]

1 hour ago, MirceaKitsune said:

I see. Are Gimp / Krita / Photoshop able to load and save that, or at least plan on being able to? If yes then I'd say go for it.

Gimp is the image editing software I actively use so I gave it a try. I can see there's no export option for RGTC which does raise a concern for this plan.

You don't _need_ to convert your custom textures to RGTC

This thread is about the core assets only

[hide_distance broken again?]

28 minutes ago, stgatilov said:

Hey, I really like it!

I looked what's the actual difference, and it seems to be only LOD processing and some hacky decal stuff... which probably should never happen for lights anyway.

Still, I suggest to test the game thoroughly and keep attention to lights behavior

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

[hide_distance broken again?]

54 minutes ago, MirceaKitsune said:

That's such amazing news! So light sources will hide with distance as well now and no longer be active? And does it interfere with triggering lights on and off? Just making sure I asked.

I'm on the latest dev snapshot and the FM I'm working on already uses hide_distance on small lights: Will update once a new dev version is out and see if this works. Thank you very much for the fix, that's much appreciated

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

[hide_distance broken again?]

Fixed hide_distance for light entities in svn rev 9492

@stgatilov You might want to review this change

[hide_distance broken again?]

Example

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

[hide_distance broken again?]

15 hours ago, kingsal said:

Okay so Ive updated the test map to reflect this. Maybe this isn't an issue with shadow mapping, but I dont know. Dmap and then load it up

lodfade.map 34.34 kB · 0 downloads

 

So this is the common scenario.

A light inside a closed portal is still bleeding through the walls and shadowing the boxes on the outside of the building. Obviously if I add a door we won't have this problem, but this isn't always feasible.  In complex spaces this happens a lot. 

Now if I could just hide that light at a certain distance I can eliminate that problem. 

 

There might be other ways to fix this problem, but once again in complex spaces (which are most city missions) this happens more than you would think. Its not a systemic solution, but it could give mappers more control. 

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?

[hide_distance broken again?]

12 hours ago, kingsal said:

Being able to hide lights at a distance would be helpful actually. Better  yet being able to fade them out gently would be awesome. 
 

There are cases where lights bleed through walls and being able to just turn them off with a distance check would be a very quick and easy way to prevent  that. Controlling that with scripts is a mess, imo.

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

[Ghosting the Dark Mod]

7 hours ago, demagogue said:

 

The issue is there aren't lines to spare.

The first thing we could do is get rid of the "and", and that might be enough for most all cases.

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

[Newbie DarkRadiant Questions]

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