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