I'm worry that my english is poor for explain my imagination but I try
write this little story with http://www.ectaco.com/online/. I write to
two groups, if you want continue only in one, just cut second, please.

I. Introduction

   Looking at quadric I see very complicated equation. I know math, than
I can (hardly) simulate this on paper. Then I can simple discover that
there are some special quadrics such sphere, cone, cylinder. They have
special routines for calculate normals but still are quadric. They have
own parameters like radius, coordinates instead of set of factors.
   I know that most povers know this example of specialization. In this
post I want propose another specialization in povray. I'am talking about
interested specialization of some isosurfaces/isofunctions. Or rather
barrow technic from isosurface with special functions to new technic in
POV-Ray.

II. Looking at isosurfaces

   Using isosurface we can describe interior of object. We can displace
its surface with noise or patterns. But we can also do something more.
We can convert coordinates from one geometry to another. For example we
can convert
     box { <-1,-1,-1> <1,1,1> }
exactly to
     cone { <0,0,0> 1 <1,1,1> 0 }
As exactly converted objects I mean that every point from one has its
own corresponding point in second object. Usually there are some special
points (top of cone) which isn't, but we can enumerate such special
points. You can ask how can we convert box to cone or cone to box. Just
this way:
     box: <x,y,z>
     P=<x,0,z>
     l=vlength(P)
     lmax=min(length(P/x),length(P/z)) // forget 0
     r=(1-y)/2
     P=r*P/lmax
     cone: <P.x,1-r,P.z>
but this conversion is not main subject, this is only example. Another
example is my post "is over iso vers." from 8:11:2000 9:20 sended as
picture to p.b.i - there is object of twenty isosurfaces
"Witch_of_Agnesi" along y, all enclosed in
     cylinder { <0,0,0> <0,1,0> 1 }
and displaced along family of parabols. This way we can achive plants or
opened skin of bananas or something similiar. Showed displacements are
only prepared for fun but I can imagine such function which describe
displacements from physics: twister, bender, strecher, curver, mirage
(non regular waves like hot air over desert). They are non-linear
transformations, right ?

III. Inherit something

   From isosurfaces we can inherit method of searching first point of
ray and calculate normal but instead of searching equipotential surface
of f=0 this should find border between inside and outside. And for every
calculated point this should return all texture properities: finish,
pigment, normal, ior etc.
   Instead of toilsome calculation for every isosurface with
displacements supported by POV, we can put modificator (non-linear
transformation) to prepared objects - csg, primitives, another
isosurfaces. We should control this with specialized parameters - in
strecher we can put factor for material and force; in curver we bound
base object with cylinder and put this cylinder proportional along
spline. The rest belongs to parser - enclose parts with different
displacements rules and calculate proper factors for functions. From
syntax of isosurfaces we can also inherit "accuracy" and other
parameters if there is no way to calculate.

IV. Syntax

   I don't know how this can be putted in POV's language. Perhaps:

  #declare MyObject=object{
    union { box{} intersection { .. } .. }
    scale, translate, rotate
    non-linear {
      type /* bender, twister, etc. */
      syntax_proper_for_type
    }
  }

or maybe this way:

  #declare MyObject=modificator{
    object { MyBaseObject }
    type /* bender, twister, etc. */
    syntax_proper_for_type
  }

or meybe completly different.

V. To do

   I don't think that my idea is great. There is many to discuss.
Perhaps this is imposible or perhaps possible but completly different. I
only want to inspire. I'm programmer but I think I'm not proper person
to do this stuff. First of all I have a lot to do in my company and I
have some web sites to care about and update. Even for my first planned
patch I have no time. But I want to inspire somebody to play with
sources (I think after 3.5). There shouldn't be to much to do: structure
with pointer to function and table of factors and technic to return
texture properities. Than all displacement can be supported by parser.
But it is always simple to say...

thanks for reading

ABX

Post a reply to this message

I think what you are suggesting is an isosurface solving method for all 
objects to allow non-linear transformations to be used...right?
This would be possible for many objects, but not for all...for example, 
meshes wouldn't be easy(though you could probably do some kind of 
proximity calculation).
Also, you wouldn't want to use the isosurface solving method to 
completely replace the existing method, since it is sometimes slower and 
less accurate. However, as an option, and even if only available for 
some objects, it could potentially be very useful.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff wrote in message ...
> I think what you are suggesting is an isosurface solving method for
all
> objects to allow non-linear transformations to be used...right?

right

> This would be possible for many objects, but not for all...for
example,
> meshes wouldn't be easy(though you could probably do some kind of
> proximity calculation).

yes, there could be checking for proper mesh
i.e. looking for declaration of inside_vector or something


> However, as an option, and even if only available for
> some objects, it could potentially be very useful.

especially for this users with small perception of math

ABX

Post a reply to this message

In povray.unofficial.patches Chris Huff <chrishuff@mac.com> wrote:
: Also, you wouldn't want to use the isosurface solving method to 
: completely replace the existing method, since it is sometimes slower and 
: less accurate.

  Specially with meshes. I suppose that if you substituted a big mesh
with a bunch of isosurfaces, your rendering time will go to the roof :)

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

  "The derivative of sin(2x) is cos(2x)"  - Matt Giwer

Post a reply to this message

Warp wrote:
> 
>   Specially with meshes. I suppose that if you substituted a big mesh
> with a bunch of isosurfaces, your rendering time will go to the roof :)
> 

Then again, you could forgo the isosurface method for meshes, and do the
non-linear transformations just on the vertices (after all, isn't that the usual
method of doing it - tessellating to a mesh and transforming the vertices?)

-- 
Margus Ramst

Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg

Post a reply to this message

In article <3A155772.F7735710@peak.edu.ee>, Margus Ramst 
<mar### [at] peakeduee> wrote:

> Then again, you could forgo the isosurface method for meshes, and do 
> the non-linear transformations just on the vertices (after all, isn't 
> that the usual method of doing it - tessellating to a mesh and 
> transforming the vertices?)

That is what I have heard...POV is the only 3D software I have any 
experience with.
Subdivision for meshes would also be nice...

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

In article <3a1524e7@news.povray.org>, "Wlodzimierz ABX Skiba" 
<abx### [at] abxartpl> wrote:

> yes, there could be checking for proper mesh
> i.e. looking for declaration of inside_vector or something

Insideness checking won't be enough, the isosurface solving method 
requires a continuously changing function, so you would need something 
which changes depending on distance from the surface of the mesh and 
which has a different sign on the inside of the mesh than on the outside.
A proximity function which decreases/increases linearly from 0 at the 
surface of the mesh, negative "inside" the mesh and positive "outside" 
the mesh would probably work quite well, but be slow, especially for 
large meshes, and not exactly easy to code...

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

On Fri, 17 Nov 2000 19:13:22 -0500, Chris Huff <chr### [at] maccom>
wrote:

>A proximity function which decreases/increases linearly from 0 at the 
>surface of the mesh, negative "inside" the mesh and positive "outside" 
>the mesh would probably work quite well, but be slow, especially for 
>large meshes, and not exactly easy to code...

Actually a proximity function for meshes wouldn't be that slow. Come
to think about it, you wouldn't need to trace any rays to find the
distance to the mesh at any point in space.


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

Post a reply to this message

In article <8ujb1ts0ro5h8l41asccr9rvaro1qgpnip@4ax.com>, Peter Popov 
<pet### [at] usanet> wrote:

> Actually a proximity function for meshes wouldn't be that slow. Come
> to think about it, you wouldn't need to trace any rays to find the
> distance to the mesh at any point in space.

It would be speedy compared to the current "shoot a bunch of samples" 
method, but compared to a sphere or box proximity function, it certainly 
would be slow.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

On Fri, 17 Nov 2000 20:18:08 -0500, Chris Huff <chr### [at] maccom>
wrote:

>> Actually a proximity function for meshes wouldn't be that slow. Come
>> to think about it, you wouldn't need to trace any rays to find the
>> distance to the mesh at any point in space.
>
>It would be speedy compared to the current "shoot a bunch of samples" 
>method, but compared to a sphere or box proximity function, it certainly 
>would be slow.

LOL yeah. Still, with the current octree optimisation of meshes, it
could be significantly sped up. I'll think about it.


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

Post a reply to this message