 News | Forum | People | FAQ | Links | Search | Register |
Log 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 tyrvis
---- TyrVis v1.0 ---- running with 4 threads BSP is version 29 4040 leafs 10656 portals Calculating Base Vis: 0....1....2....3....4....5....6....7....8....9.... Calculating Full Vis: 0....1....2....3....4....5....6....7....8....9.... average leafs visible: 181 c_noclip: 0 c_chains: 158170515 visdatasize:282459 compressed from 2040200 Writing BSP version 29 144.0 seconds elapsed ================================= ---- WVis 2.31 ---- Modified by Bengt Jardrup Multithreading enabled by Willem File: gmsp3v2.bsp 4040 portalleafs 10656 numportals testlevel = 4 Using 4 threads. average leafs visible: 176 max leafs visible: 518 near (384 2240 -768) c_chains: 113742805 visdatasize: 270 kb compressed from 1992 kb Elapsed time : 4:00 ========================================== qfvis i gave up after 15minutes -------------------------------- specs - i-760 -4gb ram -win7 x86 average leafs visible: 181
average leafs visible: 176 That's interesting. I wonder what the difference is...
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |