POV-Ray : Newsgroups : povray.programming : Which code evaluate Math functions (ie: isosurfaces) ? : Re: Which code evaluate Math functions (ie: isosurfaces) ? Server Time
27 Apr 2024 07:03:46 EDT (-0400)
  Re: Which code evaluate Math functions (ie: isosurfaces) ?  
From: Ben Chambers
Date: 14 Feb 2007 19:58:24
Message: <45d3b030$1@news.povray.org>
virtualmeet wrote:
> Ben Chambers <ben### [at] pacificwebguycom> wrote:
>> The problem is, you will LOSE on the quality front.
>> ...
>> You are essentially saying "If you just ditch your quality concerns, and
>> use polygonal tessellation instead, you could have much faster renders!"
> Hi,
> What I'm saying is that there is probaly a way to render images faster by
> using an "intelligent" parser: this "intelligence" came from given it some
> geometrical propertys of points to render. Also, the quality of images will
> be the same.

I don't think you're using the word "parser" in the same way it is used 
in POV-Ray.  The "parser" in POV reads SDL from a file into memory.  You 
seem to be talking about the actual trace code.

> I think that people get confused with what I'm saying because there is a
> deep thought that it's impossible to "improve" the parser (the part of the
> code that perform math functions).

On the contrary, we know its very possible to improve the speed of 
things (speaking of math functions, and not the SDL parser), we just 
don't agree with sacrificing quality for speed.  If we did, we'd be 
using 3DS, Maya, or some other mesh modeler.

> What I'm saying is that the actual way
> of doing math calculations (and this in every field where a parser is
> needed) IS OVER : People should think about using geometrical propertys
> when performing math calculations...

I agree, using all applicable knowledge of a shape can lead to amazing 
speed improvements.  However, it's not the kind of thing which has been 
traditionally possible to teach a computer to do, as each situation is 
highly unique.  And your voxel array certainly doesn't add anything in 
terms of geometric analysis, other than approximation.

> I don't know how well this will work with PovRay but for me I'm already
> doing some calculations more than 30 times faster than before! and I'm

I'd say you're falling short of your potential, then.  If you really 
want a speed bump, properly utilizing a graphics card can give you a 
speed increase of several thousands of times.  However, such methods 
compromise quality in a way which is not accepted by this community.

> To be honest, I start thinking that some heivy demanding math applications
> should be rewritten in the perspective to take advantage of that kind of
> "technologie": The parser should "impose" the way math calculations will be
> done and applications should be adapted to that fact.

When you're a hammer, the whole world looks like a nail...  I'm against 
the system imposing on the user any method, as its a case of the tail 
wagging the dog.  Rather than adapting ourselves (and our programs) to 
fit the current fad system, we should adapt systems to suit our needs.

...Chambers


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.