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

> I think about joining my method and method with deforming vertices
> my method will be applied when you type predefined deform i.e. twist
> or type deformations with two defined functions (bi-directional 
> deformation)
...snip...
> but when you put only one user defined function or you type deformations
> one-directional - this cause error
...snip...
> noticed parsing *Error*: Only one direction of deformation specified 
> - to achive proper shape please tesselate it first!
> 
> and user must add tesselation with parameters he wants
> 
> box
>  {
>   1, 1
>   tesselation { 7, 13, 15}
>   deform {warp{...}}
>   deform {MyDeformFunc(x,y,z,3,5)
>  }
> 
> and this is parsed ok.

I'm not sure this is a good idea...what if the user wants to use 
ordinary deformations on tesselated objects, which are just meshes? 
Sometimes you have very low resolution meshes which are representing 
straight edged objects (a 12-triangle cube mesh, for example), and if 
you apply per-vertex deformation without subdividing the triangles, it 
will look pretty ugly. Subdividing the triangles is another thing to 
think about, but after the basic functionality is there...and my point 
is that the user should be able to choose the method.
For example, have "method 0" be the "direct displacement" method which 
has highest possible accuracy but is limited to reversable deformations, 
and "method 1" be the per-vertex method. When "method 1" is used, have 
optional tesselation information in the deform block...POV would 
automatically tesselate the object if needed (or "always_tesselate" 
could be turned on to process meshes).
box {1, 1
    deform {warp{...}
        method 1
        tesselation_options {
            [always_tesselate on|off]
            [other options and parameters]
        }
    }
    deform {MyDeformFunc(x,y,z,3,5)
}


> note that parameters above are only example and has no meaning this 
> way for such simple deformations like twisting you don't need waste 
> memory for copy of recalculated vertex becouse all is done with 
> curved ray - but there is gate for user defined deformation
> there is even place for control points

I like your function syntax. :-)
I'm not sure how the function does a deformation, though...are you 
planning to extend them to return vectors, or to allow them to modify 
their parameters? Or will you create a special kind of function that is 
3 ordinary functions bundled into one? I kind of like that last 
solution, especially if functions are allowed to have variables...I 
think the basic syntax should remain scalars-only, though.

#declare DeformationByControlPoint =
function_3d(
    Point_X,
    Point_Y,
    Point_Z,
    ControlPoint_X,
    ControlPoint_Y,
    ControlPoint_Z,
    Radius,
    Power=1)
{
    local Foo = blah blah...;
    {x = Bar1;},
    {y = Bar2;},
    {z = Bar3;}
}


> > Similar to the way patterns and warps are done: a set of predefined
> > deformations and maybe function-defined deformations. Maybe warps too.
> 
> please notice that you are really convincing
> in talking about warps deformations

I was? It didn't seem like it at the time... ;-)
BTW, I saw your question about reversable turbulence in 
comp.graphics.algorithms, but it disappeared before I could reply...I 
probably just forgot to mark it unread. Anyway, you might find more help 
if you say it is a Perlin noise texture deformation.

-- 
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