 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
This is a C/Qc issue caused by the hull navigation.
You can solve it with an entity called a func_nodraw from the extras mod: http://www.quakewiki.net/quake-1/mods/extras-r4/ Coding one from scratch should be trivial since you just set the model to empty on runtime, I think. All it does is make a solid brush that you can't see. It's not ideal because you can't shoot through it - but that's the limitation of Quake. Minlight for entities would be awesome. Q2 has this and it makes life a little bit easier every time you add a door to a map. <quote>* Brush models (func_ entities) can have a minlight value so that there is no solid black surfaces. It is easy for a secret door to have a solid black surface on the opening edge, which is difficult to get rid of. No one wants to minlight a whole level but certain entity types could benefit from a minlight boast. </quote>
Ooh, nice idea! That would be mega useful. * AI clip brushes, a surface that is invisible like clip but can block AI/Players. At the moment all floor gaps need func_wall entities so that AI can walk across the gaps properly. For some reason clip brushes are not in the clip hull that the AI movement code uses.
To be more specific about what the map compiler does which causes problems - the clip brushes get added to hull-1 (player size) and hull-2 (shambler size), but not the visible hull or hull-0 (point sized). I'm pretty sure that the visible hull and clipping hull-0 are stored separately in the BSP (but please correct me if I'm wrong). If that's the case, then it should be possible to create clip brush variants where the brushes are considered in different stages. So for example super-clip brushes would be skipped at the visible stage, but included in hull-0 to hull-2, so grenades bounce off them and monsters can navigate them. It certainly ought to be possible to create sub-clip brushes which only affect hull-2, to prevent large monsters getting into parts of the map but allowing players in. Entity minlight - Easy. Will add that.
The AI clip thing, don't think it's possible. The thing is that Hull0 *is* the visible hull. There is no separate clipping hull for point size entities, they use the same bsp tree that the renderer uses. It should be doable, but the information about which brushes are grouped are lost after the BSP has been produced, so can't use that as a basis.
A tweakable command line parameter (or worldspawn key) to set the maximum angle between two surfaces to consider for phong shading/smoothing should work and I believe there are Q2/Q3 tools that did this (though I forget the name now). Could also restrict it to faces with the same texture as well if that seems like a useful thing to do. recommend you call it "_minlight" since the engine automatically ignores keys that start with an underscore (this is so you can add new fields for the compilers that don't have to be in the progs.dat definitions list.) Otherwise players will get spammed with "minlight is not a field" messages.
Hmmm...some way of specifying it to only use phong shading on faces that use certain textures might be a good idea...
Whilst we're all in crazy wishlist mode - what about an option for brush entities to cast shadows (on the world and other brush entities) @Tyrann, doing phong shading on surfaces with the same texture would be awesome. Another option is to use a keyword in the texture name. Maybe you can specify the keyword as a parameter.
Example command line : "-phong terrain" Textures containing the word "terrain" have phong shading applied to their edges. Having the _minlight key on any entity would be awesome, I can think of plenty of situations where that would be handy. Or have it identify with certain texture names? Like how fluids begin with an * or animated textures begin with a + ?
If we have phong shading and minlights we could emulate Quake 3's shading on curves really accurately? This would be amazing!
I already use anglesense, but unfortunately it is applied to everything which makes it difficult to fine tune.
The AI clip thing, don't think it's possible. The thing is that Hull0 *is* the visible hull. There is no separate clipping hull for point size entities, they use the same bsp tree that the renderer uses.
Ah, was worried you'd say that. Still, if we can have brushes that are both skip AND detail, we can fake it. Imagine we're just trying to create 1 solid transparent window in a visible square frame. On the front of the frame we make a square based pyramid, so that the four vertices of the base meet the vertices of the frame, and the point of the pyramid points backwards. This brush doesn't clip away any of the inside of the frame, because it only touches the edges of the other surfaces. Make it skip and you've got an invisible hull-0 face. You can already do this much with the existing skip tool. Naturally the next thing would be to make another brush on the back of the frame, so the window clips correctly from both sides. The problem to date is that sealing the area on both sides causes it to be clipped away. Even if one side is left open, VIS believes the skip brushes are opaque and starts culling the inside of the frame when looked at from the front. I think that making these brushes details as well as skip ought to fix both problems at once - but I should probably put my money where my mouth is and try it! Is it me or Wine or does this vis totally kick wvis' ass?
I just vis'd EvilExhumed.bsp in 70 seconds with this vis, but with wvis in wine it took 12 minutes! Let's do some benchmarking in any case, I always wanted to do that.
https://www.quaddicted.com/tools/vis_benchmark Damn link abbre.....
That link above invites you to run some VIS on gmsp3v2.bsp and has a table where you then can add your numbers. [quote]I just vis'd EvilExhumed.bsp in 70 seconds with this vis, but with wvis in wine it took 12 minutes! [/quote]
Srsly? Damn, that's great! I wonder what he did to his version Jesus FUCK with this non-standard tags...
I just vis'd EvilExhumed.bsp in 70 seconds with this vis, but with wvis in wine it took 12 minutes! Srsly? Damn, that's great! I wonder what he did to his version I added qfvis and bjp to the wiki page.
Could someone make a bat file that runs it all without the need for interaction? The only parameter the user has to supply is the number of threads for qfvis, the other tools pick them themselves. Is this some additional thing on top of normal vis? If not you could run it with necros compiling tool without having to mess around with batch files?
If some Quake 1 tool gets phong shading, Q1 mapping would suddenly look more attractive again.
Higher resolution lightmaps? :-p
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |