 |
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|||||||||||||||||
Add Forum to Favorites | Send Topic To a Friend | View Forum FAQ | Track this topic |
Last Thread Next Thread |
| Super Frustums |
|
 |
RamboBones Member since: 9/23/2002 From: Blacktown, Australia |
|||
 Posted - 11/3/2003 2:31:00 AM |
||||
| The only problem I can see with the super frustums are if the person starts swinging the camera around very fast, like spins 180 then spins back 180. With a nice big bounding matrix you don't have that problem, and even if you do move you only have to load at MOST xsize+ysize-1 tiles and since they will be further away if they don't get loaded it won't be noticed as much. |
||||
|
||||
|
Anonymous Poster |
|||
Posted - 11/3/2003 3:58:51 AM |
||||
| Hrm; for starters, prefetching that little amnount of data does NOTHING AT ALL. So the argument about prefetching is not valid. Another thing that somewhat bugs me is the fact that the frustum has to be enlarged in order for this to work. There's another method out there which uses the frustum EXACTLY and it works. It does not miss any borders and only the visible polygons are rendered. Maybe I missed something, but there doesn't seem to be anything mentionned about projecting the frustum to the terrain. Wouldn't that be faster? The other method does so <shrug> At least from a CPU poinbt of view it is faster. Just my 0.02$ |
||||
|
||||
|
Penance Member since: 5/15/2002 |
|||
|
Posted - 11/3/2003 9:30:04 AM |
||||
| I'm confused about the point of the article. No references are mentioned, so is this an original technique conceived by the author? If so, some source code would have been cool. Otherwise references are in order. |
||||
|
||||
|
adiash Member since: 12/14/2002 From: Israel |
|||
|
Posted - 11/3/2003 9:40:33 AM |
||||
| Having seen one or two thesis in my life I must say that this is one of the most poorly written one I have ever seen (scientific-wise). I make no claim against the validity of the "super-frustum", but I have some remarks: 1.How about some benchmarking? (high medium and low is not really detailed enough) 2. I could think of a hardware configuration where one method is preferable and vice versa. 3. There are clearly advantages and disadvantages to this method. Pointing out only the advantages and choosing the most convenient environemnt for the purposed algorithm like this is a product presentation is very inappropriate. Am I just being harsh, or did you also feel "cheated" by this article? ____________________________ I rather sprintf than sprint |
||||
|
||||
|
apanjocko Member since: 10/14/2003 From: sweden |
|||
|
Posted - 11/3/2003 10:13:53 AM |
||||
| you are not harsh, it has to be backed up by something, at least code. |
||||
|
||||
|
Anonymous Poster |
|||
Posted - 11/3/2003 11:14:46 AM |
||||
| This should have been a sweet snippet or something...anyone can just have an idea like this and say it's worth an article. |
||||
|
||||
|
GBGames Member since: 1/25/2001 From: Chicago, IL, United States |
|||
|
Posted - 11/3/2003 11:21:16 AM |
||||
| I also feel like something was missing. Naturally if this was the optimal algorithm, wouldn't we find plenty of information on this elsewhere? Sources of any papers would have been nice. The original algorithm's title was at least provided, but what about the revision and this "Super Frustum" algorithm? Also, how about a list of games that might have used this or similar techniques? |
||||
|
||||
|
Anonymous Poster |
|||
Posted - 11/3/2003 1:21:07 PM |
||||
| Oh my... didn't anyone of you thought that point of article was not _speeding_ up rendering _but_ to *optimize* RAM usage. |
||||
|
||||
|
jesterlecodeur Member since: 10/22/2000 From: France |
|||
|
Posted - 11/3/2003 1:53:59 PM |
||||
| Personnaly I use a LRU cache of cells (size depend on memory I give to terrain) and allow N cells to be loaded each frame (I didn't do multithread for now). If a cell need to be render but isn't in the cache I ask to load it, if I can't (N cells already loaded this frame). I have a demo here (it use FIFO not LRU so there is sometimes holes, but LRU will solve it): http://esotech.free.fr/pub/esoteric.rar I just wanna see some demo to check myself about author ideas. Well, but this article might help some people, a too small article is better than nothing. _______________ Jester, studient programmer The Jester Home in French [edited by - JesterLeCodeur on November 3, 2003 1:55:15 PM] |
||||
|
||||
|
noisecrime Member since: 10/2/2002 From: Leicester, United Kingdom |
|||
|
Posted - 11/3/2003 2:40:49 PM |
||||
| There is nothing new here, anyone who has looked into render large area terrains would have considered these options. However even though there is a lack of code or support material, the fact that these options are discussed will be useful starting points. In fact all of the techniques suffer from stability/de-synching at large rotation/movement rates, so extra care must be taken, which ever is choosen. However I rather suspect that option 3 is not the best. Sure it produces the minimum number of chunks to display and therefore reduces the memory overhead, but actually it requires so much more loading/unloading when the viewpoint rotates, even by small amounts, that performance suffers. In my own experiments I found option 2 to be far better. It loads more chunks, but for normal rotations it loads/unlaods far fewer. You can still use an exact frustum to ensure only those chunks viewable are actually rendered. You can see a demo of this here. http://www.noisecrime.com/develop/techdemo/dmx/terrainchunkengine12sw.htm It takes a short time to start up as it has to build the terrain normal map, just be careful of using the large map option (1024x1024), as that can take several minutes to generate the normal map! It has some useful features like indicators as to when chunks are being loaded and complete stalls. YOu can also play with the size of the grid to display etc. Its possible to get gaps if you use a large grid size or move/rotate very quickly. Idealy there would be some limites placed on the engine for these cases. But as this was a demo to test the idea, I avoided adding limits. One feature that isn't mentioned, is by pressing the SPACEBAR you get a birds eye view. This allows you to see the chunks as they load/unload. [edited by - noisecrime on November 3, 2003 2:42:27 PM] |
||||
|
||||
 |
Sneftel Moderator - Consoles, PDAs, and Cell Phones Member since: 7/7/2001 From: Philadelphia, PA, United States |
|||
|
Posted - 11/3/2003 3:46:50 PM |
||||
| I agree that the article's fairly short on useful info. "Load a few units in each direction outside the frustum" is a pretty obvious technique... not really worth giving it a name. I think the biggest problem, though, is the rotation issue mentioned before. It's hard to tell because of the lack of detail, but it doesn't look like much attention is being paid to the potential for a cache miss from a rapid, or even not-so-rapid, rotation. quote: Those two are extrema, between which a compromise must be reached. If you're trying to speed up rendering, you cache as much of the map as you possibly can, thus eating up all your RAM. If you're trying to optimize RAM usage, you just load the immediately visible areas, thus slowing down rendering with even the smallest move. This article attempted to find an efficient compromise, but IMHO the lack of attention to the effects of rotation rather dull its usefulness. How appropriate. You fight like a cow. |
||||
|
||||
|
Fingers_ Member since: 8/17/2003 From: Kirkland, USA |
|||
|
Posted - 11/3/2003 4:25:55 PM |
||||
| The best method depends on the application. In a flight simulator with fast speeds and limited turn rates you can probably optimize the RAM and HD usage by only loading what's (going to be) in view. On the other hand, if you're making a first-person walking-around game some version of the first technique is probably the best. The player might turn 180 degrees within a couple frames with a flick of the mouse, and it must not cause a framerate drop or visual errors. |
||||
|
||||
|
gimp Member since: 4/10/2000 From: Sydney, Australia |
|||
|
Posted - 11/3/2003 10:03:37 PM |
||||
| I'm glad that I found the other comments here started flaming before I did. My personal strategy: -Inner sphere. This is set to just ourside the max frustum depth to force the load of all octants needed. -Outer Sphere. This is a sort of distance based LRU cache expiry system. When an octant falls outside the outer sphere it is deleted from memory. I use this system to ensure that everything I may need will be in memory well before I need to draw it. However to stop the user walking around and paging the entire mapped area in to memory I have an expiry based on distance. When an octant gets too far away it and any static objects in it get purged(decremented) from the resource manager. As it happens my resource manager will only purge it if system available bytes falls below a certain point so even then it stays in ram. |
||||
|
||||
|
Zook Member since: 3/4/2000 From: Sweden |
|||
|
Posted - 11/4/2003 6:46:34 PM |
||||
| I found this article interesting. Would have been good with some explanation of the implementation of the algoritm though. |
||||
|
||||
|
bortx Member since: 8/1/2003 |
|||
 Posted - 11/12/2003 11:09:32 AM |
||||
| hi, i'd like to answer most of the things that have been said about the article... 1. "The only problem I can see ... swinging the camera around very fast".sure.this algorithm was conceived and implemented in a flight simulator context (no source code can be given obviously) not in a 1st person shooter game context. 2."prefetching that little amnount of data does NOTHING AT ALL".false. it does. it prevents from having data not loaded when rendering, and a pc is not fast enough to load a 1024x1024 texture from disk in one frame.THE ALGORITHM TALKS ABOUT LOADING NOT RENDERING. 3.no references are given because, as far as i know, it's an original algorithm. 4.this article wasn´t meant to be a thesis, only a guide about terrain loading.period. 5."Oh my... didn't anyone of you thought that point of article was not _speeding_ up rendering _but_ to *optimize* RAM usage" thanks. at least one person did understood the point of the article. 6."I just wanna see some demo to check myself about author ideas". sorry, i'm not allowed to provide one. 7."However I rather suspect that option 3 is not the best...it requires so much more loading/unloading when the viewpoint rotates, even by small amounts, that performance suffers". what performance kind are you talking about? gpu or cpu? cpu does suffer (not so much), but as it's a multithreaded algorithm gpu doesn´t at all (that's what really counts, ain´t it?) 8.i'm not trying to optimize RAM, i'm trying to use a 4Gb database, get it? |
||||
|
||||
|
thenewparadigm Member since: 4/30/2004 From: USA |
|||
|
Posted - 5/1/2004 1:16:25 AM |
||||
| i'm a bit knew to game design, so forgive any ignorance on my part, but in dealing with the rapid rotations, would it not be prudent to calculate the rate at which the mouse is rotating, then using that calculation to determine how many tiles should be cached into system memory? in greater detail: we can generally assume that if someone is rotating the camera in a given direction, that person wont immediately rotate the camera at full speed in the opposite direction (and even if they did, there would not be too large of a problem). given this principle, the rate of rotation can be very useful: you calculate the rate of rotation per second, divide that down so that it's the rate of rotation per frame, and then calculate a virtual frustrum that would include the area of the frustrum in the next frame (or next few frames - which ever is optimal), and precache all tiles within the newly calculated virtual frustrum into the system memory. this would take care of any problems dealing with ultra-fast rotation rates, however, given that you can be dealing with anywhere from (frustrum_arc_length * frustrum radius) to (360-frustrum_arc_length * frustrum radius) of precached tiles, framerate could vary signifigantly. a more efficient alternative would simply be to create a virtual frustrum that covers the area based on the rate of rotation calculation, and simply precache any new tiles found in the virtual frustrum. this alternative assumes that only one frame is needed to precache all new frames within a frustrum, and may not be viable if more frames are needed to precache all frames with the new frustrum. |
||||
|
||||
| All times are ET (US) |
Last Thread Next Thread |
|
