Rune wrote in message <3a671821@news.povray.org>...
> > fine. looking at your example I have a question
> > is there any difference beetween this result and
> > results of my deform patch presented in p.b.i
> > during last month ?
>
> Last I heard, your deform patch could do reversible deformations only.

yes, it is the worst thing in it :-(
it is price of working with all object types
but I plan to mix it with tessalation patch and allow
one directional deformations for meshes
and bidirectional for other objects

> With my method any deformation can be done.

congratulations

> > as long as you work on mesh this is faceted but my
> > patch work fine with *any* object
>
> Doesn't this slow down the rendering?

a little, but only traced points are calculated
imagine zooming on object
when it is small for camera it don't need deform all vertices
and when you deform{csg{}} boundings remove not necessary rays
perhaps I'm talking little hermetic becouse onfortunatly only me know my patch
:(

> My method does not slow down the rendering at all. The parsing is a bit slow
> though.

my parsing time is not changed and rendering time depends of area on image (you
know - boundings)

> > I'll make animated example for you perhaps there
> > should be speed comparison mesh->mezz->rendering will
> > win but perhaps deform->teselation->rendering could be
> > more accurate
>
> My method produces results as accurate as the input mesh is.

but more accuracy -> more vertices -> more parse time, right ?

ABX

Post a reply to this message

"Wlodzimierz ABX Skiba" wrote:
> I plan to mix [the deform patch] with tessalation patch
> and allow one directional deformations for meshes and
> bidirectional for other objects

That's interesting. The mesh deformation would be handled in a *completely*
different way than for other objects, right?

> > Doesn't this slow down the rendering?
>
> a little

> my parsing time is not changed

But for deformed meshes the parsing time would increase and rendering time
would be unchanged, like with my macro, I think.

I'm sure a mesh deforming patch would be much quicker than my mesh deforming
macro. It's just that nobody has made such a patch *yet*...

Also, my macro gives the user full control over the deformation. How would
the user control the deformation in your patch? (I mean the deformations for
meshes.)

> but more accuracy -> more vertices -> more parse time, right ?

Yes. I never said it was quick... :)

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

In article <3a6746fe@news.povray.org>, "Rune" <run### [at] inamecom> 
wrote:

> "Wlodzimierz ABX Skiba" wrote:
> > I plan to mix [the deform patch] with tessalation patch
> > and allow one directional deformations for meshes and
> > bidirectional for other objects
> 
> That's interesting. The mesh deformation would be handled in a 
> *completely* different way than for other objects, right?

I think he is talking about a different deformation method that will 
work for all objects, but work by first converting them to a mesh.


> Also, my macro gives the user full control over the deformation. How 
> would the user control the deformation in your patch? (I mean the 
> deformations for meshes.)

Similar to the way patterns and warps are done: a set of predefined 
deformations and maybe function-defined deformations. Maybe warps too.

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

Rune wrote in message <3a6746fe@news.povray.org>...
> "Wlodzimierz ABX Skiba" wrote:
> > I plan to mix [the deform patch] with tessalation patch
> > and allow one directional deformations for meshes and
> > bidirectional for other objects
>
> That's interesting. The mesh deformation would be handled in a *completely*
> different way than for other objects, right?

deformation applied to mesh copy array of recalculated vertex to another memory
location or aplies function to vertex during tracing - first solution: slow
parsing and memory wasting but fast rendering, second solution: fast parsing and
memory saving but slow tracing - this could be parametrized

> > > Doesn't this slow down the rendering?
> >
> > a little
>
> > my parsing time is not changed
>
> But for deformed meshes the parsing time would increase and rendering time
 >would be unchanged, like with my macro, I think.

but pach is faster than macro
and I think this is good usage patch solution instead of macro solutions

> I'm sure a mesh deforming patch would be much quicker than my mesh deforming
> macro. It's just that nobody has made such a patch *yet*...

but you are not first how think of it
I'm not first neither.
I have read nearly whole pov-ray news and I meet such propositions many times.
But not everyone has such programing skills.

> Also, my macro gives the user full control over the deformation. How would
> the user control the deformation in your patch? (I mean the deformations for
> meshes.)

I'm waiting with user control deformations for release 3.5 becouse I plan use
functions but want patch them first (if pov-team doasn't) to pass more
parameters. Functions stuff is so complicated and I don't want duplicate such
complicated work.

ABX

Post a reply to this message

Chris Huff wrote in message ...
> In article <3a6746fe@news.povray.org>, "Rune" <run### [at] inamecom>
> wrote:
>
> > "Wlodzimierz ABX Skiba" wrote:
> > > I plan to mix [the deform patch] with tessalation patch
> > > and allow one directional deformations for meshes and
> > > bidirectional for other objects
> >
> > That's interesting. The mesh deformation would be handled in a
> > *completely* different way than for other objects, right?
>
> I think he is talking about a different deformation method that will
> work for all objects, but work by first converting them to a mesh.

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)

box
 {
  1, 1
  texture { texture stuff }
  deform {twist 7}
  deform {MyDeformFunc(x,y,z,7,11) MyUndeformFunc(x,y,z,7,11)}
 }

but when you put only one user defined function or you type deformations
one-directional - this cause error

box
 {
  1, 1
  deform {warp{...}}
  deform {MyDeformFunc(x,y,z,3,5)
 }

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.

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

#declare DeformationByControlPoint=
  function
   (
    Point_X,
    Point_Y,
    Point_Z,
    ControlPoint_X,
    ControlPoint_Y,
    ControlPoint_Z,
    Radius,
    Power=1
   )
  {
   /* function changes Point if it is less than radius from Control Point */
  }

#declare MyDeform=deform
 {
  deform { DeformationByControlPoint(x,y,z,1,2,3,2)
  deform { DeformationByControlPoint(x,y,z,7,1,2,4,2)
  deform { DeformationByControlPoint(x,y,z,5,3,1,10)
 }

box
 {
  -1,2
  texture {}
  tesselate {}
  deform { MyDeform }
 }

>> Also, my macro gives the user full control over the deformation. How
>> would the user control the deformation in your patch? (I mean the
>> deformations for meshes.)
>
> 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

:-)

ABX

Post a reply to this message

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

"Chris Huff" wrote:
> "Rune" wrote:
> > Also, my macro gives the user full control over the deformation.
> > How would the user control the deformation in your patch? (I mean
> > the deformations for meshes.)
>
> Similar to the way patterns and warps are done: a set of predefined
> deformations and maybe function-defined deformations. Maybe warps too.

Predefined deformations does not give the user full control. Nor do warps.

POV-Ray functions returns floats and not vectors, don't they?

The only way the user can get full control, is by using functions where both
input and output are vectors.

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

"Wlodzimierz ABX Skiba" wrote:
> patch is faster than macro and I think this is good usage
> patch solution instead of macro solutions

I fully agree about this.
But a macro can be useful until the patch is ready.

It is also possible that the patch is not as flexible.
Will the user be able to use functions where both input and output is
vectors? That would be the only way to get full control over the
deformation.

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

Rune wrote in message <3a6868e6$1@news.povray.org>...
> "Wlodzimierz ABX Skiba" wrote:
> > patch is faster than macro and I think this is good usage
> > patch solution instead of macro solutions
>
> I fully agree about this.
> But a macro can be useful until the patch is ready.

I agree with it, but ... patch is nearly ready :-)
I don't want to forbid you play with your stuff
I'm just trying to compare results
if patch serves more accurate result it is worth to play for me.
perhaps you missed example: http://www.abx.art.pl/pov/nonlinear/step3.jpg
more images after weekend with wife and daughter :-)

and .... can you twist plane{} ? :-)
result is very interesting, belive me

> It is also possible that the patch is not as flexible.
> Will the user be able to use functions where both input and output is
> vectors?

in my specifications of possibilities, yes
in first version, no

> That would be the only way to get full control over the
> deformation.

this is part of my greater plans
I want patch functions to allow:
1. more/less input parameters
2. more output values
3. default values for some input parameters
4. local variables
5. calling during parsing

I've started with such patch in November and 1. and 3. works fine and 5. seems
be easy
but 2. and 4. is big thing and therefore I wait with that for source of POV 3.5
becouse I don't waste time for double coding. I don't know structure of sources
designed by Team for functions in 3.5 therefore I must wait.

ABX

Post a reply to this message

In article <3a6868e5$1@news.povray.org>, "Rune" 
<run### [at] inamecom> wrote:

> Predefined deformations does not give the user full control. Nor do 
> warps.
> 
> POV-Ray functions returns floats and not vectors, don't they?

Yes, but it might be possible to combine three of them into a single 
function that returns a vector. This would be best with variables in 
functions, but would be quite useable otherwise.
Or you could just use three separate functions...

-- 
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 povray.binaries.animations Rune <rune.johansen@iname.com> wrote:

> "Chris Huff" wrote:
>> "Rune" wrote:
>> > Also, my macro gives the user full control over the deformation.
>> > How would the user control the deformation in your patch? (I mean
>> > the deformations for meshes.)
>>
>> Similar to the way patterns and warps are done: a set of predefined
>> deformations and maybe function-defined deformations. Maybe warps too.

> Predefined deformations does not give the user full control. Nor do warps.

> POV-Ray functions returns floats and not vectors, don't they?

> The only way the user can get full control, is by using functions where both
> input and output are vectors.

Well, they could always define a function for each of x,y,z.  Little messy,
though.

Geoff

Post a reply to this message

"Wlodzimierz ABX Skiba" wrote:
> Rune wrote:
> > a macro can be useful until the patch is ready.
>
> I agree with it, but ... patch is nearly ready :-)

But maybe your patch is better for some purposes while my macro is better
for others.

> can you twist plane{} ? :-)

Not an infinite plane obviously, since meshes can't be infinite.

> > It is also possible that the patch is not as flexible.
> > Will the user be able to use functions where both input
> > and output is vectors?
>
> in my specifications of possibilities, yes
> in first version, no

With my macros user-defined deformations are very easy simple.
This is a simple twist:

#macro deform_mezz (P) vrotate(P,120*x*P.x) #end

How would a user-defined twist look with your patch?
(I do *not* mean the build-in twist-deform. I mean user-defined function!)

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

"Chris Huff" wrote:
> "Rune" wrote:
>
> > Predefined deformations does not give the user full control.
> > Nor do warps.
> >
> > POV-Ray functions returns floats and not vectors, don't they?
>
> Yes, but it might be possible to combine three of them into a
> single function that returns a vector. This would be best with
> variables in functions, but would be quite useable otherwise.
> Or you could just use three separate functions...

Doesn't sound intuitive at all I think!

I prefer a user-defined twist to be as simple to make as this:

#macro deform_mezz (P) vrotate(P,120*x*P.x) #end

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

In article <3a68a798@news.povray.org>, "Rune" <run### [at] inamecom> 
wrote:

> Doesn't sound intuitive at all I think!

I don't see how it is any less intuitive than the < X, Y, Z> vector 
syntax...the user would just be specifying expressions that would be 
evaluated when the function is computed instead of at parse time. Or 
were you talking about using three separate functions?


> I prefer a user-defined twist to be as simple to make as this:
> 
> #macro deform_mezz (P) vrotate(P,120*x*P.x) #end

Using macros would be too slow...and I've tried to figure out how to do 
it before, with no success. I think macros should remain parse-time, and 
that functions should be extended instead.

-- 
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:
> I don't see how it is any less intuitive than the < X, Y, Z>
> vector syntax...the user would just be specifying expressions
> that would be evaluated when the function is computed instead
> of at parse time.

But I don't really know how the <X,Y,Z> syntax would work.

What I would prefer is to deform a mesh just like I would deform a point.
Like this:

Translate by <1,2,3>: P+<1,2,3>
Scale by <1,2,3>: P*<1,2,3>
Rotate 55 degrees about A axis: vaxis_rotate(P,A,55)

To make more complicated deforms I can take advantage of #local or #declare:

#declare A = P*<1,2,1>;
#declare B = P+<2,1,1>;
vrotate(A,90*x*B.x)

I find that it couldn't be more simple and intuitive than this. Could a
deform function be made to work the same way?

> Using macros would be too slow...

The macro was not the important part.

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

In article <3a68ccf1@news.povray.org>, "Rune" <run### [at] inamecom> 
wrote:

> But I don't really know how the <X,Y,Z> syntax would work.

It would take the XYZ coordinates of a point and output new XYZ 
coordinates...you could even have built-in "vector" functions like 
vrotate and vaxis_rotate, though they would only return a component at a 
time. (vrotate_x(px, py, pz, rx, ry, rz), vaxis_rotate_y(), etc...


> What I would prefer is to deform a mesh just like I would deform a point.
> Like this:
> 
> Translate by <1,2,3>: P+<1,2,3>
> Scale by <1,2,3>: P*<1,2,3>
> Rotate 55 degrees about A axis: vaxis_rotate(P,A,55)
> 
> To make more complicated deforms I can take advantage of #local or 
> #declare:
> 
> #declare A = P*<1,2,1>;
> #declare B = P+<2,1,1>;
> vrotate(A,90*x*B.x)
> 
> I find that it couldn't be more simple and intuitive than this. Could a
> deform function be made to work the same way?

Not without a substantial amount of work...basically replicating the 
functionality of isosurface functions for vectors and writing code to 
parse stuff that looks like POV-Script on the fly. If this was easy or 
even just a bit difficult, don't you think it would have been done 
already for isosurface functions?


> > Using macros would be too slow...
> 
> The macro was not the important part.

Well, it should be possible to make a version of functions that handles 
only vectors, but it seems like an unnecessary inconsistency with the 
float version, and you likely wouldn't be able to use the two together.
And if you really want to use a macro, you could always read the data 
from the mesh, do what you want with it using a macro, and create a new 
mesh with it. (Using the mesh data stuff Warp wrote.)
Maybe you could provide a sample of the syntax you would use?

-- 
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:
> they would only return a component at a time.
> (vrotate_x(px, py, pz, rx, ry, rz), vaxis_rotate_y(), etc...

Ough!

> > What I would prefer is to deform a mesh just like I would
> > deform a point. I find that it couldn't be more simple and
> > intuitive than this. Could a deform function be made to
> > work the same way?
>
> Not without a substantial amount of work...basically
> replicating the functionality of isosurface functions for
> vectors and writing code to parse stuff that looks like
> POV-Script on the fly. If this was easy or even just a
> bit difficult, don't you think it would have been done
> already for isosurface functions?

But isosurfaces and meshes are completely different things!
Isosurfaces are fields defined for every point in space. A surface is
created wherever the field equals a certain value. Meshes are completely
different. There's no field, there's just a bunch of points in space
connected by triangles.

For isosurfaces it makes sense to change the field values by using functions
that return floats.

For meshes it makes sense to directly move the vector points by using
functions that return vectors.

> it should be possible to make a version of functions that
> handles only vectors, but it seems like an unnecessary
> inconsistency with the float version, and you likely
> wouldn't be able to use the two together.

But it's two completely different things! It wouldn't make sense to make
them consistent or to use them together.

> And if you really want to use a macro, you could always read
> the data from the mesh, do what you want with it using a
> macro, and create a new mesh with it.

Err Chris, that's what I'm already doing. This whole thread origins from my
message in povray.binaries.animations with an example of a mesh deformed by
a macro. But I was discussing with ABX if a patch could do it as easily and
flexibly (to the user) as a macro.

Seems that it can't...

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

In article <3a697e3b@news.povray.org>, "Rune" <run### [at] inamecom> 
wrote:

> "Chris Huff" wrote:
> > they would only return a component at a time.
> > (vrotate_x(px, py, pz, rx, ry, rz), vaxis_rotate_y(), etc...
> 
> Ough!

That was my solution for handling vectors in a float-based function...it 
probably wouldn't be impossible to extend functions to handle vectors as 
well.


> But isosurfaces and meshes are completely different things!
> Isosurfaces are fields defined for every point in space. A surface is
> created wherever the field equals a certain value. Meshes are completely
> different. There's no field, there's just a bunch of points in space
> connected by triangles.
> 
> For isosurfaces it makes sense to change the field values by using 
> functions that return floats.
> 
> For meshes it makes sense to directly move the vector points by using
> functions that return vectors.

You have completely missed the point...
This has *nothing* to do with isosurfaces, it's about executing 
user-written code multiple times at a later time, between parse and 
render time or even at render time. With macros, you can't do that, and 
functions are the only things that can do that (well, forget about 
shaders for the moment, since they are specialized for color processing, 
but they may also be a solution), so it makes sense to use them as an 
example and a base for the vector stuff.

Since this specific application only needs to be done at parse time, it 
should be possible to use macros (if you can figure out how, I attempted 
this as part of my particle system patch but never figured it out), but 
speed will suffer, and there are other applications of the same thing 
that would need to be done at render-time.


> But it's two completely different things! It wouldn't make sense to make
> them consistent or to use them together.

Why not? Each component of a vector is a float, allowing the user to use 
float functions in vector functions would be very powerful. And I don't 
see a reason to make another, very different version of the syntax just 
to support vector functions. They are *very* closely related, the only 
difference is that one handles scalars and the other handles vectors.


> > And if you really want to use a macro, you could always read
> > the data from the mesh, do what you want with it using a
> > macro, and create a new mesh with it.
> Err Chris, that's what I'm already doing.

Why do you think I mentioned it? ;-)


> This whole thread origins from my message in 
> povray.binaries.animations with an example of a mesh deformed by a 
> macro. But I was discussing with ABX if a patch could do it as easily 
> and flexibly (to the user) as a macro.
> Seems that it can't...

As flexibly? No...not without a lot of changes and additions. How easy 
it would be would depend on your needs, a macro based solution will be 
easy to modify to suit your needs but far slower.

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

Rune wrote in message <3a697e3b@news.povray.org>...
> Err Chris, that's what I'm already doing. This whole thread origins from my
> message in povray.binaries.animations with an example of a mesh deformed by
> a macro. But I was discussing with ABX if a patch could do it as easily and
> flexibly (to the user) as a macro.
>
> Seems that it can't...

It seems that it could...
It can't at current level of pov syntax but after some patches (my plans) it
could be done.
Did you carefully read proposition of my syntax ?
This is even better than macros becouse it can use default values of input
parameters.

ABX

Post a reply to this message

Rune wrote in message <3a68a791@news.povray.org>...
> With my macros user-defined deformations are very easy simple.
> This is a simple twist:
>
> #macro deform_mezz (P) vrotate(P,120*x*P.x) #end
>
> How would a user-defined twist look with your patch?
> (I do *not* mean the build-in twist-deform. I mean user-defined function!)


I think such thing should be possible after my whole patching

#declare Twisting=function(speed=120,A[3]=<0,1,0>,P[3])
   { VRotate( P, VScale( speed, A )) }

where VRotate and VScale are previous defined or build-in functions, i.e.:

#declare VScale=function(a=1,V[3]=<1,2,3>)
  {
    local V1[3]
    local V1[0]=a*V[0]
    local V1[1]=a*V[1]
    local V1[2]=a*V[2]
    V1
  }

and with such definitions you can write what you want

twisting along y with default speed
  box { -1 1 deform { Twisting() } }
twisting along y with new speed
  box { -1 1 deform { Twisting(130) } }
twisting along x with new speed
  box { -1 1 deform { Twisting(100,x) } }

and remember that this deform both: geometry and texturing
is this simple enough ?

but I still prefer some simple build-in deformations
becouse they have not aproximated normals
and are calculated internally/faster
(not parsed during every calculation)

ABX

Post a reply to this message

"Wlodzimierz ABX Skiba" wrote:
> Rune wrote:
> > I was discussing with ABX if a patch could do it as easily
> > and flexibly (to the user) as a macro.
> >
> > Seems that it can't...
>
> It seems that it could...

Seems like you and Chris disagree on that point...! ;)

> It can't at current level of pov syntax but after some
> patches (my plans) it could be done.
> Did you carefully read proposition of my syntax ?

I've read the post where you describe a user-defined twist-deform.

I didn't find it intuitive, and I didn't really understand it at all, but
that may just be me. I also noticed that it took up several lines of code,
where my macro took up only one short line of code.

Of course your solution was also more general, but I'd like to see what a
deform would look like that did exactly the same as the macro I made, so I
can better compare.

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

Rune wrote in message <3a6c7008@news.povray.org>...
> "Wlodzimierz ABX Skiba" wrote:
> > It can't at current level of pov syntax but after some
> > patches (my plans) it could be done.
> > Did you carefully read proposition of my syntax ?
>
> I've read the post where you describe a user-defined twist-deform.
>
> I didn't find it intuitive, and I didn't really understand it at all, but
> that may just be me.

I think it is you ;-) becouse (I think) this is nearly the same syntax
like for pure POV only no hash before local and default values for params

> I also noticed that it took up several lines of code,
> where my macro took up only one short line of code.

but my code is parsed only once and then it is used internally
as pointers to functions

> Of course your solution was also more general, but I'd like to see what a
> deform would look like that did exactly the same as the macro I made, so I
> can better compare.

animation posted to p.b.a just now
this is not user defined deformation
but my build-in twisting
with user defined twisting I'll wait for 3.5
before this I realize more built-in deformations

ABX

Post a reply to this message