Interesting
#11398 posted by necros on 2011/08/12 23:25:51
i did a little bit of testing on this issue.
1. yes, it also occurs in FQ085.
2. it wasn't actually that the map had >512 sounds.
what seems to happen is that, when loading a new map, the engine doesn't flush the precaches or something. the reason it crashed before was because i was loading it from the console after another map had already been loaded.
if i start the map up first, from scratch, it's fine.
if i try to load another map that uses a large number of sounds, it will crash.
this sounds like not a big deal at first, but it means that you can't have a map pack with more than 1 map that uses many different sounds. :(
Oh
#11399 posted by necros on 2011/08/12 23:26:26
and looking forward to see the map then, jpl. :)
#11400 posted by raptorE on 2011/08/14 21:56:57
What would happen if you load a map with many sounds, then a map with few sounds, and then another map with many sounds?
Just an idea.
That's My Point
#11401 posted by necros on 2011/08/14 22:08:22
eventually, if you, say, had 512 maps, each with 1 unique sound, it would end up crashing.
if, as i believe, the precaches are not being cleared, then every map that adds any extra unique sounds will bring the crash that much closer to happening.
Of Course
#11402 posted by Preach on 2011/08/15 00:24:08
The problem is often masked simply because practically every mod to date has
a) offered no means to import custom sound into a map and
b) contains fewer than 512 sounds itself
So it's likely a bug that has long survived in practically every source port of the engine...
Yes
#11403 posted by necros on 2011/08/15 00:42:02
i'm certainly not blaming anyone for not noticing it.
Glass
#11404 posted by jt_ on 2011/08/17 18:59:06
Is there any way to have glass in current engines?
Heh - RMQ Engine - Func_wall + "alpha" Key "0.#"
#11405 posted by RickyT33 on 2011/08/17 19:11:08
Quoth - make a func_wall, give it a texture called "skip" (Use newskip.exe after compiling), make a waterbrush in the same place as the func_wall, give it a water texture with a flat grey or white colour. Use a trigger_command to set "r_wateralpha 0.#" on mapload.
Cannot be done in vanilla progs without the player having to type a wateralpha value into the console.
RMQ Progs
#11406 posted by RickyT33 on 2011/08/17 19:12:42
Will have breakable glass. func_breakaway FTW.
Im Sure Some Of The Engines Support Transparency
#11407 posted by RickyT33 on 2011/08/17 19:17:17
On bmodels though. FitzQuake i think? Just set an "alpha" key on a func_wall - is the easiest way, and probably better than the water hack, because there is no waterwarp on a func_wall or other bmodel unless it has a water texture. GlQuake will do wateralpha, hence the water hack's universal compatibility. But you can have a nice glass texture is you use the alpha key.
RMQEngine
FitzQuake?
Darkplaces?
DirectQ?
#11408 posted by necros on 2011/08/17 20:01:57
http://necros.slipgateconstruct.com/temp/split.jpg
i've mostly just ignored this kind of thing as down to the way bsp works... but is there any way to reduce or eliminate this seemingly needless poly splitting?
in the shot, the rock path is made up of 3 brushes per segment, the large center bit and the two small side bits, all 3 are split into tris. in theory, since none of the faces are larger than 240 in any direction, qbsp should have never split them at all, and just left them the way they were in the editor.
instead, you get that weird split in the center brush that runs up the slope until it meets the right-hand side where there are all these tiny little tris.
every compiler i've tried makes the exact same shape.
this is what it looks like in the editor, for reference:
http://necros.slipgateconstruct.com/temp/split_ed.jpg
am i just missing something?
Append
#11409 posted by necros on 2011/08/17 20:07:49
ok, in true necros fashion, i figured a little more out right after posting... -_-
it seems this has to do with how similar the planes are between those brushes. there's a setting in aguirre's txqbsp -epsilon that you can set to smaller to have more precision on identifying unique planes which reduces the unnecessary splits.
looks like if a plane is similar enough to another plane qbsp thinks they're the same plane(?) and tries to split it or somesuch.
unfortunately, even at smallest settings, it doesn't completely remove the extra splits. i think there must be a lower bound built into the compiler, since values smaller than 0.001 had no noticeable effect.
I Think..
#11410 posted by JPL on 2011/08/17 23:29:38
.. you should directly contact aguirRe for this. He will certainly be really happy to help you ;)
It has indeed something to do with precision in clipping Hull (Hull 1 ?).. I've seen several test map compiled with different epsilon, and the lower it is, the better the rendering is (i.e smoother planes, less "corners").. though... it seems to not be valid for all maps..
Some quotes from aguirRe's TxQBSP readme file give a little bit more details
Improved handling of complex maps such terrain. This is done by increasing precision when identifying unique planes (faces) and modifying hull expansion logic. This reduces the risk of clipping errors and creates much smoother clipping hulls which can help player/monster movements.
All maps don't benefit from this, therefore two new options have been introduced; "-oldexpand" which just disables the new expansion logic and "-epsilon x" (default 0.01) which sets the plane identifying tolerance. To revert to previous compiler behaviour, just add options "-oldexpand" and "-epsilon 0.05".
The default settings have been chosen for overall best results. If you have a big map that still doesn't build correctly, you can try lowering the epsilon even more, e.g. 0.001. In most maps the default settings have little effect on # clipnodes, but some maps can see either a significant increase or decrease. Thanks to Tyrann for this one.
I hope it clarifies the stuff ;)
Not Really
#11411 posted by necros on 2011/08/17 23:38:39
you just cnped the text from his website. that's how i found out about -epsilon. :P
Necros
#11412 posted by JPL on 2011/08/18 09:37:01
... hence I suggested since the beginning of my post to directly contact aguirRe ;)
#11413 posted by roblot on 2011/08/18 14:42:10
If the -epsilon factor has to do with with monster/player clipping hull adjustment, then JPL's post makes sense. I think I now know why sometimes a player gets stuck on some brushwork ingame. It's sometimes not bad brush alignment, but maybe odd hull expansion the player gets caught up on.
#11414 posted by gb on 2011/08/18 18:32:31
Personally I think what you're trying to do is overkill, to be completely honest. How many people are going to appreciate the little subleties of the corridor floor, especially when it's all plastered over by a low-res rock texture?
Maybe there's an easier way to get the same effect that uses less brushes and generates less splits.
Ideally you'd do this in a model editor and then import it into the map and fake collision somehow.
Necros
#11415 posted by RickyT33 on 2011/08/18 19:38:05
You could make the floor-trim into a func_illusionary. This would make the floor a lot less complex, but there would be little or no visual difference because the floor trim cannot cast a shadow anyway.
#11416 posted by necros on 2011/08/18 20:07:13
i experimented with -epsilon more and the original change i saw didn't have anything to do with it, but rather some change in geometry in another place that affected the spot i was looking at.
from what i can tell, -epsilon does absolutely nothing! i tried with settings of 0.5 and 0.0001 with absolutely no change in geometry.
i think the changes are very subtle and will only show up on a large, completed map.
hence I suggested since the beginning of my post to directly contact aguirRe ;)
yeah, i think i will now that i've had more time to look at it. :)
Personally I think what you're trying to do is overkill, to be completely honest. How many people are going to appreciate the little subleties of the corridor floor, especially when it's all plastered over by a low-res rock texture?
/shrug this is what i appreciate in maps, so it's natural that i'd do it in my own mapping process. subtleties, for me, is what makes a map great. if you walk up to a cliff and you see the edge has been beveled and there are chips taken out of it, that, to me, is far far more impressive than someone just making a flat cliff with a 1024x1024 texture.
Is there a command to force VIS to cut off at a certain distance (which would be hidden by fog)? Can't find my copy of the tools readme :(
#11418 posted by Spirit on 2011/08/30 19:56:04
hmap2 has -farplane
#11419 posted by necros on 2011/08/30 21:04:20
tuna's fixed version of willem's modified version of aguirre's vis has -visdist #.
yeah, i totally just wanted to type out that line. ^_^
Trying To Compile A Quake Map W/ Win7
#11420 posted by biff_debris. on 2011/08/31 00:01:23
And everything seems to be going well except for the old "no textures in game" crap. Yes, I've got a worldspawn key for the texture wad, and I've put the damn wad in the id1 directory, the id1/tools directory (with the compile tools) and in the /id1/maps directory (with the maps) -- no dice. Any flashes of wisdom would be appreciated.
Win7
#11421 posted by raptorE on 2011/08/31 00:05:39
Which compilers are you using?
Hi Rap =D
#11422 posted by biff_debris. on 2011/08/31 00:19:19
Using Tyrann's stuff at the moment.
|