Thread: RE: [Algorithms] terrain texturing
Brought to you by:
vexxed72
Menu
▾
▴
gdalgorithms-list
|
From: Charles B. <cb...@cb...> - 2001-01-15 17:23:52
|
First of all, to the original poster (Timo), if your target
is high-end (GeForce2, XBox) you could use the "splatting"
technique ("compositing influence regions in the frame buffer")
which I describe at www.cbloom.com/3d/
It's similar to John's (and others') techniques in many ways,
though as John knows, the greatness is in the details. Splatting
lets you composite many close detail maps of any configuration;
the cost is higher memory usage and many passes (no problem for
XBox; GF2 can get overloaded).
Now, John, there are a couple of points I'm not clear on :
At 02:59 PM 1/14/2001 -0800, John Ratcliff wrote:
>Now, when you get up close and personal I have a dynamically generated
>tesselated mesh that is created in real-time from the base mesh. I use the
>same precomputed tables used for terrain collision detection so that I can
>generate this mesh in real-time with no performance penalty.
How does this mesh relate to the collision detection tables?
>This
>tesselated mesh is rendered alpha-blended on top of the main terrain. It
>shares the same lightmap data in the second texture channel, but texture
>stage one contains extremely high resolution close up textures.
I thought the lighting was baked into the original texture? Do you also
keep around another copy of it in lightmap form, or does the original
texture also use lightmapping (eg. color * light) so that you can do
over-brightinening by adding dynamic lights to the lightmap ?
>You can only alpha blend from one texture type to another.
So, granted you can set it up so that the places where multiple textures
meet are rare, but how do you handle those places when they happen? You've
got to at least handle a three-texture meeting (since any N-tex joint can be
turned into a 3-tex joint) or it seems like there would be visible seams?
Maybe you can also say a little more about how this alpha channel is used
to blend the detail textures.
-------------------------------------------------------
Charles Bloom cb...@cb... http://www.cbloom.com
|
|
From: Daniel R. <Dan...@ho...> - 2001-01-15 17:35:43
|
a shorty =)
> Now, John, there are a couple of points I'm not clear on :
>
> At 02:59 PM 1/14/2001 -0800, John Ratcliff wrote:
> >Now, when you get up close and personal I have a dynamically generated
> >tesselated mesh that is created in real-time from the base mesh. I use
the
> >same precomputed tables used for terrain collision detection so that I
can
> >generate this mesh in real-time with no performance penalty.
>
> How does this mesh relate to the collision detection tables?
charles, it's simple ... do your collision detecion by interpolating on/in a
heightfield,
now tesselate or roam a mesh or vipm a mesh from this heightfield ...
in 100% the mesh should be visibly same as the "heightfield underground" on
which a player could "stay on ground"
now look where the level of detail gets lower ... there the collision data
is not the same as the visual data ...
thus letting players stand/fly above ground or sticking in it
got what i / john mean(s) ?
Daniel "SirLeto" Renkel [D.R...@Fu...]
technical design director - creactivity and technowhow =8O)
Future Interactive [http://www.FutureInt.de]
|
|
From: Timo H. <Tim...@gm...> - 2001-01-15 20:32:28
|
Hi Charles !
Monday, 15. Januar 2001, you wrote:
> First of all, to the original poster (Timo), if your target
> is high-end (GeForce2, XBox) you could use the "splatting"
> technique ("compositing influence regions in the frame buffer")
> which I describe at www.cbloom.com/3d/
> It's similar to John's (and others') techniques in many ways,
> though as John knows, the greatness is in the details. Splatting
> lets you composite many close detail maps of any configuration;
> the cost is higher memory usage and many passes (no problem for
> XBox; GF2 can get overloaded).
[SNIP]
sorry, my target isn't geforce2+. I think i will use unique
texturing. each texture is generated on-the-fly in software when
needed. Then i'll add some detailmap to increase the detail around the
camera.
These techniques you and John descibe are very interesting but not
suited for my needs.
Which terrain-algo would you choose when targetting systems with tnt1
or better?
Algos that come into my mind:
a) split-only-roam
b) quadtree
c) terrain mip-mapping (also kewl for geforce)
what do you think about c) ?
I only read the paper and saw one implementation which suffers from
heavy popping, but a) and b) seem to be hardware-unfriendly and
cpu-dependant.
Thanks,
Timo
--
Timo Heister
E-mail: Tim...@gm...
|
|
From: Akbar A. <sye...@ea...> - 2001-01-15 20:45:03
|
>each texture is generated on-the-fly in software when >needed. i'm just throwing this out here, havent' been really following this thread to closely. but isn't uploading all those textures going to be really expensive for you? doing that on our hardware (geforce2, radeon, etc..) it's kind of expensive.. but on consoles (nintendo 64) it is really cheap; iirc (it's been a while ;) just curiuos? >tnt1 heh; laterz, akbar A. ;vertexabuse.cjb.net or ;www.vertexabuse.com cjb goes down once in a while "necessity is the mother of strange bedfellows" -ninja scroll -----Original Message----- From: gda...@li... [mailto:gda...@li...]On Behalf Of Timo Heister Sent: Monday, January 15, 2001 2:33 PM To: Charles Bloom Subject: Re: [Algorithms] terrain texturing Hi Charles ! Monday, 15. Januar 2001, you wrote: > First of all, to the original poster (Timo), if your target > is high-end (GeForce2, XBox) you could use the "splatting" > technique ("compositing influence regions in the frame buffer") > which I describe at www.cbloom.com/3d/ > It's similar to John's (and others') techniques in many ways, > though as John knows, the greatness is in the details. Splatting > lets you composite many close detail maps of any configuration; > the cost is higher memory usage and many passes (no problem for > XBox; GF2 can get overloaded). [SNIP] sorry, my target isn't geforce2+. I think i will use unique texturing. each texture is generated on-the-fly in software when needed. Then i'll add some detailmap to increase the detail around the camera. These techniques you and John descibe are very interesting but not suited for my needs. Which terrain-algo would you choose when targetting systems with tnt1 or better? Algos that come into my mind: a) split-only-roam b) quadtree c) terrain mip-mapping (also kewl for geforce) what do you think about c) ? I only read the paper and saw one implementation which suffers from heavy popping, but a) and b) seem to be hardware-unfriendly and cpu-dependant. Thanks, Timo -- Timo Heister E-mail: Tim...@gm... _______________________________________________ GDAlgorithms-list mailing list GDA...@li... http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list |
|
From: Timo H. <Tim...@gm...> - 2001-01-16 10:58:15
|
Hi Akbar, Montag, 15. Januar 2001, you wrote: >>each texture is generated on-the-fly in software when >>needed. > i'm just throwing this out here, havent' been really following this thread > to > closely. > but isn't uploading all those textures going to be really expensive for you? > doing that on our hardware (geforce2, radeon, etc..) it's kind of > expensive.. > but on consoles (nintendo 64) it is really cheap; iirc (it's been a while ;) > just curiuos? I'm not sure, but using a good texture-cache should help. And think about 3dfx, their texture upload is pretty fast. And you have to upload textures anyway, when having such a high detail you can't fit all textures into the agp mem. >>tnt1 > heh; just my lowest target, not my main developer machine ;) > laterz, > akbar A. > ;vertexabuse.cjb.net > or > ;www.vertexabuse.com > cjb goes down once in a while > "necessity is the mother of strange bedfellows" > -ninja scroll CU, Timo -- Timo Heister E-mail: Tim...@gm... ICQ: <ask me> |
|
From: Akbar A. <sye...@ea...> - 2001-01-16 13:14:54
|
okay, cause i'm doing a decent amount of uploading/writing freshly built textures to the scene and this is usually where a fair amount of time gets spent relatively speaking. i'm hoping the nv20 fixes this though; >but using a good texture-cache should help i use OpenGL, probably do a port do Direct3D once dx8 class hardware becomes available. laterz, akbar A. ;vertexabuse.cjb.net or ;www.vertexabuse.com cjb goes down once in a while "necessity is the mother of strange bedfellows" -ninja scroll -----Original Message----- From: gda...@li... [mailto:gda...@li...]On Behalf Of Timo Heister Sent: Tuesday, January 16, 2001 4:59 AM To: Akbar A. Subject: Re: [Algorithms] terrain texturing Hi Akbar, Montag, 15. Januar 2001, you wrote: >>each texture is generated on-the-fly in software when >>needed. > i'm just throwing this out here, havent' been really following this thread > to > closely. > but isn't uploading all those textures going to be really expensive for you? > doing that on our hardware (geforce2, radeon, etc..) it's kind of > expensive.. > but on consoles (nintendo 64) it is really cheap; iirc (it's been a while ;) > just curiuos? I'm not sure, but using a good texture-cache should help. And think about 3dfx, their texture upload is pretty fast. And you have to upload textures anyway, when having such a high detail you can't fit all textures into the agp mem. >>tnt1 > heh; just my lowest target, not my main developer machine ;) > laterz, > akbar A. > ;vertexabuse.cjb.net > or > ;www.vertexabuse.com > cjb goes down once in a while > "necessity is the mother of strange bedfellows" > -ninja scroll CU, Timo -- Timo Heister E-mail: Tim...@gm... ICQ: <ask me> _______________________________________________ GDAlgorithms-list mailing list GDA...@li... http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list |
|
From: Thatcher U. <tu...@tu...> - 2001-01-16 14:58:21
|
On Jan 16, 2001 at 07:17 -0600, Akbar A. wrote: > > >but using a good texture-cache should help > > i use OpenGL, probably do a port do Direct3D once dx8 class hardware becomes > available. The API doesn't affect whether you can make a texture cache. -- Thatcher Ulrich <tu...@tu...> == Soul Ride -- pure snowboarding for the PC -- http://soulride.com == real-world terrain -- physics-based gameplay -- no view limits |
|
From: Akbar A. <sye...@ea...> - 2001-01-16 16:25:25
|
>The API doesn't affect whether you can make a texture cache. true/okay; imho i have always presumed that Direct3D was just better suited when it came to handling/dealing with textures. and lots of ppl that use Direct3D often tell me this as well... glAreTexturesResident() and glPrioritizeTextures() ;) and with GL you rarely know what the driver is doing with textures, this can suck at times. laterz, akbar A. ;vertexabuse.cjb.net or ;www.vertexabuse.com cjb goes down once in a while "necessity is the mother of strange bedfellows" -ninja scroll -----Original Message----- From: gda...@li... [mailto:gda...@li...]On Behalf Of Thatcher Ulrich Sent: Tuesday, January 16, 2001 8:55 AM To: gda...@li... Subject: Re: [Algorithms] terrain texturing On Jan 16, 2001 at 07:17 -0600, Akbar A. wrote: > > >but using a good texture-cache should help > > i use OpenGL, probably do a port do Direct3D once dx8 class hardware becomes > available. The API doesn't affect whether you can make a texture cache. -- Thatcher Ulrich <tu...@tu...> == Soul Ride -- pure snowboarding for the PC -- http://soulride.com == real-world terrain -- physics-based gameplay -- no view limits _______________________________________________ GDAlgorithms-list mailing list GDA...@li... http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list |
|
From: Thatcher U. <tu...@tu...> - 2001-01-16 05:08:07
|
On Jan 15, 2001 at 09:32 +0100, Timo Heister wrote: > > sorry, my target isn't geforce2+. I think i will use unique > texturing. each texture is generated on-the-fly in software when > needed. Then i'll add some detailmap to increase the detail around the > camera. > These techniques you and John descibe are very interesting but not > suited for my needs. > Which terrain-algo would you choose when targetting systems with tnt1 > or better? > Algos that come into my mind: > a) split-only-roam > b) quadtree > c) terrain mip-mapping (also kewl for geforce) > > what do you think about c) ? > I only read the paper and saw one implementation which suffers from > heavy popping, but a) and b) seem to be hardware-unfriendly and > cpu-dependant. Soul Ride uses a system that sounds similar to what you're talking about: unique texturing, rendered by software and then downloaded into a texture cache. The rendering/downloading hurts, especially on TNT-level hardware, but it is feasible. The way I see it, the algorithm used for meshing and the algorithm used for texturing can/should be fairly independent of each other, so the roam/quadtree/static discussion is a separate question. I agree with you that texturing is really important for getting good results with a terrain engine, probably more important than geometric LOD in these days of fast hardware. John R's description and screenshots are very generous and should give you good ideas to keep you busy for a while. Combining his comments with my own experience, I would distill the message down to a few bullet points: * hi-res unique texturing with hi-res unique lighting looks great. * you can't reasonably fit the full-resolution textures you need in texture RAM all at once (e.g. in John's case 8192m x 8192m --> 64Mtexels), however, for any given viewpoint, most of the terrain is far away and so can use a lower res version. So you need some sort of texture cache, and you need to be able to load/generate mip-mapped versions of your texture tiles. * detail rules, but RAM is limited... if you're serious, you need to get into paging and/or compression. Detail overlays, tiling, splatting, procedural texturing etc can all be thought of as compression techniques in some sense. Those are the principles, the rest is just a bunch of minor details... :) -- Thatcher Ulrich <tu...@tu...> == Soul Ride -- pure snowboarding for the PC -- http://soulride.com == real-world terrain -- physics-based gameplay -- no view limits |
|
From: Ron H. <rh...@cy...> - 2001-01-16 06:02:36
|
I asked this on the DirectX list, but I figured this might be a better place for a more general discussion. What are some good ways to make a game more concurrent as far as the CPU and graphics card are concerned? Is it better to send over the primitives all in a single bunch, or to split them up into batches and do calculations interspersed between them? Thanks! Ron Hay DevGuy |
|
From: Timo H. <Tim...@gm...> - 2001-01-16 11:12:29
|
Hi Thatcher,
Dienstag, 16. Januar 2001, you wrote:
> On Jan 15, 2001 at 09:32 +0100, Timo Heister wrote:
>>
>> sorry, my target isn't geforce2+. I think i will use unique
>> texturing. each texture is generated on-the-fly in software when
>> needed. Then i'll add some detailmap to increase the detail around the
>> camera.
>> These techniques you and John descibe are very interesting but not
>> suited for my needs.
>> Which terrain-algo would you choose when targetting systems with tnt1
>> or better?
>> Algos that come into my mind:
>> a) split-only-roam
>> b) quadtree
>> c) terrain mip-mapping (also kewl for geforce)
>>
>> what do you think about c) ?
>> I only read the paper and saw one implementation which suffers from
>> heavy popping, but a) and b) seem to be hardware-unfriendly and
>> cpu-dependant.
> Soul Ride uses a system that sounds similar to what you're talking
> about: unique texturing, rendered by software and then downloaded into
> a texture cache. The rendering/downloading hurts, especially on
> TNT-level hardware, but it is feasible.
Does soul ride has a fully unique texturing approach? or are some
textures used a few times? (should be possible when displaying snow)
Anyway,I think i will give it a try.
> The way I see it, the algorithm used for meshing and the algorithm
> used for texturing can/should be fairly independent of each other, so
> the roam/quadtree/static discussion is a separate question.
Thats right, but a few things are dependent, for example John's Algo
uses detail-polys to blend the textures which has a connection to the
texture generation. When i don't have to blend the textures i won't
need extra detail polys for blending ...
but you are right, perhaps i should start a new thread.
> I agree with you that texturing is really important for getting good
> results with a terrain engine, probably more important than geometric
> LOD in these days of fast hardware.
Do not forget good lighting ...
> John R's description and
> screenshots are very generous and should give you good ideas to keep
> you busy for a while.
Yep, it was really kind to tell us his secret algos. But i think my
engine won't be the future reference. It kindof helped me, but i'm not
sure if it works that good for current hardware.
> Combining his comments with my own experience,
> I would distill the message down to a few bullet points:
that's nice ;)
> * hi-res unique texturing with hi-res unique lighting looks great.
right, i would even say, that one should consider lowering the
poly-count for more texture/lighting detail. With a few hundret polys
and large textures you can even build a few very nice moutains. (note
that i won't work as good with normal binary/.. trees because they
aren't as efficient)
> * you can't reasonably fit the full-resolution textures you need in
> texture RAM all at once (e.g. in John's case 8192m x 8192m -->
> 64Mtexels), however, for any given viewpoint, most of the terrain is
> far away and so can use a lower res version. So you need some sort of
> texture cache, and you need to be able to load/generate mip-mapped
> versions of your texture tiles.
The question is, if leaving a really low-resolution texture of the
whole terrain in texture-ram is a good idea. When you get near a quad
you can upload a larger version. what do you think? It perhaps depends
on how large your terrain is and where the far clipping-plane is.
> * detail rules, but RAM is limited... if you're serious, you need to
> get into paging and/or compression. Detail overlays, tiling,
> splatting, procedural texturing etc can all be thought of as
> compression techniques in some sense.
right, has anyone any experience with texture-compression (s3tc,dds
...) ? How is the quality of the textures? How fast is the generation?
(when generating compressed textures in realtime)
> Those are the principles, the rest is just a bunch of minor
> details... :)
The problem sometimes is in the detail !
CU, Timo
--
Timo Heister
E-mail: Tim...@gm...
ICQ: <ask me>
|
|
From: Thatcher U. <tu...@tu...> - 2001-01-16 15:43:25
|
On Jan 16, 2001 at 12:12 +0100, Timo Heister wrote:
> Hi Thatcher,
>
> Dienstag, 16. Januar 2001, you wrote:
>
> > Soul Ride uses a system that sounds similar to what you're talking
> > about: unique texturing, rendered by software and then downloaded into
> > a texture cache. The rendering/downloading hurts, especially on
> > TNT-level hardware, but it is feasible.
>
> Does soul ride has a fully unique texturing approach? or are some
> textures used a few times? (should be possible when displaying snow)
> Anyway,I think i will give it a try.
It's fully unique from the texture cache down. In other words, there
is a unique texel in texture RAM for every spot on the visible
terrain. The texture tiles are built on demand, and the rendering
process uses predefined tile types blended using a noise function and
lightmaps, so there is quite a bit of apparent "sameness".
[...]
> > John R's description and
> > screenshots are very generous and should give you good ideas to keep
> > you busy for a while.
>
> Yep, it was really kind to tell us his secret algos. But i think my
> engine won't be the future reference. It kindof helped me, but i'm not
> sure if it works that good for current hardware.
Don't be so sure... I think the extra detail passes might be tough on
older hardware, but most of the other ideas seem usable.
> > * you can't reasonably fit the full-resolution textures you need in
> > texture RAM all at once (e.g. in John's case 8192m x 8192m -->
> > 64Mtexels), however, for any given viewpoint, most of the terrain is
> > far away and so can use a lower res version. So you need some sort of
> > texture cache, and you need to be able to load/generate mip-mapped
> > versions of your texture tiles.
>
> The question is, if leaving a really low-resolution texture of the
> whole terrain in texture-ram is a good idea. When you get near a quad
> you can upload a larger version. what do you think? It perhaps depends
> on how large your terrain is and where the far clipping-plane is.
Sure. In fact, you pretty much *have* to do something like this.
Just to do some back-of-the-envelope calculations, let's say your
terrain is like John's, 8192m x 8192m with 1m texels in the base map.
So that's 64M texels at full res. But you only need full res locally.
At a FOV of 90 degrees, and a 640-pixel-wide window, the terrain
texels will be smaller than one pixel when the viewpoint is more than
320 meters away. At 640 meters, you can switch to 2m texels with no
visible impact. At 1280 meters you can use 4m texels, and at 2560
meters you can use 8m texels. 8192 / 8 == 1024, so a single 1024x1024
texture representing your whole terrain looks perfect for all terrain
that's further than 2560 meters away, and only consumes 1M texels.
You also need tiles for the closer terrain, and they take up ~1M
texels per level (actually a little less in practice due to overlap).
So that's three more levels to get to your highest resolution (4m, 2m,
and 1m). Total texture RAM usage: ~4M texels. Furthermore, that
includes textures that are outside the frustum, so you actually only
see ~1M texels at any given time.
In Soul Ride I use a 3Mtexel cache for terrain textures, because my
terrain is bigger and the finest resolution is 0.25 meters/texel, but
once you have the system in place it's pretty scalable.
> > * detail rules, but RAM is limited... if you're serious, you need to
> > get into paging and/or compression. Detail overlays, tiling,
> > splatting, procedural texturing etc can all be thought of as
> > compression techniques in some sense.
>
> right, has anyone any experience with texture-compression (s3tc,dds
> ...) ? How is the quality of the textures? How fast is the generation?
> (when generating compressed textures in realtime)
My system is totally ad hoc, based on synthesis (and also RLE of some
of the control data), but I suspect that something like JPG would work
great for generic image data. It's probably faster than grabbing
uncompressed data off the disk, anyway.
> > Those are the principles, the rest is just a bunch of minor
> > details... :)
>
> The problem sometimes is in the detail !
^^^^^^^^^
always!
--
Thatcher Ulrich <tu...@tu...>
== Soul Ride -- pure snowboarding for the PC -- http://soulride.com
== real-world terrain -- physics-based gameplay -- no view limits
|
×
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