"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