Ha thats funny since it does not sound quite perfect to me. 

Warp wrote:
> 
> Rune <run### [at] inamecom> wrote:
> : I've noticed before that you take what other people say very very literally.
> 
>   I'm sorry. I'm too perfectionist.
> 
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <399162a1@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   I'm sorry. I'm too perfectionist.

That is usually "too much of a perfectionist", or "too perfectionistic".

Sorry, couldn't resist. :-)

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

Post a reply to this message

Warp wrote:
<snip>

>   How do you convert a julia_fractal to an isosurface? What about 'text'?

"object" pattern ? - probably would only work for solid objects

> Bicubic patches? Meshes? Polygons?
>   What about infinite surfaces like planes and polys? An isosurface can't be
> infinite since it has to be contained by a finite object.

These may not work

>   You ideas are very good, though.

I agree

--
Bye
Pabs

Post a reply to this message

In article <39920E80.B2D662D0@hotmail.com>, Pabs <pab### [at] hotmailcom> 
wrote:

> "object" pattern ? - probably would only work for solid objects'

The object pattern will only work for objects that are solid, and it 
isn't very friendly with the isosurface solving method. It is a "block 
pattern", and has only one of two states...basically meaning it has an 
infinite max_gradient. The isosurface algorithm can't easily cope with 
this.


> > Bicubic patches? Meshes? Polygons?
> >   What about infinite surfaces like planes and polys? An isosurface 
> >   can't be
> > infinite since it has to be contained by a finite object.
> 
> These may not work

Bicubic patches might be approximated with a function of some sort, 
though you might have to clip the resulting surface yourself. Polygons 
wouldn't be possible, but prisms would be. Plane, quadratic, poly, 
quartic, etc would work fine, they would just be clipped to the 
contained_by object. Meshes...I don't think there is an easy way to 
support meshes. Maybe if you used a sort of proximity pattern(optimized 
for meshes, of course)...


> >   You ideas are very good, though.
> 
> I agree

As do I...many of the object *could* have built in functions.
As for the existing built in functions, I really hope their syntax is 
changed if they are included. It is really non-standard, non-POV, and 
inconsistent.(Parameters in a vector?!? Function names in a string? 
Results affected by the size of the bounding box? Etc...)

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

Post a reply to this message

On Wed, 09 Aug 2000 21:52:16 -0500, Chris Huff wrote:
>
>As do I...many of the object *could* have built in functions.
>As for the existing built in functions, I really hope their syntax is 
>changed if they are included. It is really non-standard, non-POV, and 
>inconsistent.(Parameters in a vector?!? Function names in a string? 
>Results affected by the size of the bounding box? Etc..

I'm pretty sure they'll either be changed or removed.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

Ron Parker wrote:

>  removed.

???????????? Why
IMVHO I don't think they should be removed esp the superellipsoid type
one.
--
Bye
Pabs

Post a reply to this message

On Fri, 11 Aug 2000 09:48:41 +0800, Pabs wrote:
>Ron Parker wrote:
>
>>  removed.
>
>???????????? Why
>IMVHO I don't think they should be removed esp the superellipsoid type
>one.

Fixed is more likely, but they obviously can't stay like they are.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

> Rune <run### [at] inamecom> wrote:
> : I've noticed before that you take what other people say very very literally.

Warp wrote:
>   I'm sorry. I'm too perfectionist.

I have the same problem sometimes, and I put it down to being liberal. 
As a lifelong science fiction fan, I'm accustomed to having people write
things that are outrageous at first sight but literally meaningful in
the proper context; so if a sentence puzzles me, I try to think *how* it
might be meaningful ... rather than thinking the writer was simply
sloppy.

-- 
Anton Sherwood  --  br0### [at] p0b0xcom  --  http://ogre.nu/

Post a reply to this message

Chris Huff wrote:
> The object pattern will only work for objects that are solid, and it
> isn't very friendly with the isosurface solving method. It is a "block
> pattern", and has only one of two states...basically meaning it has an
> infinite max_gradient. The isosurface algorithm can't easily cope with
> this.

I'm coming into this late and ignorant (haven't even compiled megapov
yet), so ignore me if I say something too stupid ...

Rune asked for a "function" equivalent to a given cone.  What about
having this mean a function of the angle between the point in question,
the tip of the cone and the axis of the cone, ranging from 0 (axis,
outside) to 1 (axis, inside), adjusted so that a point on the surface of
the cone has function value 1/2 ?

The base of the cone can be represented by a ramp function, and thus the
whole finite cone function is the min() of these two.

To illustrate, suppose a standard cone has its apex at the origin, its
base at y=-1, and a 45 degree slope ...

	float cone (float x, float y, float z)
	{
	float r = sqrt(x*x+z*z);
	return 0.5 - atan2(y+r,r)/pi;
	}

	float cone_base (float x, float y, float z)
	{
	if (y<-2) return 0;
	if (y>0) return 1;
	return 1+y/2;
	}

	float finite_cone (float x, float y, float z)
	{
	return min( cone(x,y,z), cone_base(x,y,z) );
	}

-- 
Anton Sherwood  --  br0### [at] p0b0xcom  --  http://ogre.nu/

Post a reply to this message

In article <39964397.4C636C6C@pobox.com>, Anton Sherwood 
<bro### [at] poboxcom> wrote:

> Rune asked for a "function" equivalent to a given cone.  What about
> having this mean a function of the angle between the point in question,
> the tip of the cone and the axis of the cone, ranging from 0 (axis,
> outside) to 1 (axis, inside), adjusted so that a point on the surface of
> the cone has function value 1/2 ?

The equation for a cone is actually simpler, just the equation for a 
cylinder with the radius variable along the axis of the cone, like:

function {((Ra - Rb)*y + Rb) - sqrt(sqr(x) + sqr(z))}
(threshold value of 0, Ra is upper radius, Rb is lower radius)

You just have to clip it to the right length(possibly using the & 
operator with two plane functions, or by just using the container 
object). No trig functions are necessary. It is probably a good idea to 
keep it axis-aligned, this makes some displacements easier to do, 
simplifies the function, and is faster.

But what I think Rune wants is a way to use objects in isosurfaces 
*without having to write the functions*. This would be difficult, it 
would require adding density functions to objects which don't have them, 
and would probably use a syntax similar to the pigment functions. An 
alternative would be to use the proximity pattern, though it really 
isn't very useable for this purpose in it's current state. You might 
also be able to use the blob pattern, there may be some modifications 
which would make it more useful for this.

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

Post a reply to this message