-
Notifications
You must be signed in to change notification settings - Fork 155
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
A custom shader works on one brush but it fails with the neighbour brush beside it #650
Comments
Because you covered just one face per brush with it; This has random behavior in 1.6 branch. |
No, I textured both sides but I am still not able to shoot through one of them. One shader |
Result of covering two faces is random too. |
@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. |
Yes, this radiant shuffles faces and this q3map2 determines content by 1st face. |
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:
If you need a different behaviour for a different surface, split the brush in two and apply a unique shader to each brush. |
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. |
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. |
System design itself has no such limitation. There is just no code to resolve content parms mixture.
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. |
Is there a netradiant that supports RTCW? The mentioned package is only for Q1/Q3/Heretic2. |
The mentioned package supports RTCW, see unverified game configs there. |
The radiant.exe crashes. The unverified game configs for wolf are not sufficient. Something is still missing. |
Ok, I found it under folder games. It is working now. Thank you Garux. |
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. |
There is mbspc included, which is bspc from Q3 source with some improvements. Where is the source of bspc you want? |
The mbspc.exe is not suitable for RTCW. RTCW needs an area compiler that can generate a _b0 and _b1 file. 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. |
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). |
My binary displays the following: D:\wolfenstein\radian150>bspc And I found this line in your source code: 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? |
I can build that code, but there is no goal to have two bspc code versions in the project. |
Case 1: 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: Thank you |
You apparently do not quite realize what these switches do. 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 The question is whether these are alright for use in RTCW, considering i had to remove unrecognized |
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 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. |
Configs have been obviously loaded in my test, as i'v got two aas of varying size. |
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. |
So things are clarified: RTCW bspc is not compatible with Q3 and dust is not a thing in RTCW. |
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? |
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. |
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. |
Compiling is just a part of problem (getting id's script to work or creating own build script). |
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
The text was updated successfully, but these errors were encountered: