Christoph Hormann's recent updates on his LOTW-project, inspired me to do some
work on my own LOTW-system.  Now, this is a technique-in-progress (TIP?).  A
radial height_field.  The idea is that parts of the landscape far away from the
camera don't need to be as detailed as the parts close to the camera.  So in
terms of regular height_fields, the resolution may decrease as the distance from
the camera increases.  This can easily be accomplished by going through the
points in your height_field-image (or function in this case) not in a
rectangular way, like regular height_fields, but in a radial way.

Hope you understand what I'm talking about :)

Oh, and, uhm, it might be an interesting technique, but I'm afraid, it's not
very useful: parse-time increases and trace-time doesn't really seem to be less
than an ordinary height_field :-/

cu!
--
camera{location-z*3}#macro G(b,e)b+(e-b)*(C/50)#end#macro L(b,e,k,l)#local C=0
;#while(C<50)sphere{G(b,e),.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1
;#end#end L(y-x,y,x,x+y)L(y,-x-y,x+y,y)L(-x-y,-y,y,y+z)L(-y,y,y+z,x+y)L(0,x+y,
<.5,1,.5>,x)L(0,x-y,<.5,1,.5>,x)                 // ZK http://www.povplace.com

Post a reply to this message

Attachments:
Download 'radialheightfield.jpg' (54 KB)

Preview of image 'radialheightfield.jpg'

Zeger Knaepen wrote:

> Christoph Hormann's recent updates on his LOTW-project, inspired me to do
> some
> work on my own LOTW-system.  Now, this is a technique-in-progress (TIP?). 
> A
> radial height_field.  The idea is that parts of the landscape far away
> from the
> camera don't need to be as detailed as the parts close to the camera.  So
> in terms of regular height_fields, the resolution may decrease as the
> distance from
> the camera increases.  This can easily be accomplished by going through
> the points in your height_field-image (or function in this case) not in a
> rectangular way, like regular height_fields, but in a radial way.
> 
> Hope you understand what I'm talking about :)
> 
> Oh, and, uhm, it might be an interesting technique, but I'm afraid, it's
> not very useful: parse-time increases and trace-time doesn't really seem
> to be less than an ordinary height_field :-/
> 

I had a similar idea, also abandoned, my take was to use the camera 
parameters (direction, width, height) to control the nummer of points. It 
was no faster but the memory consumption seemed lower. here's a sample 
image just to prove I'm not just BS-ing :-)

-- 
Bill Hails
http://thyme.homelinux.net/

Post a reply to this message

Attachments:
Download 'smooth.jpg' (44 KB)

Preview of image 'smooth.jpg'

Zeger Knaepen wrote:
> Christoph Hormann's recent updates on his LOTW-project, inspired me to do some
> work on my own LOTW-system.  Now, this is a technique-in-progress (TIP?).  A
> radial height_field.  The idea is that parts of the landscape far away from the
> camera don't need to be as detailed as the parts close to the camera.  So in
> terms of regular height_fields, the resolution may decrease as the distance from
> the camera increases.  This can easily be accomplished by going through the
> points in your height_field-image (or function in this case) not in a
> rectangular way, like regular height_fields, but in a radial way.
> 
> Hope you understand what I'm talking about :)
> 
> Oh, and, uhm, it might be an interesting technique, but I'm afraid, it's not
> very useful: parse-time increases and trace-time doesn't really seem to be less
> than an ordinary height_field :-/

The idea is interesting, though. I wonder if it would work better 
implemented in code than SDL.

-Xplo

Post a reply to this message

> The idea is interesting, though. I wonder if it would work better 
> implemented in code than SDL.
I guess it's somewhat unnecessary with heightfields. Unless you got a
*very* detailed one, I doubt the effect will be very noticeable. It
would be really nice with isosurfaces (wasn't there anyone doing some
stuff in that direction?) and with terrain generators or things like
that. IIRC it's a standard feature for meshes in most commercial packages.


Florian
-- 
camera{look_at-y*10location<8,-3,-8>*10}#local a=0;#while(a<999)sphere{
#local _=.01*a-4.99;#local p=a*.01-5;#local c=.01*a-4.995;<sin(p*pi)*5p
*10pow(p,5)*.01>sin(c*c*c*.1)+1pigment{rgb 3}}#local a=a+1;#end
/******** http://www.torfbold.com ******** http://www.imp.org ********/

Post a reply to this message

"Xplo Eristotle" <xpl### [at] infomagicnet> wrote in message
news:42891452@news.povray.org...
> The idea is interesting, though. I wonder if it would work better
> implemented in code than SDL.

It will probably parse a lot faster, but the trace-speed should be the same.

cu!
--
camera{location-z*3}#macro G(b,e)b+(e-b)*(C/50)#end#macro L(b,e,k,l)#local C=0
;#while(C<50)sphere{G(b,e),.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1
;#end#end L(y-x,y,x,x+y)L(y,-x-y,x+y,y)L(-x-y,-y,y,y+z)L(-y,y,y+z,x+y)L(0,x+y,
<.5,1,.5>,x)L(0,x-y,<.5,1,.5>,x)                 // ZK http://www.povplace.com

Post a reply to this message

"Florian Brucker" <tor### [at] torfboldcom> wrote in message
news:4289163d$1@news.povray.org...
> > The idea is interesting, though. I wonder if it would work better
> > implemented in code than SDL.
> I guess it's somewhat unnecessary with heightfields. Unless you got a
> *very* detailed one, I doubt the effect will be very noticeable.

Yes, but it was supposed to be for *very* detailed height_fields :)
I just rendered a low-resolution radial height_field to more clearly show what
it is :)

> It
> would be really nice with isosurfaces (wasn't there anyone doing some
> stuff in that direction?) and with terrain generators or things like
> that. IIRC it's a standard feature for meshes in most commercial packages.

But most commercial packages use scanline-rendering, where the speed is
proportional to the amount of polygons in the scene.  With raytracing, it's
different.  The main factor is the image resolution, not the scene-detail.
Extremely detailed scenes will render faster with raytracing than with scanline
rendering.  So I really wonder if a LOD-system for height_fields has any use :-/

cu!
--
camera{location-z*3}#macro G(b,e)b+(e-b)*(C/50)#end#macro L(b,e,k,l)#local C=0
;#while(C<50)sphere{G(b,e),.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1
;#end#end L(y-x,y,x,x+y)L(y,-x-y,x+y,y)L(-x-y,-y,y,y+z)L(-y,y,y+z,x+y)L(0,x+y,
<.5,1,.5>,x)L(0,x-y,<.5,1,.5>,x)                 // ZK http://www.povplace.com

Post a reply to this message

On Tue, 17 May 2005 00:10:54 +0200, Zeger Knaepen wrote:

> The main factor is the image resolution, not the
> scene-detail.

Well, perhaps - the thought that comes to my mind is the parse time -
that's still going to be a factor of the number of objects/polygons in the
scene regardless, so lowering the detail level farther away from the
camera could potentially save some time - and quite possibly some memory
(which might be more significant).

It might be interesting with this technique to look at memory consumption.

Jim

Post a reply to this message

"Jim Henderson" <nos### [at] nospamcom> wrote in message
news:pan### [at] nospamcom...
> On Tue, 17 May 2005 00:10:54 +0200, Zeger Knaepen wrote:
>
> > The main factor is the image resolution, not the
> > scene-detail.
>
> Well, perhaps - the thought that comes to my mind is the parse time -
> that's still going to be a factor of the number of objects/polygons in the
> scene regardless, so lowering the detail level farther away from the
> camera could potentially save some time - and quite possibly some memory
> (which might be more significant).
>
> It might be interesting with this technique to look at memory consumption.

ah, yes, now I remember why I tried this :)

no really, I forgot :-/

Maybe I need to buy me some more memory :)

cu!
--
camera{location-z*3}#macro G(b,e)b+(e-b)*(C/50)#end#macro L(b,e,k,l)#local C=0
;#while(C<50)sphere{G(b,e),.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1
;#end#end L(y-x,y,x,x+y)L(y,-x-y,x+y,y)L(-x-y,-y,y,y+z)L(-y,y,y+z,x+y)L(0,x+y,
<.5,1,.5>,x)L(0,x-y,<.5,1,.5>,x)                 // ZK http://www.povplace.com

Post a reply to this message

On Tue, 17 May 2005 00:53:33 +0200, Zeger Knaepen wrote:

> ah, yes, now I remember why I tried this :)
> 
> no really, I forgot :-/
> 
> Maybe I need to buy me some more memory :)

<G>

The thought of how complex the scenes are that I can create with 2 GB of
memory with a technique that reduces memory consumption are somewhat
mind-boggling.  Not to mention that I've not done anything near complex
enough to warrant using all the memory in my machine. <G>

Jim

Post a reply to this message

"Zeger Knaepen" <zeg### [at] studentkuleuvenacbe> schreef in bericht
news:42891a68@news.povray.org...
> "Florian Brucker" <tor### [at] torfboldcom> wrote in message
> news:4289163d$1@news.povray.org...
> > It
> > would be really nice with isosurfaces (wasn't there anyone doing some
> > stuff in that direction?) and with terrain generators or things like
> > that. IIRC it's a standard feature for meshes in most commercial
packages.
>
> But most commercial packages use scanline-rendering, where the speed is
> proportional to the amount of polygons in the scene.  With raytracing,
it's
> different.  The main factor is the image resolution, not the scene-detail.
> Extremely detailed scenes will render faster with raytracing than with
scanline
> rendering.  So I really wonder if a LOD-system for height_fields has any
use :-/
>

Still, that idea of Florian, to apply the technique to isosurfaces, seems
interesting to me. It would not parse faster I suppose, but wouldn't it
render faster?

Thomas

Post a reply to this message