 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
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... Spy, thanks! I guess that is a "i5 760", correct?
qfvis seems to get stuck (or it is ultra slow) for some reason, I'll tell taniwha. I noticed that vis leafs difference too, different methods? could look really cool in Quake. I know valve added AO to the light compiler for CS:GO maps so maybe that would be somewhere to start looking? I have no idea :P
That is interesting. I'm not aware of anything in my vis that should give a different result. It could just be a floating point precision thing, but I suspect it's more than that. I'll look into it at some stage, but it will be pretty tedious.
Maybe a moderator could update the post above, rather than a new annoucement?
Quite a few new features here, thought people might rather have some of this stuff now while playing around with Trenchbroom (func_group in particular): TyrUtils v0.6 changes: qbsp: respect floating point texture rotation and shift in map files qbsp: support for Valve's 220 map format used in later Worldcraft/Hammer qbsp: support func_group entities used by Radiant and similar editors qbsp: surfaces with the skip texture are now removed from the compiled bsp qbsp: hint brush support similar to Quake 2 for hand-tweaking the PVS qbsp: fixed a problem where leak files were not written for hull0 or hull1 light: fixed a race condition in multithreaded coloured light processing light: fixed bug preventing use of all 4 light styles in a common case light: implemented attenutation formulae "delay" 4+5, ala Bengt's tools light: removed old bsp30 support light: lit files now automatically generated when coloured lights detected light: implemented 4x4 oversampling with -extra4 command line light: implemented the -gate option to help speed processing (default 0.001) light: implemented the "_softangle" key for spotlights light: implemented minlighting for brush models Announcement Download: Windows, Mac OS X, source.
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |