BJP's qbsps have a -hilimit switch to enable extreme capacity. This may be worth a try, though probably not solve the texture lump problem. If you can't reduce their number/size (considered grouping several similar textures into one?), and are aiming at DP anyway, you can use the Q3 map format and compile the map with hmap2. This way the map will have external textures which should bypass the texture lump issue. 

 

aguirre's (BJP) qbsp already has > 2mb tex lump capacity.

also, i've never been able to get -hilimit to work.
i mean, it compiles and whatever, but no engines can load the map. not even aguirre's engine. :P 

I need -hilimit. Without it my map wont compile. My map runs in Fitz .85 (and its children), Darkplaces, Aguire-Quake etc. When you hit the vertex limit weird stuff happens. The map will compile, but DP and Fitz&co no longer run it, and AguirRe's invincible, un-crashable engine will run it but you get artefacts in the form of giant flickering polygons all over the place. 

Dont break the vertex limit of 65### whatever it is. 

I think -hilimit merely allows the map to compile, it doesn't magically make engines support the resulting bsp. I used it to exceed 32k leafs I think, and it worked for that test. Not sure if you need it even to exceed marksurfaces though. 

that's really all i meant. i mean, what's the use of compiling a bsp that can't load in anything at all. :P 

Probably aguirre hoped that engines would add support once there were bsps to test it on. At least, he added a lot of support to his engine. Sounds like he didn't get to everything though. 

The 65thousandish mark. But I started to need the -hilimit command way back when it was only 40'000 or something. If -hilimit wasn't there, really large maps would be a no-no. 

i have a map that is right at the 65k vertex mark, but the other things are either below or very close as well, hence why i felt -hilimit was completely useless.

must be in the way the map is made that makes other things balloon up faster than vertices. 

How much does the openess of an area affect VIS time? If an area is huge but low on detail does VIS time still get hit really bad? 

yeah, detail and 'openness' both affect vis.

for example, i've got a map that is at 65k vertices, that is to say, about as detailed as you can be, and it full vises in less than 4 hours. flat 3 if i let the machine be and not use up the cpu. mind you, this is on a dual-core cpu, so single core, it'd be maybe 6-7 hours, but that's still very fast.

another map is about half that, but is basically one giant open terrain area, and the vis estimate reached 200 hours before i gave up. (since it's wide open, there's no real point running a full vis anyway).


it's not just details, it's also how many different planes there are in an area, because many different planes (for example, tri souped terrain or curves/beveled edges) will force qbsp to cut the area up into many many (many) small volumes which takes exponentially longer to vis. 

What would happen if you created an empty box of sky and just placed models inside it? in showtris the sky always looks like it's has less polys cutting it up :E 

But as soon as there's geometry in, things slow down. I remember a certain coagula map that was the biggest bitch of all Quake to vis which made the author feel stupid for months afterwards.

Modern compilers split a simple sky surface only twice if there's no interference (older ones would treat sky as a regular texture which is why back then it was recommended to scale it up). So, indeed, you can box your whole map with sky and turn everything within into a large func_wall. Bam, VIS trouble solved! 

To be more precise, they split it once, so it will have two polys. In a box with flat symmetric walls and no other brushes touching it. 

Thanks negke. I was thinking about it's use for adding a bit of surrounding geometry beyond walls in large areas.

And on a similar note: Quoth and replacing geometry with BSP models:

I've got it working, but you don't appear to be able to apply an angle change to it. This just a basic limitation with the technique? 

Btw. the func_wall box thing above was a joke in case you really thought it was the way to go. If it's just for additional detail 'outside the window', then it's fine.

Yes, I think external bsps can't be rotated. They always appear relative to worldspawn (angle 0). For angle varations you'll have to create several instances in individual bsps. 

If it's just for additional detail 'outside the window', then it's fine.

Yeah just thinking of it has some extra eye candy 

Yeah :) Just give the representative entity an angle like any other entity. Seem to recall it working..... I'll check :) 

otherwise try mangle: pitch yaw roll 

Certain entities force angles to be '0 0 0' regardless of the settings from the map. This includes func_wall and func_illusionary. This comes for the standard quake source. Quoth doesn't change this and it probably wouldn't be wise to do so for reasons of backwards compatibility with existing maps.

If you want an entity class with an external model which you can set angles on, I recommend mapobject_custom. It also allows you to select if the entity is made static or not, which might be helpful if a) you're running out of static ents or b) you need to do something dynamic with it.

As a final cool hint, mapobject_custom has MOVETYPE_NOCLIP. While it would probably be of limited use to set the velocity of the entity, this also enables you to set avelocity on one and it will rotate. This is a very cheap and easy way to create rotating fans in base style maps.

If you're worried about the loss of solid clipping because you previously used func_walls instead, I should warn you that rotated bsp model don't provide correct clipping in most engines - so even if func_walls supported it user experiences would range from inconsistent to broken. Luckily you are protected from this by virtue of it not being possible... 

hehe giving a custom map object an angle but not setting it as static does make the collision go bonkers :D
With the collision off it's pretty much exactly what I was looking for now cheers :)

ps func_togglewall is almost but not quite the most useful thing ever :p 

Hi,

I'm getting back into BSP. Ironically, in the past I knew these things but... Are there users of BSP (Quake Editor) that know how to use Vertex Manipulation in 2d window? Or how to make it easier in 3d?

Basicly, I remember it was very easy for me to create a sword-shape from a rectangle by just selecting the vertex in the middle on the side of the rectangular brush and then just pull it outward, like you can see in this Worldcraft tut @ Vertex Manipulation section:
http://www.quake-1.com/wc16a-tutorial/brushes.html 

How does that work again. All dynamic entities get sent over the network and having too many of them at once causes overflow. Static entities on the other hand don't generate network traffic. So lots of func_illusionaries are more favorable than lots of func_walls. Does that sound about right? 

http://www.bspquakeeditor.com/index.php