A custom shader works on one brush but it fails with the neighbour brush beside it

[sd2009-0]

Hi,

I am experiencing a strange effect with the q3map2.exe x64 from
the GtkRadiant 1.6.4. This custom shader below is working with one
brush in the same map, but it is not working on a brush beside it.

textures/jmetal/jremagen
{
qer_editorimage textures/jmetal/jremagen06.tga
surfaceparm alphashadow
surfaceparm noimpact
surfaceparm nonsolid
surfaceparm nomarks
surfaceparm playerclip
nomipmaps
nopicmip
cull disable
{
map textures/jmetal/jremagen06.tga
alphaFunc GT0
depthWrite
rgbGen vertex
}
}

I would be happy if the shader fails with both brushes but why does it
work with one and fails with the second. I can shoot through one brush
but the other brush does not let any bullets through it.

Very strange. Both brushes are textured the same way.
Did I make a mistake that I am not aware of?

Both brushes are textured with common/nodraw externally.
They are very long brushes.

Thank you for your suggestions

sd2009-0

[Garux]

Because you covered just one face per brush with it; This has random behavior in 1.6 branch.

[sd2009-0]

No, I textured both sides but I am still not able to shoot through one of them. One shader
allows me to shoot through and the other does not.

[Garux]

Result of covering two faces is random too.

[ensiform]

@Garux isn't that because of how radiant doesn't consistently store brush faces in order in map file then q3map2 has issues deciding what contents to use? At least in this main repository version.

[Garux]

Yes, this radiant shuffles faces and this q3map2 determines content by 1st face.

[0bsidian]

This issue is a limitation of Q3's shader system. Surface parameters don't have a hierarchy where certain attributes take precedence over others. Content changing surface parameters are applied to an entire brush object, not just the face it's on. Therefore, different surface parameters applied on different sides of the same brush will result in conflicts.

Q3Map2 reads shaders in order as they appear on the brush in the .map file. It selects the surface parameters from the first shader it reads and ignores the others as a means to resolve the conflicts. GtkRadiant (all versions) writes shaders applied to brush faces seemingly at a random order which can change if you manipulate the brush in any way.

As GtkRadiant rewrites the brush data, Q3Map2 compiles the brushes with changing shader parameters, resulting in unexpected behaviour in game. None of these are a bug with GtkRadiant or Q3Map2, it's simply how shaders work. I'm probably quoting myself here, but from the Q3Map2 Shader Manual:

It should be noted that some of these surface parameters will change both the surface as well as the content of an object (surfaceparm water, for example). Shaders containing content altering surface parameters should usually be used on all sides of the object.

If you need a different behaviour for a different surface, split the brush in two and apply a unique shader to each brush.

[sd2009-0]

Hi Obsidian,

Thank you for the effort. I disagree with you. I did not create this message after the first attempt. I really did not let any thinkable alternative so far without testing it. I have created another brush and even another shader with another name, so the uniqueness per brush was a fact. It did not help me either. I cut the brush in pieces. It did not help me either. I applied the shader on both sides, which does not make sense since the engine will display two sides, which is very ugly and unprofessional for a transparent brush. If shaders work like that, then this means chaos nothing else. I am not able to create a long bridge fence with brushes. I hit a max_ something error during the first attempt. I was forced to create a shader. I personally hate shaders, and try to avoid using them. Whichever workaround I invented,, created new constraints and new challenges and problems. It is very frustrating and disappointing to work that much and that long with no satisfactory result. If you look at the shader, it contains the [surfaceparm playerclip] parameter. This also does not work. I am forced to put another clip brush near the fence. This is a bug. It needs to be sorted, because I am not getting the result that I want whatever I do or try, or do you have a real alternative or solution? This is not the end of the story. If the fence brush touches the towers of the bridge the tangent brush will be rendered as a transparent brush although it does not have a caulk texture. I was forced to leave a gap between the fence brush and the tower brush. I have been working for months on this fence. Bear in mind that raising the number of used shaders and textures in a map increases the probability of hitting the nasty shader overflow bug. If I understood Obsidian well, I cannot have any acceptable solution in this case from a shader, because it functions in a way that does not suit my needs.

[Aciz]

If the brushes truly are only common/nodraw and this shader, this does sound like a bug for me, since neither shader has any properties that would make the brush block bullets, even if q3map2 would choose contents based of either.

[Garux]

This issue is a limitation of Q3's shader system.

System design itself has no such limitation. There is just no code to resolve content parms mixture.
There was warning for this case, which was commented out by ydnar as silly. Probably wasn't so silly, considering this issue.
One related unfortunate design solution was to use surfaceparm keyword for both surface and content parms, this fools user's expectations basically.

GtkRadiant (all versions) writes shaders applied to brush faces seemingly at a random order which can change if you manipulate the brush in any way.

This is not true. Exactly this 1.4/1.6 branch shuffles faces order at any opportunity, whether it's avoidable or not.

@sd2009-0 user side solution is to use consistent content parm for all brush faces, i.e. playerclip instead of nodraw. Other option is to use this radiant https://github.com/Garux/netradiant-custom/releases, which solves the problem in the code.

[sd2009-0]

Is there a netradiant that supports RTCW? The mentioned package is only for Q1/Q3/Heretic2.

[Garux]

The mentioned package supports RTCW, see unverified game configs there.

[sd2009-0]

The radiant.exe crashes. The unverified game configs for wolf are not sufficient. Something is still missing.

[sd2009-0]

Ok, I found it under folder games. It is working now. Thank you Garux.

[sd2009-0]

Contratulations! The radiant 1.5.0n is a great success. The shader is doing what I expect it to do. The editor loads large maps much faster than the regular Radiant 1.6.4. The graphics have a much higher quality. Even the navigation in the editor is very smooth, wow. Great job. Thank you.

Can you suggest a bspc.exe for the editor? I am still using the bpsc.exe from release 1.4.0. It knows the syntax of RTCW for phases _b0 and _b1.

[Garux]

There is mbspc included, which is bspc from Q3 source with some improvements. Where is the source of bspc you want?

[sd2009-0]

The mbspc.exe is not suitable for RTCW. RTCW needs an area compiler that can generate a _b0 and _b1 file.
Here are some examples for the syntax:

bspc -threads 4 -ext _b0 -cfg aascfg_sm.c -bsp2aas <path to .bsp> -output <_b0 file> -optimize -forcesidesvisible

bspc -threads 4 -ext _b1 -cfg aascfg_lg.c -bsp2aas <path to .bsp> -output <_b0 file> -optimize -forcesidesvisible

The two commands will generate a file <mapname_b0>.aas and <mapname_b1>.aas.

The mbspc.exe does not understand this syntax mentioned above.

I do not have any sources.

If you do not have alternatives, it is ok. I can continue to use the old version from Radiant 1.4.0. It functions properly and I know its handling well.

[Garux]

What i see here https://github.com/id-Software/RTCW-SP/blob/master/src/bspc/bspc.c#L816, -ext just adds optional text to output file name (to avoid manual renaming basically).
Can't judge, if that bspc adds some more codes, wanted by RTCW.

[sd2009-0]

My binary displays the following:

D:\wolfenstein\radian150>bspc
Opened log bspc.log
BSPC version 2.1c by Mr Elusive
GtkRadiant 1.2.1-nightly Jan 13 2002

And I found this line in your source code:
#define BSPC_VERSION "2.1c-wolf"

which means that it is the same code. Besides, the C code you sent needs several header files and uses functions from external C modules. Are you sure that you can fulfill all the requirements? Are you a developer? Do you have the compiler to generate a binary from the code that you found?

[Garux]

I can build that code, but there is no goal to have two bspc code versions in the project.
If you can confirm, that mbspc works well for RTCW, i can add -ext switch (or perhaps readd, because Q3 bspc has 2.1h version).

[sd2009-0]

Case 1:
If mbspc does not understand the -ext parameter and does not read the two configuration files aascfg_lg.c and aascfg_sm.c to generate two _b0.aas and _b1.aas files, then the mbspc is almost useless for RTCW. Consequently, if you add that parameter, then it must instruct the mbpsc.exe to read the two configuration files aascfg_sm.c and aascfg_lg.c. Hence, you need to add two parameters to the mbspc.c source code, the -ext and the -cfg parameter too.

I attached them to this message.

Remember the -ext parameter syntax:

bspc -threads 4 -ext _b0 -cfg aascfg_sm.c -bsp2aas <path to .bsp> -output <_b0 file> -optimize -forcesidesvisible

bspc -threads 4 -ext _b1 -cfg aascfg_lg.c -bsp2aas <path to .bsp> -output <_b0 file> -optimize -forcesidesvisible

Case 2:
Compiling the old 2.1c bspc as a 64-bit binary is also useful. Who knows maybe through a Windows patch some 32-bit binaries could become obsolete and maybe useless.

Thank you

aascfg_lg.zip

[Garux]

You apparently do not quite realize what these switches do.
This

mbspc -cfg aascfg_sm.c -bsp2aas village2.bsp -optimize -forcesidesvisible
ren village2.aas village2_b0.aas
mbspc -cfg aascfg_lg.c -bsp2aas village2.bsp -optimize -forcesidesvisible
ren village2.aas village2_b1.aas

produces this

The question is whether these are alright for use in RTCW, considering i had to remove unrecognized rs_allowladders param, and most likely GTK 1.4 release has bspc 2.1c for worlf and 2.1h for q3 for sensible reason.

[sd2009-0]

The two files aascfg_lg.c and aascfg_sm.c are different. It is not only about this parameter rs_allowladders. But if you were obliged to remove this parameter, maybe because it is not used in the new mbspc.c version, I do not know the consequences. I did not develop the engine. But at least I can test it.

Just to mention an example of the difference:

bbox //30x30x72
{
presencetype PRESENCE_CROUCH
flags 0x0001
mins {-32, -32, -24}
maxs {32, 32, 48}
} //end bbox

does not have the same values in the two files (aascfg_lg.c and aascfg_sm.c ).

ren the file is not a problem, but reading each configuration file and generating an aas file according to the settings in the configuration file is crucial.

I want to mention another example.
Both q3map2.exe from your Gtkradiant 1.5.0n and from the 1.6.4 radiant do not know the parameter surfaceparm dust. I always get a warning about them that they are not known. The shader manual on the other side states them and tells the mappers that they can use this parameter. Some functionality is omitted or added with each and every new version. Gtkradiant 1.2.11 has a functioning camera plugin. No other radiant that I know has a functioning camera plugin. When I compile a map with this parameter surfaceparm dust Gtkradiant 1.2.11 does not complain about this parameter. The q3map.exe from Gtkradiant 1.2.11 does not support ASE models, q3map2.exe from Gtkradiant 1.6.4 does and so on. It is amazing how different is the behaviour of many Gtkradiants with the same wolfsp.exe engine.

[Garux]

Configs have been obviously loaded in my test, as i'v got two aas of varying size.
surfaceparm dust thing is either bug, or it was removed on purpose, because engine doesn't support it. Does it?
Shader manual is trying to be uniform, while games circumstances are varying lightly.
camera plugin was thrown away during development, as it takes effort to maintain code. I personally got not clear notion of it's use. There are more practical abandoned plugins, like curry or pk3man.

[sd2009-0]

I compiled one map with mbspc.exe after commenting the parameter rs_allowladders but the engine does not accept them. It says aas not loaded, which means that mbspc.exe is most probably useless for RTCW. I tried to use the surfaceparm dust parameter but the RTCW engine does not seem to react at all. No dust is generated with q3map2.exe of both Gtkradiant 1.5.0n and .16.4. It says parameter is unknown. The q3map.exe from 1.2.11 does not complain about it but this old compiler also does not convince the wolfsp.exe to generate dust.

[Garux]

So things are clarified: RTCW bspc is not compatible with Q3 and dust is not a thing in RTCW.

[sd2009-0]

Yes, this is a fact for me now. Is it possible for you to compile bspc.c version 2.1c as a 64-bit binary?

[Garux]

I can try id's Conscript-bspc at a chance, but do you think this effort makes sense? Because 1: you can expect 32 bit wrapper availability in windows for at least a decade 2: there is 32 bit only code, which wont be functioning properly in 64 bit build w/o fixing.

[sd2009-0]

When I used to develop in the past, compiling a 16-bit source code as a 32-bit binary was not that complicated. I had to just add two or three keywords to my code maximum, set a flag as 32-bit in my ide and compile. Maybe sometimes a few lines. But I do not know how much effort you need to put in order to compile a 32-bit source code as a 64-bit. It is just a suggestion, if it is possible.

[Garux]

Compiling is just a part of problem (getting id's script to work or creating own build script).
32 bit only code may be warned by compiler at best (may be not either). Such code produces any sorts of strange bugs in 64 bit, like crashes and data corruption.