News | Forum | People | FAQ | Links | Search | Register | Log in
Mapping Help
This is the place to ask about mapping problems, techniques, and bug fixing, and pretty much anything else you want to do in the level editor.

For questions about coding, check out the Coding Help thread: https://www.celephais.net/board/view_thread.php?id=60097
First | Previous | Next | Last
 
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 
That Would Be Fast 
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 
I Think They Can Be Rotated 
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 
Trouble With Angles 
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 
BSP Vertex Manipulation In 2d Window 
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 
Network Packets 
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? 
Try Here 
Funny Guy 
I did not post the above message #11111

And to that poster: of course I 'tried there', but the info is NOT to be found on that website, nor is it in the manual or readme files. It only mentions how to enable vertex dragging by setting vertex_select_mode "2" in the bsp.cfg but it does not mention the actual process of vertex manipulation....anywhere. 
Negke: 
yes, changing func_wall to func_illusionary would decrease edicts, and increase static entities, and could reduce packet overflows if you convert enough of them. 
Metl 
Does it reduce detail of hull 1 if you convert lots of illusionaries to func_walls? i.e. a reduction of clipnodes and whatever else? 
I Mean Walls => Illusionaries 
not the other way round, sorry. 
Ricky: 
walls and illusionaries are identical as far as QBSP is concerned, so they have no change on the bsp complexity... 
Me = Funny Guy 
"does not mention the actual process of vertex manipulation....anywhere"

...apart from lesson 7 in the tutorials. However, I do not believe it is as advanced as shown in the Worldcraft tutorials as there is no central handle. I have not searched the BspEditor configs to see if there is a setting for that so you might look there if you have not already done so.

But dragging and cutting and shearing will get you any (legal) shape you want. 
Mike 
I know that tutorial and that's not what I mean. I really mean the stuff you see in the WC tut. I know for a fact that BSP can do that, you can have the same handles on the brush and I don't mean those corners but handles that are between the corners, just as in the WC tut.

Basicly, you can already do this in the 3d window in BSP on default, but I remember there was an easier way and it drives me nuts that I forgot about it, because it was way faster then cutting and shearing. 
I Guess 
I should mail the author... 
Wtf Wc 
Could someone see if this map loads in worldcraft? I saved earlier, closed worldcraft, and now it magically doesn't open. WC reports 1456256322345 solids not being loaded because of errors in the file.

:( 
Disregard That Last Post 
I've already recreated what I lost. 
Far Concern 
Sometimes it is handy to know what you've done wrong, before recreating it.

I did a quick search with notepath and concluded you reached an unknown punctuation at line 885.

}
}
{


Here's the corrected map in disregard:
http://members.home.nl/gimli/tl_.map 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.