large maps help

[ericw]

@toneddu2000 "brushDef" is the "brush primitives" map format.
afaik my compiler is the only Q1 qbsp with brush primitives support, and it should be OK with +-65k unit maps.
https://github.com/ericwa/tyrutils-ericw/releases

[Nahuel]

I am testing fbsp with fte and becomes my favorite map format

A question to spike/ engine programmers
Why FBSP is so unnused?? What q1 engines supports FBSP?? IS hard to implement fbsp in quake engines?

[Spike]

fbsp comes from qfusion, and is really just rbsp (from raven's q3-based games) with bigger internal lightmaps (which is quite minor in the grand scheme of things).
to implement it, you first need q3bsp and all of its capabilities. you then need to implement multiple lightmaps per surface, and blend them together, probably while also trying to deal with q3 shaders...
which is probably why dp doesn't support it despite already having q3bsp support.
so yeah, fte is the only q1 engine that supports it, and dp can only be described as inactive, so I doubt that's going to change any time soon.

when GB was messing around with rbsp, he found q3map2's support for it to be somewhat dodgy, resulting in various lighting bugs. So watch out for those. Maybe they've been fixed since.


mh was messing around in rmqe with a lighting system like that imposed by rbsp (there are performance advantages when your entire [highly detailed] map has smoothly animating lightstyles), but that engine lacks all the other things q3bsp would require.

[Nahuel]

when GB was messing around with rbsp, he found q3map2's support for it to be somewhat dodgy, resulting in various lighting bugs. So watch out for those. Maybe they've been fixed since.

I didnt find problems! i guess GB did try really hugue maps, aniway thanks for the help

[Spike]

its also possible that you're using a different branch of q3map2, or that the bug has actually been fixed since. if its all working and supports your lightstyles properly than hurrah for you.

[toneddu2000]

@toneddu2000 "brushDef" is the "brush primitives" map format.
afaik my compiler is the only Q1 qbsp with brush primitives support, and it should be OK with +-65k unit maps.
https://github.com/ericwa/tyrutils-ericw/releases

Sorry ericw for the late reply, I guess I didn't see your post! Thanks I'll try, even if I prefer to stick to q3bsp (to be honest I hate q3bsp too and I'm literally craving for a brand new level format, modern and completely compatible with blender scene, but, whatever)

[frag.machine]

Well, my turn.

I have a fairly large map (bigger than 4096 but below the 8192 qu per quadrant) where in FTEQW occurs the "leaking void mirage", although gl_maxdist is already set to 0. The map is built using TxQBSP 1.13 and VIS 2.31 and there are no leaks. Any suggestions on how to fix/avoid this ?

[Spike]

I'm going to need more info...

1: does the 'void' move with the camera? does it suddenly appear? or is it at a fixed boundary regardless of the camera?
2: does the qbsp version that you're using still have 8192 hardcoded into BaseWindingForPlane, or has it already been fixed to deal with larger maps? (iiuc txqbsp 1.13 still has this problem - note that this 8192 limit is radial rather than axial, which means it can be lower for non-axial surfaces)
3: did you try compiling with a qbsp that is known to have BaseWindingForPlane already fixed/extended? like tyrutils-ericw or hmap?

not a fix, but gl_clear may make things clearer.

[frag.machine]

1. Yes, it pops occasionally in certain areas (like the spawn point which is roughly at the center);
2. Nope, haven't tried other qbsp compilers because I believed it supported bigger maps. Thanks for the tip, I'l check it later.
EDIT
Yeah, tyrutils qbsp fixed the void issue... but now some parts of the map are non-solid. :/
Welp, I'll try another port. Thanks for the help, guys.
EDIT2
Tried hmap2 and now everything works as expected. Thanks again.