Last visit was: It is currently Tue Dec 03, 2024 3:47 am


All times are UTC-05:00




Post new topic Reply to topic  [26 posts ] 
Author Message
 Post subject:Re: Challenge Four: A Computer Science/Game Development Problem
PostPosted:Thu Dec 27, 2007 11:50 am 
 

Joined:Sun Jun 10, 2007 11:41 am
Posts:344
Location:Ninjaville
Here's my approach. You have two files lets a bigtextures.dat detailed textures.dat. Now bigtextures.dat is broken up into different maps, and the entire map is loaded into memory once it starts. Detailedtextures.dat is broken up into maps, and map sections. When you approach a certain my section the detailed sections are loaded. Now heres the clever part, lets say your viewing distance is 10 units. it would load 50 units squared into memory, and every ten units you moved, it would load maybe 3\4 of that reducing load times and stuttering.

Really though the ideal approach has already been invented. It's called MegaTexture.


Top
Offline  
 Post subject:Re: Challenge Four: A Computer Science/Game Development Problem
PostPosted:Wed Jan 09, 2008 12:36 pm 
 

Joined:Mon Nov 12, 2007 11:48 am
Posts:1
ICQ:318966698
Location:Russian Federation
The LOD is vary usefull approach.
Everybody now trying to guess, how do the Black&White game 3D engine works. There was a big isnland, that was wery detailed, when you move camera closer. (:

Bassic idea of lod is simple - you have a 3D object, that finaly consists of verticles/edges/polygons (verticles are preferable) and texture. And you can dynamicaly make the object a little less detailed: it would not look bad from far, but will eat less resources, like memory or rendering time.

Texture LOD usaly (as i know) is just a few precalculates textures, that generated from one hi-detailed. i.e. you have one 1024x1024 texture for a rock. when the "rock model" is loading (in a background, while the camera moves, or in main thread, while all the environment loads) there are some copies generated: 512x512, 128x128, 32x32, 8x8. last copy is only 64pixels and therefore eats almost no memory. you can hold 1 or 2 of that set (include main, hi-detailed) in memory. when LOD is decreesing - more detailed texture throwed away, and less detailed are loaded. if there is 2 textures in memory, you can render it both with a different alpha, to make their switch softier.
the other half is a model itself. there is a ready technology from microsoft (in directX of course) that allows mesh-LOD. the idea is simple - you index all verticles by its "contribution in model". and while LODing the least powerful verticles/edges just removed, the gaps are filed. but (i guess) that needs 2 copy of model permanently loaded - high detailed original and current LODed copy. only advantage, is there is no need to put original in video memory.

in your case the objects is square(in projection) parts of your landscape. in easy way all the squares are equal-sized and forms grid. but you can make (if the landscape is hand-drawed, not generated) some least significant deserts be 4,16,64 etc squares glued together.

and the process of indexing may be like that: four corner verticles are indexed as most powerfull( i.e. index 64535) so your square will apper as real square when LODed down completely, just 4 verticles connected. but will preserve the average angle of object.
After that you may divide curent square on 4 equal squares and make every not indexed verticle in corners of each square like [index_of_that_big_four_aroud_it/2]. and so forth for all 4 new squares recursively.
if the post will interest anyone, I'll draw some paintings to explain.

BUT all the post is pure theory. i've never wrote 3d engines, but want to do it in future. :o
ps: sorry for my english.


Top
Offline  
 Post subject:Re: Challenge Four: A Computer Science/Game Development Problem
PostPosted:Wed Mar 05, 2008 3:23 am 
Literally Nine
User avatar
 

Joined:Sat Apr 02, 2005 3:31 pm
Posts:1171
Location:The vicinity of an area adjacent to a location.
Prophile, I think this challenge is now dead. Let's get another going.

_________________
- Tycho

Image


Top
Offline  
 Post subject:Re: Challenge Four: A Computer Science/Game Development Problem
PostPosted:Wed Mar 05, 2008 11:48 am 
User avatar
 

Joined:Sun Feb 12, 2006 8:56 pm
Posts:1019
Website:http://eddieringle.com
Location:Detroit, MI
Yes please. And I would like some more like these, without code. I'd rather create the concepts instead of the code. I'm a... Conceptionist. (If that is a real word...)


Top
Offline  
 Post subject:Re: Challenge Four: A Computer Science/Game Development Problem
PostPosted:Wed Mar 05, 2008 3:52 pm 
User avatar
 

Joined:Mon Feb 18, 2008 8:13 pm
Posts:36
Quote:
Yes please. And I would like some more like these, without code. I'd rather create the concepts instead of the code. I'm a... Conceptionist. (If that is a real word...)
I agree with you. I am one myself. You had a good approach though. However, for the quality of the textures, I would go with with something bove low, but not that high so people could actually see more than just low quality textures of the landscape. (As a viewer, it would be more enjoyable to see more as long as the computer is capable to do it.)


Top
Offline  
 Post subject:Re: Challenge Four: A Computer Science/Game Development Problem
PostPosted:Thu Mar 06, 2008 2:30 pm 
Connoisseur of the Godawful
User avatar
 

Joined:Tue Mar 01, 2005 9:00 am
Posts:456
ICQ:286315965
Website:http://rabidtinker.mine.nu/
Yahoo Messenger:alistair_lynn
AOL:Agent_Vast@mac.com
Location:127.0.0.1
I declare no winner, since nobody even said the word 'octree' let alone advanced paging :(

_________________
Alastair Lynn / Alumnus / Onlink Team


Top
Offline  
 Post subject:Re: Challenge Four: A Computer Science/Game Development Problem
PostPosted:Sun Jul 06, 2008 7:11 pm 
User avatar
 

Joined:Mon Mar 07, 2005 9:32 am
Posts:600
Location:localhost
I've just read this, and I'm really surprised at how much people missed.

The main performance enhancer would be prefetching of higher detail map sections. The area closest to the player has the highest LOD (maximum particle count, highest texture quality, etc). The further away from the player that a model or terrain section is, the lower the LOD.

Say for example we define 5 levels of detail, LOD_LEVEL_1 through to LOD_LEVEL_5 (where 5 is the highest detail).

The immediate area around the player gets LOD_LEVEL_5 applied. Areas that are a reasonable distance away get LOD_LEVEL_4 applied and even further out from that gets LOD_LEVEL_3. The horizon would be LOD_LEVEL_1 (minimal texture quality, few/no particles, simple lighting, reduced polygon count models, etc). We mask off the low quality of distant quality with a bit of blur, bloom or fog, and it looks great.

The prefetching should work by loading the next available level of detail from disk into memory during less intensive periods of the game. As the player moves, the areas that were previously on LOD_LEVEL_4 now get LOD_LEVEL_5, which has been conveniently prefetched for us.

The next thought is selective processing. While a player battles with monsters or other players, they will not be paying so much attention on the distant horizon, so we can tighten the LOD falloff a little (increase the gradient at which LOD falls) to allow for better performance during high-movement and high-particle count periods.

Another great performance enhancer is the use of precomputed occlusion volumes. For example, say we have a set of player starting points which face a large building, in a hollowed out crater. Dotted around the edge of the crater are fountains of lava and large glittery and sparkly statues. When the map is created, an occlusion volume is created around the player starting points, which is linked to another volume on the other side (see attached image for demo - red = player start, blue box = occlusion volume, dark grey block = building). The occlusion is precomputed at map-compile time (at the end of development) and requires very little processing.

Sometimes a technical problem can also be solved artistically. If the close environment is kept rich and interesting, the player will be less likely to stare off into the distance.


Attachments:
File comment:Demonstration of occlusion volumes.
occlude.jpg
occlude.jpg [7.86KiB |Viewed 52390 times ]
Top
Offline  
 Post subject:Re: Challenge Four: A Computer Science/Game Development Problem
PostPosted:Sun Nov 02, 2008 10:49 pm 
User avatar
 

Joined:Mon Sep 22, 2008 9:51 am
Posts:112
This is old, but reading the first few posts i'll add what I would like to do (I am an idealist). Generally speaking, you have a ton of geometry, most games deal with this in several ways, area loads and a view distance. If you want a nice way to display it all at once you would probably have to do something simular to the way they handle the graphics scaling in games. Level of detail, in graphics you generally have a bunch of graphics, one at high quality then decrease it by half every step of distance (1024x1024, 512x512, 256x256, 128x128, etc), place it where it needs to be, most the LOD scaling would happen near the horizon (ergo 90% is the 1024, 5% is 512, 2.5% is 256, etc). Generally I wouldn't care enough about very far off geometry to even notice it was there in video games, which is why most cut it, unless the video game made it a big deal.

Oh also, octrees are your friends. :)

_________________
Oh this and that.


Top
Offline  
 Post subject:Re: Challenge Four: A Computer Science/Game Development Problem
PostPosted:Sun Jan 18, 2009 9:31 pm 
 

Joined:Sun Jan 18, 2009 4:20 am
Posts:40
Run the application on a server farm when client is run.

Client captures and sends user input (keyboard/mouse), server farm runs application and renders, and pushes the picture back to client.

Extensible and independent from user's computer specs!

*ducks*


Top
Offline  
 Post subject:Re: Challenge Four: A Computer Science/Game Development Prob
PostPosted:Wed Jul 28, 2010 5:16 am 
 

Joined:Thu Nov 15, 2007 2:00 pm
Posts:68
Website:http://www.skyblownet.com
Massive grave digging!

But anyway one way to do it is just calculate the viewable portion of the 'map'/'world' on-the-fly with use of a height map.


Top
Offline  
 Post subject:Re: Challenge Four: A Computer Science/Game Development Prob
PostPosted:Wed Jul 28, 2010 10:10 am 
 

Joined:Tue Jul 27, 2010 6:09 pm
Posts:15
I'm afraid that I always viewed LOD s a cheap hack to fix things that the rendering developer couldn't.

My recommendation would be to make a draw sphere. The entirety of the sphere starts out as invalid, and sections of the sphere become invalidated yet again when the distance between the camera and the sections differ from the radius of the FOV by a certain threshold. When they do become invalidated, a full trace render is done in that section.

Pros:
-No loss of quality can be seen by the user.
-You are rendering large distances, but only sparingly.
Cons:
-Massive lagspikes when teleporting or traveling high enough speeds to pass through the threshold on a regular basis.
Recommended fix: Multithread the rendering and create a buffer. Traveling would then cause some small loss of quality as the camera got close enough to the drawsphere to recognize it as a sphere.
-Small moving objects do not update properly from a distance.
Recommended fix: Use *ugh* LOD to omit small objects from being rendered at all. If a lot of entity data changes beyond a specified amount, invalidate that direction.


Top
Offline  
Display posts from previous: Sort by 
Post new topic Reply to topic

All times are UTC-05:00


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Theme created by Miah with assistance from hyprnova