 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
What was once one slightly boring post in a previously interesting thread is now eight very boring posts. Actually, now it's nine because of me.
I like TrenchBroom because it's cool. Nope. Just you, Willem, and mfx. Everyone else is fine. But, you two, yes, you two have already had your 5 strikes. Yes, 5 strikes, not 3 strikes. I gave you 5, and you've used them up already, here and in other threads. 5 strikes; that's how much patience I gave.
Good day. 1. please read this carefully:
http://en.wikipedia.org/wiki/Superiority_complex 2. calm down already. 3. stop posting irrelevant bollox in this sacred thread. Nope. Just you, Willem, and mfx. Everyone else is fine. But, you two, yes, you two have already had your 5 strikes. Yes, 5 strikes, not 3 strikes. I gave you 5, and you've used them up already, here and in other threads. 5 strikes; that's how much patience I gave.
http://cdn.crushable.com/files/2012/07/jlaw-okay.gif Could find func_detail in trenchbroom...
func_detail seems to be not included. Has someone a working Quake.fgd with func_detail support for trenchbroom? The included
The included
Not exactly mmh - the result is not that what i expected.
uncommented the func_detail, made a boxed "testchamper", placed some irregular/complex brushes in it and compiled with tyrann's tools = still got a messed up (highly splitt/weirdly triangled) bsp (r_showtris 1) Vis may have been faster.. Maybe i'm betting on the wrong horse. :-) How do i prevent irregular brushes to splitt the bsp then? i thought func_detail would be the right way. Func_wall 'em? enlight me. In Quake, detail brushes only speed up the vis process. Apart from that, they are treated like normal world geometry. If you want to avoid splitting, you'll have to make it a func_wall.
Thanx.
Seems that my hl and q3 based memory tricked me. i stopped mapping for ages, restarted with trenchbroom 'caused it feels nice to work with. Great job btw. Love it. I'm noobish and ignorant, but is there any reason to not simply use func wall for details like that?
func_walls are entities and come with several issues. like OTP said, no shadows. Also, stock engines have limitations on edicts and models present in a bsp, so using lots of them (or in a larger map) can lead to needing to perform balancing acts if you want to stay under those limits.
func_details are not actually entities, despite being used like them in an editor. They are world geometry, and cut the world geometry as normal, but are not considered while calculating the PVS. Having the _shadow and _selfshadow keys to make the features opt-in makes a lot of sense - because the compiler can't tell if the entity class is meant to be static, to slide or to rotate (well, it might have some hints about rotation but still). But how would people feel about fgd/def files which add the keys by default - for example to add "_shadow 1" to newly created func_wall, and "_selfshadow 1" to func_train?
Those at intermediate level will know how to disable it.
Last thing about func_wall - they only draw if vis believes the player can see them, so if they stretch through several leafs then they will go invisible in stock engines, depending on where you're stood.
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2025 John Fitzgibbons. All posts are copyright their respective authors. |