stgatilov
-
Posts
7257 -
Joined
-
Last visited
-
Days Won
280
Posts posted by stgatilov
-
-
On 10/28/2024 at 1:44 AM, Arcturus said:
One thing I wanted to test was .md5 meshes. Parallax mapping doesn't mesh very well with them, but if you crank it up to 11 you get something that looks like polished metal. Of course you can forget about proper texturing, but it reacts to light believably.
Could you please explain where is heightmap used on the builder model?
How does it look without heightmap/parallax? -
It was experimental shader which was never released properly.
And I don't see why it should be helpful here.
The experimental shader could compute reflection from the floor based on cubemap reported above the floor. As far as I see, @Arcturus mostly tests small objects inside the room, where ordinary env. map works fine. -
dev17171-10894 is here.
-
4
-
-
Sadly, this "weak lightgem" is buggy as hell, it will not display proper light value in most cases.
However, "buggy as hell" is still much better than "completely disfunctional", I suppose.Lightgem has rather complex graphical implementation: it uses OpenGL "pixel buffer object" to read back contents of the framebuffer, including some asynchronicity and fences. Maybe GLES does not support some of this stuff.
-
I suppose @snatcher might know something about it...
-
1
-
-
I looked at the shader, and all the types match.
Maybe you really have wrong shader somewhere, it is between two files:
- glprogs\stages\light_passes\blend_light.frag.glsl
- glprogs\tdm_lightproject.glsl
Here is the important contents in the first shader, it must match exactly:
uniform sampler2D u_lightFalloffTexture; uniform sampler2D u_lightProjectionTexture; uniform vec4 u_lightTextureMatrix[2]; uniform vec4 u_blendColor; in vec4 var_TexLight; out vec4 FragColor; void main() { vec4 lightColor = projFalloffOfNormalLight(u_lightProjectionTexture, u_lightFalloffTexture, u_lightTextureMatrix, var_TexLight); FragColor = u_blendColor * lightColor; }
Here is the important line in the second shader, it must match too:
vec4 projFalloffOfNormalLight(in sampler2D lightProjectionTexture, in sampler2D lightFalloffTexture, in vec4 texMatrix[2], vec4 texCoord) {
Maybe your driver cached compiled shader somewhere and still tries to use the old cache.Maybe this is some driver-specific issue.
-
I guess it happens when a custom shader is being used which was not used before.
Maybe something related to loading shader happens from the wrong thread. Windows drivers are OK with that but Linux drivers are not. -
6 hours ago, The Midnight Taffer said:
Missing end chunk 0..1430 (1430 bytes) after downloading URL http://mirror.mstrmnds.me/releases/zipsync/release/release205_from_release204/tdm_defs01.pk4
Is the error message exactly the same every time?
Exactly the same file, same numbers, same URL?If yes, maybe something broken on specific mirror.
Try to use "Get custom version", then select "Prefer Mirror" to "Cabalistic" or "Taaaki2", and try to proceed.What else you can try:
- check RAM
- check disk
- try to disable antivirus temporarily
- try to check for malware
- can something intervene in your network/provider?
-
Mathematically it is possible to extract heightmap from normalmap by solving partial differential equation.
If heightmap is f(x, y), then normal vector is proportional to N = (-df/dx, -dy/dx, 1).
Hence we can find df/dx = -Nx / Nz, df/dy = -Ny / Nz.
So normalmap gives us partial derivatives of heightmap in pretty straightforward way, but their precision is around 0.4% at best.If normalmap was generated properly from a real heightmap, then this problem is called "reconstructing potential function for conservative vector fields". But since our values are rather imprecise, we need some stable solution, not just some trivial prefix sums.
I'm not sure how stable the possible solution could be, and how good will be the quality of the output.
Even if they would be OK, this approach can only be usable as offline tool to be run explicitly.-
2
-
-
Since parallax mapping has sort-of gone public, maybe we should create a public thread about it?
I can extract this discussion into a new thread as a start. -
1 hour ago, lowenz said:
Isn't possible to let the alsoft.ini visible? And maybe OpenAL32.dll (or soft_oal if openal32 is just the router and that can be integrated into the exe)
The alsoft.ini is visible, and people sometimes tweak it to troubleshoot sound issues.
The DLL however is not visible, since OpenAL is embedded into TDM executable.Quoteaside from let choose the "right" HRTF preset for everebody and not just force the default one
There was an idea to add in-game OpenAL settings and possibly allow choosing HRTF preset.
But I'm afraid nobody is good enough listener to check the presets and say "hey, this 3-rd preset sound so much more understandable for me, we really should provide selection to everyone!"QuoteAll the 3 settings are mandatory, otherwise it just doesn't work (and using by default the WASAPI shared mode, not the exclusive mode, it's not possible to avoid further and unwanted processing by the Windows Mixer or other APOs installed on the system - being the only other way this: Release OpenAL Soft 1.22.2 WASAPI-exclusive · ThreeDeeJay/openal-soft )
I feel it is not the right idea to switch to dedicated mode.
I'm pretty sure there would be many quality-of-life issue in this mode, like background sounds from OS and other applications not cutting through.Are you sure there is real issue with Windows mixer on all machines?
I understand that it is possible to enable some automatic crap in OS that would modify all the sounds, I think I had this on some machines myself. But ultimately it is the user's will to enable some crappy "3D processing" in Windows and we shouldn't go against it. -
On 10/15/2024 at 4:41 PM, datiswous said:
Does this mean the following info needs an update?
https://wiki.thedarkmod.com/index.php?title=Setting_Up_Speakers#minDistance/_s_mindistance
Yes, now "s_minDistance 0" should work as people normally expect.
But this will become official only in 2.13.
And there will be a big sweep over all the missions to restore original behavior when 2.13 beta starts.-
2
-
-
16 hours ago, lowenz said:
Experimental implementation of parallax mapping
Isn't it reatroactive (in old FMs), right?
Of course it is not retroactive.
Parallax mapping requires heightmap and height scale, which does not exist for old materials.
Also, any kind of parallax mapping introduces visual artefacts and might require tuning for specific use case, so we can't just force it onto everything.-
2
-
1
-
1
-
-
1 hour ago, datiswous said:
I thought you specifically removed this some time ago. Although I think at least it's good vor dev and beta versions.
I believe I removed it because:
- It showed only the version, not the SVN revision. It did not help but only added confusion.
- It had some "check for updates" logic which could ping the server, but we always forgot to update the server side of this feature. This was the main thing I wanted to remove.
I guess I removed the whole GUI element because I thought having this info in console is enough.
-
dev17152-10890 is available!
-
3
-
-
4 hours ago, MirceaKitsune said:
Did anything breaking saves change from the previous dev version? I didn't update yet since I didn't finish a FM I was playing... I disabled the setting that forces you to have the same TDM version to load old saves, but if save compatibility was affected loading would still cause a crash.
I'd recommend to record which dev build you were playing somewhere, maybe rename savegames directory so that it includes the version. Or simply get a fresh TDM directory for new version until you finish the mission.
I don't think there were savegame format changes.
-
New dev build is available: dev17121-10869
Be sure to check the new search functionality in mission select / download menus by @Daft Mugi !
-
2
-
1
-
-
Just like for tdm_installer, the mirror for mission download is selected randomly.
There are also weights intended to distribute traffic across mirrors.
While you might be interested in using the fastest mirror only, controlled random distribution is used because some mirror owners were worried about too much traffic.-
1
-
2
-
-
interactionMultiLight were experimental shaders which are not used in game.
Just ignore that warnings/errors. -
On 8/18/2024 at 1:32 PM, datiswous said:
What do you mean with that?
The way main menu is customized was changed greatly somewhere about 2.08, which affects both single missions and campaigns.
If you look into mainmenu_custom_defs.gui, you'll see that the current suggested approach for main menu in campaigns is using #if MM_CURRENTMISSION == 2. So you can set defines for separate single missions first, then put them all in a single file and wrap in #if-s.
The sample uses the old approach unfortunately.
-
If you want to find out what is the problem on your machine on specific mission, you can record performance trace:
Tracy Viewer allows to save the trace, so you can send it to me.
At the very least, we can learn whether it is CPU or GPU limited.And yes, there are certain settings in TDM which stress GPU a lot.
Like high antialiasing or high quality soft shadows --- tooltips in the recent version note about it. -
dev17104-10844 is available.
-
1
-
1
-
-
This was suggested many times.
I believe there is technical problem in implement lightgem the way you suggest on GPU.
Maybe I can try to make a prototype with new CPU implementation and see how it goes.However, most of the people believe it would be confusing for the player, and that's a typical case where realism should be sacrificed.
-
1
-
-
On 7/7/2024 at 3:46 PM, OrbWeaver said:
Is it using the 7zip module just to create a better-compressed ZIP, or is it actually creating a 7z-formatted file using the LZMA algorithm?
If it's an actual 7z file, will the game actually load it? The packaging section on the wiki suggests that only ZIP format is supported (although it could be out of date).
Actually, it only matters on your local machine today.
And if you share your pk4 with someone directly.When you release a mission, you send archive to e.g. @nbohr1more, he unpacks all contents and commits them into mission SVN. Then TDM server automatically packs it into pk4 and this pk4 goes into mirrors.
-
1
-
[2.13] Interaction groups in materials: new behavior
in TDM Editors Guild
Posted
Every material consists of global keywords and stages.
Stages are classified into ambient stages and interaction stages (diffuse, specular, bump, parallax).
Interaction stages are partitioned into interaction groups. Each group is rendered as single draw call with interaction shader, its stages supply various settings (e.g. diffuse texture is taken from diffuse stage, specular texture from specular stage, etc.).
Ambient stages are all extracted into separate list and rendered in their respective order. But this always happens after all interactions are rendered.
In 2.12 and earlier, interaction groups were detected dynamically during rendering. There was some preprocessing code which was static (sorting stages, adding implicit bumpmap) and some additional detection in rendering code which was dynamic because it checked conditions.
In the recent TDM version (hopefully in 2.13 too), the old approach is replaced with two new ways to detect interaction groups: implicit and explicit. Both ways are fully static and implemented straight during material parsing.
Implicit detection.
We go through stages in their definition order and add each new stage into the last interaction group. If the last interaction group already contains a stage of same type, then we finish that group and start a new one with the current stage. For instance, if we see interaction stages DSBBDDSBSD (abbreviated by first letters), it will get split into [DSB][BD][DSB][SD] groups.
This should work fine for simple materials with one stage of each kind.
It should also work fine for vertex-blended materials because they should have each group starting from bump stage (and hopefully they don't have duplicate diffuse stages).
Explicit detection.
There is new material keyword: interactionSeparator. If at least one such keyword is present in material, then explicit detection is used.
Each interaction group consists of all the stages located between two consecutive interaction separators. The stages before first separator are put into a group too (if any), same applies to the stages after the last separator. Note that disabled stages are ignored during runtime, so it is possible to have several stages of the same kind in an interaction group, as long as at most one of them is enabled at any time.
Explicit approach can be used for non-trivial cases, especially when stages are enabled by condition (like e.g. animated textures).