Closed Tasijjj closed 6 years ago
Not sure what game you're building for, but this looks an awful lot like this bug that we fixed in our Quake2 / Quetoo BSP compiler last year:
http://forums.insideqc.com/viewtopic.php?f=3&t=5817&p=58037&hilit=tapir#p58037
My suggestion would be, if you're using older tools, is to try some of the more well maintained compilers that are out there.
Of course, if this is Q3 / q3map2, I'm not sure what to say. Not my area of expertise.
I'm using ioquake3 with GTK Radiant 1.6.5 (20-08-2017). I forgot where I found it.
Do you have any specific suggestions, which compiler to use?
May be provide test map, so we could reproduce and investigate Normally such stuff is done from detail brushes with caulk for odd faces and w/o crappy intersections, but it's still apparent compiler's flaw Also your 3d view looks broken
First of all, here is one example of a map that compiles with several gaps in between brushes or brush sides missing.
My 3D view looks odd in terms of selecting which triangle to show. If the whole triangle is not in the screen, radiant wouldn't show it. It should be vice versa, I know. Until now, I thought it was some kind of preference that I couldn't found.
So which radiant and compiler should I use?
As for radiant/compiler tip, i'd like to recommend my fork
As for map: one is very good test case! Issue source is obvious tho: tiny portals There are warnings even:
WARNING: node without a volume
node has 4 tiny portals
node reference point 874.70 877.05 -56.91
both compilers (from this project and mentioned fork), have this problem (~10x fewer errors in 2nd one), tho that's a problem of you, doing thing wrong (creating tiny intersections of structural brushes) using detail brushes solves the issue perfectly for both compilers (avoiding tiny intersections would most likely solve it too)
Thank you very much for the help. I'll be working on removing tiny intersections.
Sorry for a kind of ignorant question but, what does the phrase "detail brush" stand for?
Detail brushes do not block pre-computed visibility in the map. Structural brushes do. By default, radiant creates every brush as structural, and it can be turned detail with CTRL + M. You want to create the basic structure of your map with structural brushes, and add any details as detail brushes. Avoid odd angles when creating structural brushes, as they can cause issues with lighting.
Edit: obsidian was faster :P wanted to add that you should probably also look into some official map sources, to get a general idea on how to use structural/detail brushes. You can toggle detail brushes with CTRL + D.
All of you couldn't be more helpful.
There is one thing I briefly mentioned in the original post of this thread that I would greatly appreciate to know: is there a way to make some sides of the brush to completely disappear once the compilation is done. So there is no such triangle in the .bsp file. In my case, the remaining triangles would be just those facing upwards.
Use caulk for those faces.
Caulk is kind of good enough but as far as I've tested it, it doesn't completely remove the triangle. For example, it clips the player, intersects bullets, etc. So you could argue that the triangle is still there in a way. Or am I doing something horribly wrong?
Caulk is what you should be using for faces that are not visible to player and should be solid.
What if... I want to place something below the "terrain" but very close to it, as shown on the sketch. I hope is understandable.
Should I just give up on this?
Why is that an issue?
There would be a hole in the ceiling if there would be a room below the brown brush.
Sorry, but could you please find some other method of support? This issue tracker is for actual GtkRadiant software issues. For support issues, I suggest you look at other options via forums or IRC as detailed here:
No problem. Thank you for the link.
Greetings.
Could someone explain the issue shown on the picture 1?
If it's not clear what's wrong, the picture 1 shows the compiled (in-game) part of terrain, made out of three sided brushes. There is clearly a part of brush missing. Could it be caused by the overlapping of brushes show on the pictures 2 and 3?
Shaders wise, I started with desired (brick) texture on every side of the brush. Then, I tried changing the sides, that are not "needed" for the terrain, to a texture, that would force the compiler not to write them in the .bsp file (is this even possible to achieve?). I used common/nodrawnonsolid shader for this, because it seemed like it would do the job. Sadly, it didn't.
Brush shape wise, I tried making downward-facing pyramids (picture 4) instead of extruded triangles, so none of the brushes were overlapping and it didn't help.