POV-Ray : Newsgroups : povray.unofficial.patches : Re: preview of deform patch (53 kbu) Server Time
1 Sep 2024 16:15:12 EDT (-0400)
  Re: preview of deform patch (53 kbu) (Message 1 to 10 of 20)  
Goto Latest 10 Messages Next 10 Messages >>>
From: Wlodzimierz ABX Skiba
Subject: Re: preview of deform patch (53 kbu)
Date: 11 Dec 2000 11:49:58
Message: <3a3505b6@news.povray.org>
Christoph Hormann wrote in message <3A34E9C5.48E56C4A@gmx.de>...
> I must admit that i don't understand much of the code.  I thought it would
> be something like a displace warp for objects but it does look different.
> Could you explain it a bit more detailed?


I choose keyword "deform" becouse this is short

I know that this is some kind of transformation and perhaps should be placed
beetween object's modifiers but I choose different statment becouse of different
usage it has. This example is simple deformation but I'm thinkin on some
complicated which in the truth create different objects - my defformations are
objects. It means they can be assigned to variables, puted as base of another
deformation, as part of csg, can be scaled, rotated etc.

I try describe but I'm affraid of vocabulary

deform {
  TYPE
  contained_by{ CONTAINER }
  [ DEFORM_PARAMETERS ]
  [ DEFORM_TYPE_PARAMETERS ]
  [ object modifiers ... ]
}

description:

TYPE: for develop universal deformation module curently only support "turn" but
I want implement more type of deformations (look below)

CONTAINER: syntax is inspired by isosurface and this show space of base object -
this allow deform only part of object - i.e. you can twist middle part of
woodden column and leave rest of it

DEFORM_PARAMETERS:
  [ ACCURACY float ]
  [ NORMAL_ACCURACY int [ , float ] ]
  [ NORMAL_WEIGHTED ]

this is group of parameters for all types of deformations

ACCURACY - this is connected with method of recive deformed shape - during trace
ray is divided by points with distance described in accuracy parameter, every
point is undeformed to original space of base object, this makes some kind of
curved ray, than look for intersection with base and return coordinate to
deformed space - default value is 0.01

NORMAL_ACCURACY - this is followed by two parameters and is connected with
method of deformation normals - after finding intersection with base object this
find neighbouring points distributed evenly around of intersection point on
surface perpendicular to normal. first integer value determine number of this
points (must be greater than 2); second float determine distance beetwen this
points and intersection point (default values are 4 and 0.001); this points are
deformed to space of scene and appear as some surface aproximate as set of
triangles; than average normal of this triangles for output normals

NORMAL_WEIGHTED - determine method of averaging normal - more in thread "should
be normals weighted" at p.a-u

DEFORM_TYPE_PARAMETERS - this is group of parameters proper for type of
deformation; they control deformation i.e. for deformaion "turn" there is
parameter "full_after" followed by float - this tells that going along axis of
container after every full_after distance space should be twisted 360 degrees

I hope after explanation this is more readable, try understand again:

deform {
  turn box{-1 1 texture{Texture}}
  contained_by { cylinder{ <0,-1,0> <0,1,0> 3 }}
  accuracy 0.05
  normal_accuracy 3, 0.01
  normal_weighted
  full_after 8
}

what about next deformation types
second will be deformation showed on right side at
http://www.abx.art.pl/pov/nonlinear/test.jpg - this is still deformation "turn"
but with specified parameter "spindle" followed by float greater than 0
another deformation types:
a) put object in cylinder and place along bezier - for curved texts
b) put object in cylinder and create torpatch, tangle
c) put object in box and place beetwen two bezier_patches as top and bottom
surface of this box
d) put object in cylinder or box and stretch out this like rubber (different in
center and at and)

in future I think that this could speed up if deform vertices of mesh during
parse and play like normal mesh

I not have finished sources but if there is any person interested with this I
can public current state of deform.c

ABX


Post a reply to this message

From: Disnel
Subject: Re: preview of deform patch (53 kbu)
Date: 11 Dec 2000 12:53:58
Message: <3A352441.DBE0DD88@hlavacek-partner.cz>
Great, I thinked about something similar some time ago.
But why don't use curved rays for tracing primarilly a only for those
objects,
which don't suppory intersection with spline (for example) use spline
interpolation by straight rays? Those objects will be all of POV objects
at the beginning, but in the future some of them can support
intersection with curved rays.

Just an idea, I don't know, if exists mathematical solution of
intersection between spline and sphere, for example.

Disnel


Post a reply to this message

From: Christoph Hormann
Subject: Re: preview of deform patch (53 kbu)
Date: 11 Dec 2000 13:31:40
Message: <3A351D86.BF6A26FD@gmx.de>
That was much clearer, thanks.  

I think it would be useful to allow to use functions or pigments for
deformation.  Don't know if that's easy to implement, but better than a
whole lot of independent types with new keywords IMO.  

It would be interesting to have some info about speed although it's
probably not that slow with a simple 'turn'.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/


Post a reply to this message

From: Wlodzimierz ABX Skiba
Subject: Re: preview of deform patch (53 kbu)
Date: 11 Dec 2000 14:00:55
Message: <3a352467$1@news.povray.org>
Christoph Hormann wrote in message <3A351D86.BF6A26FD@gmx.de>...
> I think it would be useful to allow to use functions or pigments for
> deformation.

I didn't plan such usage but maybe ...

> Don't know if that's easy to implement, but better than a
> whole lot of independent types with new keywords IMO.

I think deform, accuracy and contained_by is easy to understand
normal_accuracy and normal_weighted are optional and in the truth
I don't think that this has large meaning for output
to describe spline I want use syntax of spline
to describe patch I want use syntax of patch
I try to not annoying with new keywords
current are wrong ? please tell me

> It would be interesting to have some info about speed although it's
> probably not that slow with a simple 'turn'.

I tell you when finish code
Good comparision will be with speed of isosurface with the same equation of
deformed coordinates

ABX


Post a reply to this message

From: Chris Huff
Subject: Re: preview of deform patch (53 kbu)
Date: 11 Dec 2000 14:20:09
Message: <chrishuff-00B1BF.14210211122000@news.povray.org>
In article <3a3505b6@news.povray.org>, "Wlodzimierz ABX Skiba" 
<abx### [at] abxartpl> wrote:

> deform {
>   TYPE
>   contained_by{ CONTAINER }
>   [ DEFORM_PARAMETERS ]
>   [ DEFORM_TYPE_PARAMETERS ]
>   [ object modifiers ... ]
> }

I think a much more intuitive syntax would be:
deform {
    DEFORMED_OBJECT
    deformation {WARP}

    DEFORM_PARAMETERS
    OBJECT_MODIFIERS
}

I would also use "weighted_normals" or "weight_normals" instead of 
"normal_weighted", "twist" instead of "turn", and a few other little 
changes. If the object has a texture, it is deformed along with the 
object. If a texture is given in the deform{} block, it isn't deformed.

This would be used like this:
deform {
    sphere {...}
    deformation {turbulence 0.5}

    accuracy 0.01
    normal_accuracy 4, 0.001
    weighted_normals on|true|yes|off|false|no
        // the on/off/etc... would be optional, using
        // only the keyword would turn it on.
}

Also, I don't know how your deformations work, but it would make sense 
to use the warps to do the job, since you are really just warping an 
object instead of a pattern. If you do this, you can avoid a lot of 
duplicated work by implementing a single warp.

The equivalent code for what you wrote with my suggested syntax would be:
deform {
    box {-1, 1 texture {Texture}}
    type {twist y, 8}// twist AXIS, TWISTS_PER_UNIT_DISTANCE
    accuracy 0.05
    normal_accuracy 3, 0.01
    weighted_normals
}

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

From: Wlodzimierz ABX Skiba
Subject: Re: preview of deform patch (53 kbu)
Date: 11 Dec 2000 14:39:10
Message: <3a352d5e$1@news.povray.org>
Chris Huff wrote in message ...
> I think a much more intuitive syntax would be:
> deform {
>    DEFORMED_OBJECT
>    deformation {WARP}
>    DEFORM_PARAMETERS
>    OBJECT_MODIFIERS
> }

yes, good suggestion, thanks

> I would also use "weighted_normals" or "weight_normals" instead of
> "normal_weighted"

why ? this groups parameters for normal calculation ?

> "twist" instead of "turn"

yes, I thought of it, this is hardly to choose english equvalent by
non-natural-english-speak-man
:-)

> and a few other little changes

write, please

> If the object has a texture, it is deformed along with the
> object. If a texture is given in the deform{} block, it isn't deformed.

yes, this is part of my conception
even further - layered textures mixed from deformation and base object!

> deform {
>  sphere {...}
>  deformation {turbulence 0.5}
>  accuracy 0.01
>  normal_accuracy 4, 0.001
>  weighted_normals on|true|yes|off|false|no
> }

what about deformations where they are good described only in part of space ?
turbulence and twist is calculable in evry point but what about placing along
spline ?

> Also, I don't know how your deformations work, but it would make sense
> to use the warps to do the job, since you are really just warping an
> object instead of a pattern. If you do this, you can avoid a lot of
> duplicated work by implementing a single warp.

I consider it

> The equivalent code for what you wrote with my suggested syntax would be:
> deform {
>    box {-1, 1 texture {Texture}}
>    type {twist y, 8}// twist AXIS, TWISTS_PER_UNIT_DISTANCE
>    accuracy 0.05
>    normal_accuracy 3, 0.01
>    weighted_normals
> }

thanks, evening, going to daughter and wife I'll consider

ABX


Post a reply to this message

From: Christoph Hormann
Subject: Re: preview of deform patch (53 kbu)
Date: 11 Dec 2000 15:24:02
Message: <3A3537D9.67ED545C@gmx.de>
Wlodzimierz ABX Skiba wrote:
> 
> > I think it would be useful to allow to use functions or pigments for
> > deformation.
> 
> I didn't plan such usage but maybe ...
> 

Probably Chris Huff's idea of using warps is even more universal.  

> I think deform, accuracy and contained_by is easy to understand
> normal_accuracy and normal_weighted are optional and in the truth
> I don't think that this has large meaning for output
> to describe spline I want use syntax of spline
> to describe patch I want use syntax of patch
> I try to not annoying with new keywords
> current are wrong ? please tell me
> 

I didn't mean the general keywords but the ones specific for the different
types.  Each new type will introduce a new keyword although most of them
are probably only simple mathematical functions.  

BTW, i'm curious how you want to deform something according to a spline,
since it only supplies some local geometric information (i.e. the shape of
a line) while it would need some deformation function for the whole space. 

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/


Post a reply to this message

From: Chris Huff
Subject: Re: preview of deform patch (53 kbu)
Date: 11 Dec 2000 15:53:04
Message: <chrishuff-348FE5.15535711122000@news.povray.org>
In article <3a352d5e$1@news.povray.org>, "Wlodzimierz ABX Skiba" 
<abx### [at] abxartpl> wrote:

> > I would also use "weighted_normals" or "weight_normals" instead of
> > "normal_weighted"
> why ? this groups parameters for normal calculation ?

Because in English, describing words or actions usually go before the 
thing they describe or act on. You say "weighted normals", not "normals 
weighted". You tell POV to weight the normals or to use weighted 
normals, not to use normals weighted.


> > and a few other little changes
> write, please

Allowing a boolean after "weighted_normals"(or "weight_normals", or...) 
so you could specify on or off...um, that's all I could think of right 
now. I think I mentioned all the ones I thought of.


> > If the object has a texture, it is deformed along with the
> > object. If a texture is given in the deform{} block, it isn't deformed.
> yes, this is part of my conception
> even further - layered textures mixed from deformation and base object!

Yes, I was thinking of that...some interesting possibilities. And if you 
use warps to specify the deformations, you could control the textures 
yourself...your patch looks like it could be very fun just to play 
around with. :-)


> what about deformations where they are good described only in part of 
> space ?
> turbulence and twist is calculable in evry point but what about 
> placing along spline ?

I'm not sure what exactly you mean...I would assume that parts of the 
surface where the deformation is undefined simply aren't deformed. If 
you want only part of the object to be deformed, you should probably use 
a union of a deform object with ordinary objects.
BTW, multiple deformations would also be useful...just allow them to be 
applied one after the other, which should be very easy to do if you use 
warps. That way you could make a twisted, turbulated box being sucked 
into a black hole. :-)
deform {
    box {<-1,-1,-1>, < 1, 1, 1> texture {Texture}}
    deformation {turbulence 0.2}
    deformation {twist y, 8}
    deformation {black_hole ...}
    accuracy 0.05
    normal_accuracy 3, 0.01
    weighted_normals on
}


> > The equivalent code for what you wrote with my suggested syntax would 
> > be:
> > deform {
> >    box {-1, 1 texture {Texture}}
> >    type {twist y, 8}// twist AXIS, TWISTS_PER_UNIT_DISTANCE

Oops, that should have been "deformation {twist y, 8}".

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

From: Chris Huff
Subject: Re: preview of deform patch (53 kbu)
Date: 11 Dec 2000 15:55:36
Message: <chrishuff-5BE6B3.15563011122000@news.povray.org>
In article <3A3537D9.67ED545C@gmx.de>, Christoph Hormann 
<chr### [at] gmxde> wrote:

> Probably Chris Huff's idea of using warps is even more universal.  

Especially when combined with the "displace" warp and the function 
pigment(which is currently vaporware, I haven't gotten it to work right).

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

From: Jérôme M  Berger
Subject: Re: preview of deform patch (53 kbu)
Date: 12 Dec 2000 04:36:32
Message: <3A35F19F.94DFD97@enst.fr>
Wlodzimierz ABX Skiba wrote:
> 
> NORMAL_ACCURACY - this is followed by two parameters and is connected with
> method of deformation normals - after finding intersection with base object this
> find neighbouring points distributed evenly around of intersection point on
> surface perpendicular to normal. first integer value determine number of this
> points (must be greater than 2); second float determine distance beetwen this
> points and intersection point (default values are 4 and 0.001); this points are
> deformed to space of scene and appear as some surface aproximate as set of
> triangles; than average normal of this triangles for output normals
> 
> NORMAL_WEIGHTED - determine method of averaging normal - more in thread "should
> be normals weighted" at p.a-u
> 
	Wouldn't it be simpler (and faster) to take the normal of the
undeformed object and apply the transformation to it?


-- 

* Abandon the search for truth, * mailto:ber### [at] inamecom
* Settle for a good fantasy.    * http://www.enst.fr/~jberger
*********************************


Post a reply to this message

Goto Latest 10 Messages Next 10 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.