stgatilov

Yeah, but this is diffuse map. Why are you even trying to compress it with RGTC? Of course if you use it as diffuse texture, you'll get wrong color.

Can you share the normal map file? And note which file it should replace...

You should look at FOURCC code of your DDS file, I think.

beta211-06 is available.

I'm afraid the workflows for RGTC normal maps is not well worked out yet. On the other hand, when the compression format has 4 totally different names, it's no wonder you have problems with tools... For the cup, you can just save TGA version for now. For HD carpets, it would be really great to use RGTC or just DXT1 if it looks good enough, since the textures are large.

It must be BC5u ("unorm"). I think @OrbWeaver tried to load precompressed RGTC in TDM recently and failed, and after that we fixed something. Are you trying 2.11 beta?

DDS with RGTC data must have FOURCC = "ATI2". It is also called BC5 I think.

Better read the wikipedia article S3_Texture_Compression. The DXT formats mainly differ by their use case, not by compression/quality tradeoff. Compression ratio is not a good number to look at: DXT1 gets 6:1 ratio by replacing 16 x 3 bytes (no alpha) with 8 bytes. DXT5 gets 4:1 ratio by replacing 16 x 4 bytes (with alpha) with 16 bytes, out of which 8 bytes are exactly DXT1 for color, and the other 8 bytes are high-quality alpha channel. RGTC gets 2:1 ratio by replacing 16 x 2 bytes (no blue, no alpha) with 16 bytes, which are two high-quality blocks for red and green --- exactly the same quality as in DXT5 alpha block. So RGTC has 2:1 compression ratio but DXT5 has 4:1 compression ratio. Does it mean that RGTC-compressed files will be two times larger?

Also I noticed this white line on the testmap: It looks quite bad from distance, like a 1-pixel aliased line. Is this an issue in the testmap itself?

Regarding these committed assets. Why are normalmaps saved in BC3_UNORM format? As far as I understand, it is DXT5, which is DXT1 color + high-quality alpha blocks. And normal map does not need any alpha at all. You can use RGTC (BC5) for high-quality normal map with the same size, or DXT1 (BC1) for same quality but 2x less size.

I managed to reproduce it: 6225 Yes, it is very hard to reproduce.

Yes.

beta211-05 is available. I'm positively surprised by how fast testing goes I accidentally broke two things during these two weeks , but each of them was caught on trunk within a day Let's hope I broke only two things

Large volumetrics are not blocked off, so you can indeed use them with careful tweaking. The problems with large light I can think of: [shadows only] It requires shadow maps, but large lights are forced to stencil shadows. Even if you stay under this limit, shadow map resolution can simply be too low for accurate handling of occluders near player. As you recall, volumetric light works due to dust in the air slightly spreading light all around. However, this dust also slightly occludes the light (like fog does). TDM's volumetric code ignores this effect, since it is negligible for small but bright lights. UPDATE: That said, large noshadows volumetrics are probably stable (even if they don't exhibit fogging). But shadowing ones seem risky...

Applied the patch.

This video shows that patches are too regular in one direction. That's exactly what I mean by saying that good randomization is very important, otherwise people can see patterns under some conditions. SEED is a huge piece of code trying to do everything. With animated geometry, make sure to not use its geometry merging. If there is a mode to only use entity spawning, that can be used. If not... maybe write a script. Ideally, mapper can specify grass location with a thin box, and the script should raycast this box against terrain. Exactly like projected decals work. Not sure if scripts can see brushes though...

It is wonderful that is works "fast enough" without any specific systems and optimizations! Two things though: I guess if someone wants to show this with a video, he should upload custom-made video to cloud drive and post a link. Moving grass is high frequency thing, youtube compression breaks it so hard! The latest video has all grass patches located in a regular grid and with same orientation, and this looks artificlal. Maybe SEED or custom script should be used to spawn these entities in random distribution? Actually, some low-discrepancy random positioning with simply random rotation should be the best...

Mapper set it to nonsolid: I failed to reproduce this. I can easily imagine TDM's player collision code is not 100% reliable and if you get unlucky, you can clip into object. But I'm afraid there nothing to fix here... Could not reproduce easily. If you find some reliable way to reproduce, that would be great (probably involves save/load, removing an item, or doing something while item is active). As for weird AI reactions... I suppose that has been like that for a pretty long time, and I'd rather not mess with it

I ran it locally under procmon, and yes, it tries to load this file. Don't know exactly why, but I suppose that's something from DirectInput (or OpenAL-soft maybe).

Yeah, waitFrame is a very uncertain duration with uncapped FPS.

Look at this: https://bugs.thedarkmod.com/view.php?id=4854 Non-axis-aligned walls result in wrong collision model at 40K. I spent considerable time trying to understand what causes this, but did not succeed. And despite many fixes/improvements in dmap and such, this bug still works perfectly the same.

The main problem with LWO is that engine always "fixes" them, which often breaks them And engine cannot be changed due to backwards compatibility. On the other hand, now we have OBJ support, which does not mess with geometry. I already suggested to provide a way to load single group/object from OBJ by its name, by writing model name like "mymodelfile.obj$group=lod0". This way we can store all LODs in one OBJ file. Maybe we can extend this group selection to other formats, although that would be harder. Speaking of default distance. The formula should be something like distance ~= A * sqrt(TriangleCount) with some constant A. I suppose constant A can be deduced by setting approximate average size of a triangle on screen with some default resolution (e.g. FullHD).

I think the real efficient limit is about 10K. Beyond that you risk getting physics/collision problems that will not be fixed, unfortunately. On the other hand, if you want to set some kind of background stuff which does not use physics and is not involved in gameplay, you can try doing that. For example, Swing mission creates swinging background, which is pretty large: larger than 10K. And it works well. Speaking of skybox, I have no idea why you want to put it that far. Just find some unoccupied space in the void, create heavily minified version of skybox there, then use the engine skybox feature.

Regarding switching fog in northdale1 at "400 -1220 286". This issue happens in 2.10 too. It seems to be caused by a conflict between two fog lights: "light_116" script-powered fog system of "atdm_location_settings_1" When I "remove" the individual light, or comment out script-based fog, then fog looks the same regardless of camera direction. Doom 3 fog is rather hacky by itself, I doubt two overlapping fogs are supported @Goldwell

I tried Output on SVN and latest beta, on Easy and Hard difficulties, the candle always looks properly extinguished. This is the "StaffQuarterCandle" entity at 1165 147.5 -178.25. The only thing that I noticed is that if I immediately teleport to it after the game starts, I see smoke going from it for some time. I guess because it gets extinguished on game start. I doubt player can see it. If you have this issue: specify which beta version it is (remove mods), delete FM directory and download fresh FM, try to reproduce it from clean start, post your screenshot and darkmod.cfg.