Thread: Re: [Algorithms] Terrain Organization
Brought to you by:
vexxed72
Menu
▾
▴
gdalgorithms-list
|
From: James C. <jj...@us...> - 2000-07-30 00:54:25
|
Give the message board over at Longbow Digital Arts (www.longbowdigitalarts.com) a try, under the programming forum there are many great discussions on ROAM as well as several other CLOD algorithms, as well as all kinds of general useful terrain rendering information. -----Original Message----- From: Pai-Hung Chen <pa...@ac...> To: gda...@li... <gda...@li...> Date: Saturday, July 29, 2000 8:32 PM Subject: Re: [Algorithms] Terrain Organization >Fred wrote: > >> Hi, >> >> I'm new to terrain rendering, but at this right moment I was >reading an >> article about ROAM ; looks very interesting and not so hard, >when it's well >> explained as it is on >> http://www.psky.com/prog/terrain.htm >> Have a look ! >> It seems that you do NOT have to reconstruct all the stuff for >each frame, >> and it's precisely one of the interests of ROAM. > >Actually I've read the original ROAM paper and another one on >Gamasutra, and was helplessly frustrated. :-( I'll look at the >one you suggested to see if it makes any more sense to me. Thanks >a lot! > >Pai-Hung Chen > > > >_______________________________________________ >GDAlgorithms-list mailing list >GDA...@li... >http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list > |
|
From: <SHA...@ao...> - 2000-07-30 07:13:28
|
Hi, I agree with you on ROAM...far too complicated for us mere mortals and best left to the gurus :) I would suggest using a recursive QuadTree algorithm...lots of resources for this on the net and works pretty much as you describe << Meanwhile I am planning to split the terrain up to several _hierarchical_ chunks (with bounding boxes) and, for each frame, I test each chunk against the current viewing frustum (VF) to _recursively_ determine if it has to be submitted to the transformation and rendering pipeline >> John. |
|
From: Tom F. <to...@mu...> - 2000-07-30 11:27:57
|
As well as those methods mentioned (ROAM, CLOD, quadtree, BSPd, just drawing everything), VIPM is very useful for LoD in terrains, and indeed for LoD in most things. It is especially efficient when combined with a quadtree style of texturing and paging. Probably the best tutorial for all things VIPM is Charles Bloom's site http://208.55.130.3/3d/ - check the sixth link down. There is also a terrain VIPM demo there. There is also tons of discussion on the various terrain styles in the archives (assuming they are up and running now). Tom Forsyth - Muckyfoot bloke. Whizzing and pasting and pooting through the day. > -----Original Message----- > From: Relja Markovic [mailto:re...@in...] > Sent: 30 July 2000 12:04 > To: gda...@li... > Subject: Re: [Algorithms] Terrain Organization > > > Check the archives on this one, but I think someone (nVidia, > perhaps?) said > once that on TnL type cards it is more efficient to pump the > polygons at the > card than to spend too much time (ROAM) LODding on the CPU. > If that is true > (I for one think it makes sense), the recursive quadtree you > described would > work just fine. Apparently, terrain LOD has no future with > TnL - unless you > want some extremely detailed stuff up front. Anyway, if your > terrain has 5-10 > K polys in an average scene, you could care less if you LOD > it down to 2-5K > on a TnL card... > > Relja > > > > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list > |
|
From: Tom F. <to...@mu...> - 2000-07-31 09:02:09
|
Yes, this is basically what a quadtree culling system does. Remember - there are two separate (but linked) considerations: (1) culling geometry that is out of view frustum. (2) reducing visible geometry through some sort of level-of-detail system. The two are often (and indeed, should be) interlinked, but they are separate thing. The first is comparatively simple - quadtree and similar hierarchial systems do it very well. The second is harder, and the subject of many discussions on this list. Tom Forsyth - Muckyfoot bloke. Whizzing and pasting and pooting through the day. > -----Original Message----- > From: Mats Lundberg [mailto:ma...@al...] > Sent: 30 July 2000 22:00 > To: gda...@li... > Subject: Re: [Algorithms] Terrain Organization > > > I've also thought of something similiar to what you proposed... > > Meanwhile I am planning to split the terrain up to several > _hierarchical_ > chunks (with bounding boxes) and, for each frame, I test each chunk > against the current viewing frustum (VF) to _recursively_ > determine if it > has to be > submitted to the transformation and rendering pipeline. If an > _upper-level_ chunk is rejected, there is no need to go down to the > _lower-level_ chunks inside it, which can quickly reject a > huge amount of > geometry. > > I don't se anything wrong with it. No fancy geometry calc:s, > just a simple > recursive function that goes through a quad tree. I mean, how > much simpler > can you make it?? It maybe crude but hey, it works. Right?? > > > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list > |
|
From: Tom F. <to...@mu...> - 2000-07-31 09:09:40
|
Indeed - my goal for graphics systems is that when they are released, they should be able to bring even the best existing machine down to sub-1Hz speed if you turn all the detail levels up, and yet have perfectly acceptable performance on five-year-old machines with the auto-LoD system on. That way you know (a) you've done a good job of scaling stuff, (b) you're pretty sure you can re-use the engine (or something derived from it) for the next project, and (c) people will still play your game in five years - it won't look sad. Oh yes, and (d) you might get some good bundling deals with new graphics cards - and they're always welcome. Tom Forsyth - Muckyfoot bloke. Whizzing and pasting and pooting through the day. > -----Original Message----- > From: Jim Offerman [mailto:j.o...@in...] > Sent: 31 July 2000 08:09 > To: gda...@li... > Subject: Re: [Algorithms] Terrain Organization > > > > As for not everyone having TnL cards, well, I thought that > any game which > is > > *now* in development will probably run on fast systems. By > fast I mean > either > > TnL, or on CPUs which are fast enough that regular cards > don't suffer too > > much. Anyway, this is up to you, it depends on you budget > and a lot of > other > > things. > > If you are going to implement some form of CLOD (this is > where Tom Forsyth > would promote using VIPM - which is not a bad idea at all), I > think you > should couple the runtime error calculations to your fps... > i.e. if your fps > drops, crank down all lod levels in the game until the fps reaches an > acceptable level. Your gime might be spitting out 100K tris > per second on a > souped up PIII with GeForce2 GTS and pump through a humble > 15K on a PII with > TNT PCI. > > And, since you have tied your CLOD calculations to the fps you could > (theoratically) also truly design your game for the future - > i.e. use models > which by todays standards contain far to many triangles, the > CLOD will keep > performance acceptable on today's high end hardware and > increase detail on > tomorrow's hardware. Imagine playing Half-Life again, finding that the > overall detail has increased by a factor ten. > > Jim Offerman > > Innovade > - designing the designer |
|
From: Jim O. <j.o...@in...> - 2000-07-31 10:53:20
|
Hail to scalability :-) Jim Offerman Innovade - designing the designer ----- Original Message ----- From: "Tom Forsyth" <to...@mu...> To: <gda...@li...> Sent: Monday, July 31, 2000 11:04 AM Subject: RE: [Algorithms] Terrain Organization > Indeed - my goal for graphics systems is that when they are released, they > should be able to bring even the best existing machine down to sub-1Hz speed > if you turn all the detail levels up, and yet have perfectly acceptable > performance on five-year-old machines with the auto-LoD system on. That way > you know (a) you've done a good job of scaling stuff, (b) you're pretty sure > you can re-use the engine (or something derived from it) for the next > project, and (c) people will still play your game in five years - it won't > look sad. Oh yes, and (d) you might get some good bundling deals with new > graphics cards - and they're always welcome. > > Tom Forsyth - Muckyfoot bloke. > Whizzing and pasting and pooting through the day. > > > -----Original Message----- > > From: Jim Offerman [mailto:j.o...@in...] > > Sent: 31 July 2000 08:09 > > To: gda...@li... > > Subject: Re: [Algorithms] Terrain Organization > > > > > > > As for not everyone having TnL cards, well, I thought that > > any game which > > is > > > *now* in development will probably run on fast systems. By > > fast I mean > > either > > > TnL, or on CPUs which are fast enough that regular cards > > don't suffer too > > > much. Anyway, this is up to you, it depends on you budget > > and a lot of > > other > > > things. > > > > If you are going to implement some form of CLOD (this is > > where Tom Forsyth > > would promote using VIPM - which is not a bad idea at all), I > > think you > > should couple the runtime error calculations to your fps... > > i.e. if your fps > > drops, crank down all lod levels in the game until the fps reaches an > > acceptable level. Your gime might be spitting out 100K tris > > per second on a > > souped up PIII with GeForce2 GTS and pump through a humble > > 15K on a PII with > > TNT PCI. > > > > And, since you have tied your CLOD calculations to the fps you could > > (theoratically) also truly design your game for the future - > > i.e. use models > > which by todays standards contain far to many triangles, the > > CLOD will keep > > performance acceptable on today's high end hardware and > > increase detail on > > tomorrow's hardware. Imagine playing Half-Life again, finding that the > > overall detail has increased by a factor ten. > > > > Jim Offerman > > > > Innovade > > - designing the designer > > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list > > |
|
From: Jamie F. <j.f...@re...> - 2000-07-31 11:06:08
|
It's a nice idea, but is it worth the cost in development time? Jamie Jim Offerman wrote: > Hail to scalability :-) > > Jim Offerman > > Innovade > - designing the designer > > ----- Original Message ----- > From: "Tom Forsyth" <to...@mu...> > To: <gda...@li...> > Sent: Monday, July 31, 2000 11:04 AM > Subject: RE: [Algorithms] Terrain Organization > > > Indeed - my goal for graphics systems is that when they are released, they > > should be able to bring even the best existing machine down to sub-1Hz > speed > > if you turn all the detail levels up, and yet have perfectly acceptable > > performance on five-year-old machines with the auto-LoD system on. That > way > > you know (a) you've done a good job of scaling stuff, (b) you're pretty > sure > > you can re-use the engine (or something derived from it) for the next > > project, and (c) people will still play your game in five years - it won't > > look sad. Oh yes, and (d) you might get some good bundling deals with new > > graphics cards - and they're always welcome. > > > > Tom Forsyth - Muckyfoot bloke. > > Whizzing and pasting and pooting through the day. > > > > > -----Original Message----- > > > From: Jim Offerman [mailto:j.o...@in...] > > > Sent: 31 July 2000 08:09 > > > To: gda...@li... > > > Subject: Re: [Algorithms] Terrain Organization > > > > > > > > > > As for not everyone having TnL cards, well, I thought that > > > any game which > > > is > > > > *now* in development will probably run on fast systems. By > > > fast I mean > > > either > > > > TnL, or on CPUs which are fast enough that regular cards > > > don't suffer too > > > > much. Anyway, this is up to you, it depends on you budget > > > and a lot of > > > other > > > > things. > > > > > > If you are going to implement some form of CLOD (this is > > > where Tom Forsyth > > > would promote using VIPM - which is not a bad idea at all), I > > > think you > > > should couple the runtime error calculations to your fps... > > > i.e. if your fps > > > drops, crank down all lod levels in the game until the fps reaches an > > > acceptable level. Your gime might be spitting out 100K tris > > > per second on a > > > souped up PIII with GeForce2 GTS and pump through a humble > > > 15K on a PII with > > > TNT PCI. > > > > > > And, since you have tied your CLOD calculations to the fps you could > > > (theoratically) also truly design your game for the future - > > > i.e. use models > > > which by todays standards contain far to many triangles, the > > > CLOD will keep > > > performance acceptable on today's high end hardware and > > > increase detail on > > > tomorrow's hardware. Imagine playing Half-Life again, finding that the > > > overall detail has increased by a factor ten. > > > > > > Jim Offerman > > > > > > Innovade > > > - designing the designer > > > > _______________________________________________ > > GDAlgorithms-list mailing list > > GDA...@li... > > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list > > > > > > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list |
|
From: Jim O. <j.o...@in...> - 2000-07-31 12:06:27
|
> It's a nice idea, but is it worth the cost in development time? I think that any form of scalability (whether it is achieved through some pre-calculated LoD levels or through advanced techniques, like the forementioned VIPM, or even just scalability/modularity of your engine it self) is worth the cost in development time, since it potentially increases the replayability of your game and/or the reusability of your engine. So your game can potentially sell more copies of a longer period, since it can still compete with the newest releases (hence you earn more money with it) and you can potentially reduce the development cycle of your next game, since you already have a good basis to start from. Scalability combined with modularity can even save you development time. If you implement a general case CLOD algorithm in your engine, you can apply this technique to both your game entities (units, buildings, etc.) and your terrain. Such a decision may have far reaching consequences: Since all your geometry is essentially the same, you can also handle all your geometry in the same way, which means less special case algorithms (which makes sense, since everything is evolving to more general case algorithms anyway...) and thus less code to write and debug. Jim Offerman Innovade - designing the designer |
|
From: Jamie F. <j.f...@re...> - 2000-07-31 13:15:35
|
Jim Offerman wrote: > > It's a nice idea, but is it worth the cost in development time? > > I think that any form of scalability (whether it is achieved through some > pre-calculated LoD levels or through advanced techniques, like the > forementioned VIPM, or even just scalability/modularity of your engine it > self) is worth the cost in development time, since it potentially increases > the replayability of your game and/or the reusability of your engine. > > So your game can potentially sell more copies of a longer period, since it > can still compete with the newest releases (hence you earn more money with > it) Is this true in the PC market? For consoles, you get most sales in early days, very little afterward. Tom's suggestion that you can still be looking good in n years time isn't matched by sales in our circumstances. > and you can potentially reduce the development cycle of your next game, > since you already have a good basis to start from. > Great idea, does it really happen in practice? We seem to end up starting from scratch every time. Or at least taking the old stuff, using it as a base, and then rewriting most of it. New consoles don't help, of course :) > > Scalability combined with modularity can even save you development time. If > you implement a general case CLOD algorithm in your engine, you can apply > this technique to both your game entities (units, buildings, etc.) and your > terrain. Such a decision may have far reaching consequences: Since all your > geometry is essentially the same, you can also handle all your geometry in > the same way, which means less special case algorithms (which makes sense, > since everything is evolving to more general case algorithms anyway...) and > thus less code to write and debug. That definitely makes sense. All our geometry is going through the same pipeline. CLOD does not make sense for us given time constraints, and it doesn't fit the hardware too well either (according to our somewhat limited research :). Next generation of games, we may try something a little more procedural, but not for the mo.... Algorithms that scale well are a good thing... he says, frantically trying to convince himself the thread's not OT.... :) Jamie |
|
From: Jim O. <j.o...@in...> - 2000-07-31 16:04:15
|
> Great idea, does it really happen in practice? We seem to end up starting from > scratch every time. Or at least taking the old stuff, using it as a base, and > then rewriting most of it. New consoles don't help, of course :) I am quite a fanatic reuser... while some parts of my engine are written only yesterday, other parts are several years old and have survived many generations of my engine. I find myself constantly tweaking the parts of the engine which interface with stuff like direct3d (technology side) and such all the time, while my scenegraph (content side) has remained quite constant for several years now. > That definitely makes sense. All our geometry is going through the same > pipeline. CLOD does not make sense for us given time constraints, and it > doesn't fit the hardware too well either (according to our somewhat limited > research :). Next generation of games, we may try something a little more > procedural, but not for the mo.... Admittedly, I cannot really afford to spend much time on progressive meshes, my biggest worry at the moment is getting my game up and running. Still, I am always on my toes and looking ahead... Given the architecture of my engine, VIPM is the way to go for me, since it can be implemented in my engine with quite little effort (the hard part is writing the code that generates the VIPM...) and in addition it is _very_ hardware friendly. Jim Offerman Innovade - designing the designer |
|
From: Jamie F. <j.f...@re...> - 2000-07-31 17:44:37
|
Jim Offerman wrote: > > Great idea, does it really happen in practice? We seem to end up starting > from > > scratch every time. Or at least taking the old stuff, using it as a base, > and > > then rewriting most of it. New consoles don't help, of course :) > > I am quite a fanatic reuser... while some parts of my engine are written > only yesterday, other parts are several years old and have survived many > generations of my engine. Impressive :) > I find myself constantly tweaking the parts of the > engine which interface with stuff like direct3d (technology side) and such > all the time, Us console programmers just get a new console to play with :) > while my scenegraph (content side) has remained quite constant > for several years now. > > > That definitely makes sense. All our geometry is going through the same > > pipeline. CLOD does not make sense for us given time constraints, and it > > doesn't fit the hardware too well either (according to our somewhat > limited > > research :). Next generation of games, we may try something a little more > > procedural, but not for the mo.... > > Admittedly, I cannot really afford to spend much time on progressive meshes, > my biggest worry at the moment is getting my game up and running. Still, I > am always on my toes and looking ahead... Given the architecture of my > engine, VIPM is the way to go for me, since it can be implemented in my > engine with quite little effort (the hard part is writing the code that > generates the VIPM...) and in addition it is _very_ hardware friendly. Not regardless of hardware. For us, drawing several instances of the same model saves us DMA bandwidth. CLOD trashes the ability to do that. Polygons are very cheap to draw, so we might as well draw them.... Unless anyone else knows better? :) Maybe when we've had more experience of the machine we'll change our minds. :) Jamie |
|
From: Brian M. <bma...@ra...> - 2000-07-31 16:59:06
|
> Is this true in the PC market? For consoles, you get most sales > in early days, > very little afterward. Tom's suggestion that you can still be > looking good in n > years time isn't matched by sales in our circumstances. This varies a lot with product - Goldeneye has sold many millions but started very slowly - a few hundred thousand. And it's still selling. Scalability for a console is more useful for load balancing the engine to keep the frame rate and detail. Or for handling things like play modes that need twice the number of character on screen. One challenge I'm working on here is getting the processor time to scale in line with the graphics - there are solutions for scaling the graphics that work nicely - processor scaling is proving something more difficult. Also making the artists more productive is a very big thing - just building one version with automatic lodding helps a lot, even before you get to the authoring approaches like Tom F. has detailed. -Brian. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X