POV-Ray : Newsgroups : povray.unofficial.patches : Feasibility of features for 0.6 Server Time
2 Sep 2024 06:19:33 EDT (-0400)
  Feasibility of features for 0.6 (Message 1 to 8 of 8)  
From: Greg M  Johnson
Subject: Feasibility of features for 0.6
Date: 17 May 2000 07:57:17
Message: <39228815.F108998C@my-dejanews.com>
How hard would it be to add the following:
    1)  int(a)
    2)  mod(a,b)
    3)  a function that gives the true surface min & max extent of a
blob, not its overly spacious bounding box;
    4)  a function that gives the volume of an isosurface, blob, etc.


Post a reply to this message

From: Chris Huff
Subject: Re: Feasibility of features for 0.6
Date: 17 May 2000 08:20:55
Message: <chrishuff_99-870381.07242617052000@news.povray.org>
In article <39228815.F108998C@my-dejanews.com>, 
gre### [at] my-dejanewscom wrote:

>     1)  int(a)
>     2)  mod(a,b)

The int() and mod() functions are already in POV-Ray, perhaps you mean 
in isosurface functions?


>     3)  a function that gives the true surface min & max extent of a
> blob, not its overly spacious bounding box;

The blob object should probably have better bounding_box calculation, no 
need for a new function. In the meantime, you can do this yourself using 
a macro with trace(), there were some posted a while ago.


>     4)  a function that gives the volume of an isosurface, blob, etc.

Would this really be that useful? I don't know how it would be done...
I suppose you could approximate this in a macro by using eval_pattern 
with the blob or function pattern, by taking a bunch of samples in a 3D 
grid and discarding ones below the threshold value.

-- 
Christopher James Huff - Personal e-mail: chr### [at] yahoocom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://chrishuff.dhs.org/
TAG Web page: http://tag.povray.org/


Post a reply to this message

From: Greg M  Johnson
Subject: Re: Feasibility of features for 0.6
Date: 17 May 2000 08:45:50
Message: <39229375.C496478E@my-dejanews.com>
Chris Huff wrote:

> In article <39228815.F108998C@my-dejanews.com>,
> gre### [at] my-dejanewscom wrote:
>
> >     1)  int(a)
> >     2)  mod(a,b)
>
> The int() and mod() functions are already in POV-Ray, perhaps you mean
> in isosurface functions?

Yep

> >     3)  a function that gives the true surface min & max extent of a
> > blob, not its overly spacious bounding box;
>
> The blob object should probably have better bounding_box calculation, no
> need for a new function. In the meantime, you can do this yourself using
> a macro with trace(), there were some posted a while ago.

I wrote my own which calls 2500 trace functions in a grid bounded by min &
max extent.  Seems a bit brutish. If mega did this, it would just do the
same thing, you're saying?

> >     4)  a function that gives the volume of an isosurface, blob, etc.
>
> Would this really be that useful? I don't know how it would be done...
> I suppose you could approximate this in a macro by using eval_pattern
> with the blob or function pattern, by taking a bunch of samples in a 3D
> grid and discarding ones below the threshold value.

In my world, esoteric math thingies are more fun than photorealism. My
applications may be a bit eclectic and not worth the effort of the whole pov
team's development activity:A)    Seeing just how much space is in the
noise3d function. (I'm already working in my head on a way to do this
metallographically).
B)    I wanted to make physics-accurate (not merely  physically accurate)
motion of a blob character, and I was thinking that knowing its mass
distribution would help.
C)    In making advanced flocking algorithms, I was starting to wonder if
it's possible to use the 'mass' of the landscape within a certain radius
that it's about to collide with to guide its direction for graceful, smooth,
near-collisions.
D)    If you build it, they will find it useful.


Post a reply to this message

From: Warp
Subject: Re: Feasibility of features for 0.6
Date: 17 May 2000 09:22:27
Message: <39229d13@news.povray.org>
My intuition says that there should be a way to mathematically calculate
the exact bounds of a blob.
  Well, it could also be an analytically unsolvable problem, but who knows?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/


Post a reply to this message

From: Peter Popov
Subject: Re: Feasibility of features for 0.6
Date: 17 May 2000 13:36:44
Message: <68e5is82vc51a1ikamac6a3n5kk9pfeqoo@4ax.com>
On 17 May 2000 09:22:27 -0400, Warp <war### [at] tagpovrayorg> wrote:

>  My intuition says that there should be a way to mathematically calculate
>the exact bounds of a blob.
>  Well, it could also be an analytically unsolvable problem, but who knows?

I've seen at least two programs which triangulate blobs quite well,
and finding the bounds of a mesh is LAEFTR :) Also, the volume of a
mesh is easily calculated by integration, provided the vertices of all
faces come in a specified order (clockwise or counter-clockwise).

It *might* just have an analytical solution for simple blobs (spheres
only, no cylinders or ellipsoids). I'll dig around.


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] usanet
TAG      e-mail : pet### [at] tagpovrayorg


Post a reply to this message

From: Chris Huff
Subject: Re: Feasibility of features for 0.6
Date: 17 May 2000 17:14:03
Message: <chrishuff_99-B86A09.16173417052000@news.povray.org>
In article <39229375.C496478E@my-dejanews.com>, 
gre### [at] my-dejanewscom wrote:

> I wrote my own which calls 2500 trace functions in a grid bounded by 
> min & max extent.  Seems a bit brutish. If mega did this, it would 
> just do the same thing, you're saying?

It is the only way I can think of to calculate the bounding box of an 
arbitrary object fairly accurately with the available data. A built-in 
function to do this would be faster, but would most likely have to do 
the same thing.
On the other hand, improving the blob bounding_box calculation would do 
the job with min_ and max_extent(), and would also make blob rendering 
faster.


> In my world, esoteric math thingies are more fun than photorealism. 
> My applications may be a bit eclectic and not worth the effort of the 
> whole pov team's development activity:
> A)    Seeing just how much space is in the noise3d function. (I'm 
> already working in my head on a way to do this metallographically).
> B)    I wanted to make physics-accurate (not merely physically 
> accurate) motion of a blob character, and I was thinking that knowing 
> its mass distribution would help.
> C)    In making advanced flocking algorithms, I was starting to 
> wonder if it's possible to use the 'mass' of the landscape within a 
> certain radius that it's about to collide with to guide its direction 
> for graceful, smooth, near-collisions.
> D)    If you build it, they will find it useful.

Some interesting uses for it...but it still might be done better as a 
macro. You could do it in several ways:
1: You can do an inside-outside test on any object by using the 
eval_pattern() function with the object pattern, doing this on many 
points in the object's bounding box could give a fairly good estimate.
2: You could use the trace function...trace until you hit the object, 
trace again, use the resulting distance from many of these done in a 
grid to calculate the volume. Not as reliable, but probably faster. You 
could probably combine the two methods in some way.

Oh, and for "B", you have to consider that volume is not a good 
indication of mass...the chest cavity wouldn't compare well with the 
upper leg, for example.
And for "C", have you considered using eval_pattern() with the proximity 
pattern?

-- 
Christopher James Huff - Personal e-mail: chr### [at] yahoocom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://chrishuff.dhs.org/
TAG Web page: http://tag.povray.org/


Post a reply to this message

From: Warp
Subject: Re: Feasibility of features for 0.6
Date: 18 May 2000 03:56:55
Message: <3923a247@news.povray.org>
Peter Popov <pet### [at] usanet> wrote:
: I've seen at least two programs which triangulate blobs quite well,
: and finding the bounds of a mesh is LAEFTR :)

  But that's still a (non-analytical) approximation, not a mathematically
exact measurement. It's a kind of sampling method.
  What I meant was that from the equation of a blob it could be possible
to analytically solve its limits in a mathematically exact way.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/


Post a reply to this message

From: Michael Andrews
Subject: Re: Feasibility of features for 0.6
Date: 18 May 2000 07:44:19
Message: <3923D7DC.4FBED117@reading.ac.uk>
Hi Greg,

"Greg M. Johnson" wrote:
> 
> How hard would it be to add the following:

Not hard at all ...

>     1)  int(a)

int(x) == function { x-(x%1.0) }

since

>     2)  mod(a,b)

mod(a,b) == function { a%b }

>     3)  a function that gives the true surface min & max extent of a
> blob, not its overly spacious bounding box;
>     4)  a function that gives the volume of an isosurface, blob, etc.

Bye for now,
	Mike Andrews.


Post a reply to this message

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