#12 posted by JneeraZ on 2015/01/13 15:41:52
Err, by animates statically I obviously mean animates but doesn't move. :P
Most monsters are standing around waiting for the player to show up.
Not in a Tronyn map...
What Problem Are We Trying To Solve Here?
#14 posted by Kinn on 2015/01/13 16:24:20
Is it vis compile times?
Yes...
#15 posted by Scragbait on 2015/01/13 16:48:03
For me, VIS times on most of my Travial maps was beyond brutal and VIS ran for days. But I was also using a 1.3GHz Pentium 100. I added to the problem by designing maps without respecting the engine and its limitations. The burden of long VIS times cut into time and machine resources that could have been used for further creative work.
Ok
#16 posted by Kinn on 2015/01/13 16:58:18
So have you tried using func_detail and tyrann's tools?
Yeah
#17 posted by ijed on 2015/01/13 18:04:50
If vis takes longer than a couple of hours then you either need to update your tools, learn how to use them properly or both.
And, as Mh says, without PVS all enemies will wake on map start.
#18 posted by gb on 2015/01/13 18:07:53
Or even Q3BSP and manually creating portals.
OK, OK, I'll stop it.
#19 posted by mh on 2015/01/13 18:11:30
How many entities are actually doing anything each frame? Most monsters are standing around waiting for the player to show up.
And how do they know that the player's shown up? By doing a vis test, that's how (like I said, look at PF_checkclient and PF_newcheckclient, both of which use the PVS). So if you run with the "just draw everything" approach, ignoring vis data, then that vis test will always pass. And then they're no longer just standing around doing nothing.
Network Traffic
#20 posted by mh on 2015/01/13 18:12:29
Testing e1m2 with protocol 666, the network traffic difference is a factor of 10.
#21 posted by JneeraZ on 2015/01/13 18:37:57
"And how do they know that the player's shown up? By doing a vis test, that's how (like I said, look at PF_checkclient and PF_newcheckclient, both of which use the PVS). So if you run with the "just draw everything" approach, ignoring vis data, then that vis test will always pass. And then they're no longer just standing around doing nothing."
Sure, but then you come up with a different method. :)
I'm just noodling around the ideas here. I think VIS was great 20 years ago ... not sure there aren't better solutions these days.
#22 posted by JneeraZ on 2015/01/13 18:39:59
"Testing e1m2 with protocol 666, the network traffic difference is a factor of 10."
This only affects people playing across a network and ... well, I guess both of them would have to find a new hobby or something. :P
#23 posted by JneeraZ on 2015/01/13 18:43:08
I guess where my brain is heading is a thinking exercise for engine programmers ... what if VIS didn't exist? Go.
#24 posted by Kinn on 2015/01/13 18:51:45
I guess where my brain is heading is a thinking exercise for engine programmers ... what if VIS didn't exist? Go.
Just to be clear are we talking about something that requires no pre-processing step? Also, how much work should the designer have to do?
#25 posted by JneeraZ on 2015/01/13 19:00:48
I don't know. I think anything is fair game ... LDs placing portals or totally automated. It's just interesting to think about.
#26 posted by Kinn on 2015/01/13 19:05:23
I always thought Doom 3's system was pretty decent - designer places the portals, and the compile time is measured in seconds.
Although
#27 posted by Kinn on 2015/01/13 19:11:40
concerning bsp portals, the phrase "good luck with that" comes to mind once you get into the realm of Tronyn-style monstrosities (and I don't mean that word in a negative way).
#28 posted by Lunaran on 2015/01/13 21:28:20
kinn, doom3's system is fucking horrible. try portaling anything that isn't room-corridor-room and there's no fucking way.
Run the existing vis algorithm as the map is played? In the first few unrendered spawn frames, vis only the leaf the player is in, assume all other portals closed. All the right monsters will still wake up, because portal visibility is a symmetric relationship. Keep up with the player's current position vising one leaf at a time as he runs around, use any spare frames to follow the bsp structure outward to try to keep ahead of him. Cache it all to the same PVS structure. Areas that players or monsters never go will get skipped naturally.
Then, if you've still got a poorly build monstrosity of stupidity that would have taken six hours to vis, the framerate will just be bad :P
#29 posted by Kinn on 2015/01/13 21:48:35
kinn, doom3's system is fucking horrible. try portaling anything that isn't room-corridor-room and there's no fucking way.
I guess it is. I never tried doing anything fancy (layout-wise) when I was tarting about with D3.
Lol
#30 posted by Tronyn on 2015/01/13 22:32:07
this thread is awesome... it's probably my utter lack of knowledge on this subject that makes my maps such technical problems for vising (and despite the time-sink of trying to finish a degree, I hope to put out a couple more visbreakers yet...).
I Had An Idea Once...
#31 posted by mh on 2015/01/13 22:57:27
...to run vis using hardware occlusion queries at load time, rendering to a lower-res offscreen surface (you'd actually need a cubemap (or 6 renders) because vis is agnostic to orientation), which should have substantially speeded things up, as well as successfully dealing with map layouts that aren't amenable to the standard software vis.
A typical modern GPU that can handle Quake at 1000+ FPS should easily be able to crunch through most maps in seconds. The whole "portal flow" paradigm just doesn't scale, and the simpler option of "build a depth buffer and do a depth test" is more robust in the face of geometric complexity in a way that portals aren't.
The only gotcha lies in the fact that occlusion queries work from a single point, whereas leafs occupy a volume.
Even so, and if this can be overcome, an offline pre-processing tool using this idea should also work, and remove all of the burden of long vis times.
But the real appeal of run-time vis is being able to dynamically move around large sections of the world and still have valid visibility. Load-time or even accelerated pre-processing would lose that.
#32 posted by Lunaran on 2015/01/14 04:55:27
And since we don't have dynamic sections of the world moving around ...
Slightly Related
#33 posted by mh on 2015/01/14 11:37:49
Since we're talking about dynamic stuff moving around, Quake 2's areaportals system would also be a useful addition to Quake, and would give you a good starting-point for run-time visibility.
That I Would Like
#34 posted by Lunaran on 2015/01/14 18:05:24
although, designwise, areaportals are a poor substitute for static limitations in visibility. An areaportal is only a good idea when the player for whom visibility is being limited is the one opening the door. If the thing that's stopping you from seeing into the next room and getting slow performance is just one door, and a monster comes through it while you've got everything in view, for at least part of the time that door effectively isn't there and performance is as bad as if you'd just left it open.
Whenever I get annoyed that I have to still build some kind of visblocker on one side or the other of a door, I remember that that's better design anyway and the lack of areaportals is simply reminding me of that.
Q2 Bsp Format
#35 posted by qbism on 2015/01/15 18:58:50
Surface flags instead of alpha entity, r_whatever alpha, and texture naming hacks. Also external textures.
On-topic: DP has built-in vis? Not sure if orealtime.
#36 posted by Spiney on 2015/01/22 13:32:16
|