![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <39228815.F108998C@my-dejanews.com>,
gre### [at] my-dejanews com 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] yahoo com
TAG(Technical Assistance Group) e-mail: chr### [at] tag povray org
Personal Web page: http://chrishuff.dhs.org/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Chris Huff wrote:
> In article <39228815.F108998C@my-dejanews.com>,
> gre### [at] my-dejanews com 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 17 May 2000 09:22:27 -0400, Warp <war### [at] tag povray org> 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] usa net
TAG e-mail : pet### [at] tag povray org
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <39229375.C496478E@my-dejanews.com>,
gre### [at] my-dejanews com 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] yahoo com
TAG(Technical Assistance Group) e-mail: chr### [at] tag povray org
Personal Web page: http://chrishuff.dhs.org/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Peter Popov <pet### [at] usa net> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |