Func_Msgboard: Real-Time Vis = How?

Posted by Baker on 2015/01/13 07:45:13

Interpret byte-code. No problem. Unwind brushes. Ok. Point-polygon collision? At the end of the day, that one isn't so hard. Physics, manageable.

Real-time vis? I don't even know how to begin to develop a plan for that.

Yet somehow has to know how this can be done, Saurbraten did it, right? What are the fundamental concepts in developing a strategy for visibility?

First | Previous | Next | Last

#1 posted by ericw on 2015/01/13 09:25:57

Fabien Sanglard's doom3 code review has some interesting stuff on that:
http://fabiensanglard.net/doom3/renderer.php
Not really sure how state of the art engines do it though.

#2 posted by mh on 2015/01/13 10:00:37

You could do something with hardware occlusion queries.

Beware that vis data is needed on both client and server. The server uses it for determining which entities to write to the client, but also for line-of-sight target checking in PF_newcheckclient and PF_checkclient.

Easy,

#3 posted by beyon on 2015/01/13 10:44:15

just render everything!

Is the question how to do Quake-vis in real time or more general? Saurbraten obviously uses different data structures...all depends on what your goal is?

How State-of-the-art Engines Do It

#4 posted by mh on 2015/01/13 13:15:13

Culling the Battlefield: http://www.slideshare.net/DICEStudio/culling-the-battlefield-data-oriented-design-in-practice

Uses software rendering to a low-resolution depthbuffer with artist-placed low-resolution occlusion geometry in order to determine what's visible and what's not. In other words that's not something you're going to be able to do with existing content (and I can confidently predict that you'd meet some resistance from mappers if you were to suggest them building occlusion geometry for new content too).

#5 posted by JneeraZ on 2015/01/13 13:18:31

I don't know about that ... I think many mappers would build occlusion geo if the offset was they didn't have to spend 60 hours running VIS.

Occlusion Geometry

#6 posted by oh, that person on 2015/01/13 13:20:46

Is that anything like hint brushes?

Just Use Detail Brushes And Tyr's Compilers

#7 posted by Kinn on 2015/01/13 13:30:41

Rendering Everything

#8 posted by SleepwalkR on 2015/01/13 14:28:25

is a viable option though. I do it in TrenchBroom and get 60 FPS even on large maps. I don't think that adding light maps will make much of a difference, but dynamic lights might pose a problem.

#9 posted by Spirit on 2015/01/13 14:53:55

Wouldn't all the entities being visible and active be a problem?

Wot Spirit Says

#10 posted by mh on 2015/01/13 15:28:03

I mentioned this above, but PVS is not just used for rendering. Without PVS you'll also be sending all entities to the client each frame, and line of sight testing for targetting will also always succeed. You may be able to get away without PVS for rendering in a map editor, but you almost certainly can't get away without it for the latter two in the actual engine itself.

#11 posted by JneeraZ on 2015/01/13 15:41:14

I'd wager it wouldn't matter all that much in the end. How many entities are actually doing anything each frame? Most monsters are standing around waiting for the player to show up. Everything else just animates statically.

So, really, how much additional network traffic is there going to be?

#12 posted by JneeraZ on 2015/01/13 15:41:52

Err, by animates statically I obviously mean animates but doesn't move. :P

First | Previous | Next | Last

You must be logged in to post in this thread.