#11098 posted by necros on 2011/05/19 01:32:58
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
#11100 posted by negke on 2011/05/19 09:39:45
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!
#11101 posted by negke on 2011/05/19 09:43:43
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?
#11103 posted by negke on 2011/05/19 14:13:59
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
#11105 posted by RickyT33 on 2011/05/19 15:04:21
Yeah :) Just give the representative entity an angle like any other entity. Seem to recall it working..... I'll check :)
#11106 posted by gb on 2011/05/19 22:33:50
otherwise try mangle: pitch yaw roll
Trouble With Angles
#11107 posted by Preach on 2011/05/19 23:48:12
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
#11109 posted by megalodon on 2011/05/24 17:30:30
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
#11110 posted by negke on 2011/05/25 14:05:34
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
#11111 posted by megalodon on 2011/05/25 14:52:40
Funny Guy
#11112 posted by megalodon on 2011/05/25 15:42:03
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:
#11113 posted by metlslime on 2011/05/25 19:38:54
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
#11114 posted by RickyT33 on 2011/05/26 00:57:35
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
#11115 posted by RickyT33 on 2011/05/26 00:58:13
not the other way round, sorry.
Ricky:
#11116 posted by metlslime on 2011/05/26 02:07:32
walls and illusionaries are identical as far as QBSP is concerned, so they have no change on the bsp complexity...
Me = Funny Guy
#11117 posted by Mike Woodham on 2011/05/26 08:08:41
"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
#11118 posted by megalodon on 2011/05/26 15:58:41
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
#11119 posted by megalodon on 2011/05/26 15:59:31
I should mail the author...
Wtf Wc
#11120 posted by jt_ on 2011/05/29 07:46:50
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
#11121 posted by jt_ on 2011/05/29 15:39:37
I've already recreated what I lost.
Far Concern
#11122 posted by madfox on 2011/05/29 17:18:14
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
|