RE: [Algorithms] terrain texturing

[Akbar A. <sye...@ea...>]

>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