|
PuLSaR...
#111 posted by distrans on 2003/03/17 18:52:25
Would the "Tomb Raider" textures on Fatty's site be of any help?
� CLIP �
#112 posted by Leafface on 2003/03/17 18:56:45
There's one thing I still don't get about BSP's, and it's really a shame to ask this after 4 or 5 years mapping, but
I still don't know how to make CLIPs. CLIPS WITHOUT A BRUSH. I can't believe that every mapper that use clips manipulate the .map files manually or tell QBSP to skip leafs or Idonno. Almost everyone knows how to separate a clip from its brush but me. And it's very embarassing, coz I know that it's a mostly basic thing in mapping.
Please help!!
Distrans
#113 posted by PuLSaR on 2003/03/17 19:14:35
Thanx. I'll take a look
Something Very Strange...
#114 posted by necros on 2003/03/17 19:41:07
if doing a -fast on vis is fast, and a -level 4 is slow, than it stands to reason that a -level 1 should be faster than -fast but slower than -level 4.
well, doing a -level 1 on my map gives an estimate of 298 hours (!), whilst a -level 3 gives an estimate of 6.5 hours.
i'm not really seeing the logic here... any reasons?
i'm using aguiRe's modified RVis+
Oh...
#115 posted by necros on 2003/03/17 19:42:31
one more thing, and this question is directed to aguiRe... why do the percentages sometimes jump back down... for instance:
Full: 36.0%, Elapsed: 17:37, Left: 1:03:38, Total: 1:21:15, 21%
Full: 37.0%, Elapsed: 20:27, Left: 1:43:15, Total: 2:03:42, 16%
Full: 38.0%, Elapsed: 21:41, Left: 1:42:59, Total: 2:04:40, 17%
Full: 39.0%, Elapsed: 22:57, Left: 1:48:26, Total: 2:11:23, 17%
Full: 40.0%, Elapsed: 24:54, Left: 1:29:00, Total: 1:53:54, 21%
Full: 41.0%, Elapsed: 27:28, Left: 1:53:44, Total: 2:21:12, 19%
Full: 42.0%, Elapsed: 30:09, Left: 2:19:12, Total: 2:49:21, 17%
Full: 43.0%, Elapsed: 33:48, Left: 2:49:06, Total: 3:22:54, 16%
Necros
#116 posted by Tyrann on 2003/03/17 21:50:52
Well, I'm not aguiRe, but it's because the time remaining is only an estimate. The first percentage is like normal rvis+, the second percentage is the how much of the total estimated compile time has elapsed. When the estimate gets updated, this percentage figure jumps around with it.
Leafface
#117 posted by Tyrann on 2003/03/17 21:54:34
It sounds like you are confused about what clip brushes are.
A clip brush is just a brush that has the clip texture applied to all it's faces. When the map is compiled, this brush will be invisible, but you won't be able to walk through it. You can shoot through it though.
The things you are saying above don't make sense.
Leafface
#118 posted by Kell on 2003/03/18 08:10:51
If your talking Q1 or Half-Life, clip is simply a texture whose filename is
clip
Apply that to all faces of a brush and presto!
Just make sure you use the clip texture that appears in all wads by default. The id clip texture looks like this:
http://www.signsofkoth.co.uk/clip.jpg
Vis Estimation
#119 posted by aguirRe on 2003/03/18 08:26:07
Tyrann's right about the 2nd percent figure depending on the current estimation. This in turn is updated when the integer part of the 1st percent figure changes (e.g. when 40.6 becomes 41.3).
It may seem confusing at first, but that 2nd percent figure (which may go up or down) is the most important number on the line, since it's a clear indication of how the process advances.
Usually, the vis process is fast in the beginning and then slows down more or less during its lifespan. Therefore the estimation is more accurate in the later stages (unfortunately).
As for different vis levels behaving strangely, I've seen that as well. Sometimes I've seen vis got stuck completely when using "unusual" levels (1-3). Therefore I strongly recommend only using fast and level 4 for normal operation.
If level 4 is too slow (298 hours *is* slow ...) and you won't settle for fast vis (which is recommended for maps with very open nature), then I suggest looking for the standard methods; vis blockers, func_walls for detail brushes etc.
With my version of RVis you have an extra indicator "max leafs visible" for help tracking down spots with high r_speeds. Normally, the long vis processing times can be *significantly* reduced by doing some small changes to the map and with only minor appearance effects.
Remember, long vis processing times is normally an indication of vis failing completely, not that it will do a good job. If you don't want to change the map, then settle for fast vis or even *no* vis if the map is open enough, i.e. arena-like.
If you need help with the map, just let me know.
Func_walls For Detail Brushes..
#120 posted by . on 2003/03/18 08:28:18
Elaborate - what's the advantage?
Func_walls
#121 posted by Kell on 2003/03/18 08:50:36
Detail refers to any solid, visible architecture ( so that exculdes clip and triggers ) that doesn't complicate the compile process' divisions of the 2D surfaces and 3D spaces.
Example:
If you have a flat wall with a thin light fixture ( like the square plate with a gothic cross light ) then the wall, despite being only a single brush, will be fragmented into several surfaces around the light fixture. Also, volume of space around that feature will be divided up into several smaller volumes to fit around the protruding metal plate.
By making the light fixture 'detail' it no longer interupts the compiler's cutting-up of your .map, so it can use far fewer surfaces; the wall might consequently be made of only 2 or even 1 surface.
Quake 2 and 3 both have detail as an option; Quake 1 and Half-Life do not.
Using proper Q2/3 detail makes the light fixture solid to movement and lighting, but invisible to the division process.
In Q1 and HL, you can get a similar effect by making the light fixture a func_wall. This is because brush entities do not interupt the dividing up of you map during compile: they don't vis block.
Doing this has 3 drawbacks though -
1. They don't block vis, which can be a problem with some features/layouts.
2. Brush entities, including func_walls, do not stop light during the compile. So the wall mounted light fixture wont have a nifty shadow around it :(
3. There's a limit to how many brush and point entities you can have in a map, including how large they are. I discovered this to my cost when building Part III of Contract Revoked, what with all them teleporters. I believe CZG used a lot of func_walls for detail in, IIRC, Insomnia.
Heretic + Worldcraft
#122 posted by Dochist on 2003/03/18 10:21:45
is there a fgd (is that the right name? me forgets) so i can do some heretic2 mapping in Worldcraft v1.6??
#123 posted by necros on 2003/03/18 17:08:00
If level 4 is too slow (298 hours *is* slow ...) and you won't settle for fast vis (which is recommended for maps with very open nature), then I suggest looking for the standard methods; vis blockers, func_walls for detail brushes etc.
actually, it's the other way around... the level 1 estimation was 298 hours, i just completed a level 3 vis and it took 8 1/2 hours... that's mostly what i was trying to understand-- how a lower level vis could take longer than a higher level one.
thanks for the other explanations though. :)
Necros:
#124 posted by metlslime on 2003/03/18 17:20:32
vis works by flowing through the level from each leaf -- sort of like the paint bucket tool in a paint prog, except that it does line of sight tests as it flows.
higher vis level settings will make the line of sight tests more stringent, which takes longer per test, but it also means that the test is more likely to fail. The sooner vis decides you can't see down a certain winding hallway, the sooner it can stop flowing down that hallway. This is how higher vis levels can sometimes be faster.
Oic Now.
#125 posted by necros on 2003/03/19 20:47:04
thanks, metlslime. that cleared it up nicely. :)
Oh Rats!
#126 posted by necros on 2003/03/20 17:28:51
so, i'm adding my monster into my map using gtkr... and i think: "man, this is too hard. i'll make these monsters only appear in hard!"
i open the entity dialog, and find there isn't a way to change the skill settings for entities! how do you do it in gtkr?
Spawnflags
#127 posted by nb on 2003/03/20 20:14:37
256 - not in easy
512 - not in normal
1024 - not in hard
2048 - not in deathmatch
You can probably alter the entity def file or whatever they use nowadays to include this.
Say I Didn't Want It In Hard Or Easy...
#128 posted by necros on 2003/03/21 22:01:29
i would add the two up, right?
so spawnflags would be 256 + 1024 = 1280?
how do you change skill settings for other games that are sp? (like Wolf and stuff)
Title Goes Here...
#129 posted by nb on 2003/03/21 22:31:46
Yes, and I don't know.
Hmm
#130 posted by Vodka on 2003/03/21 23:39:07
the correct enteties.def file should give you all the flags in editor
?
#131 posted by necros on 2003/03/22 19:27:35
could someone send me the .def file for a sp game please? (wolf3d or the like)
Necros
#132 posted by Vodka on 2003/03/25 22:50:32
I think all the skill setting flags were removed from GTK ( I was wrong - they are editor thing and are not stored in entities.def)
But they are still present in Q3Radiant 202.
You could use that to place monsters.
Mapping Tutorial
#133 posted by Vodka on 2003/03/25 22:59:19
Clip and skew, rather advanced, but should be easy to get it. Check out
http://www.planetquake.com/speedy/tut_pipe.htm
However...
#134 posted by metlslime on 2003/03/25 23:04:45
they COULD be added to the entities.def. QER just happened to have them hard-coded in.
Bleh...
#135 posted by necros on 2003/03/26 19:43:57
unfortunatly, i don't know how. :/
i'll probably try using q3rad 202 then, to add the skill flags...
just to check, but the q2 skill flags (which i assume are the ones were talking about) are the same bits as the q1 ones, right?
|
|
You must be logged in to post in this thread.
|
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.
|
|