POV-Ray : Newsgroups : povray.unofficial.patches : Re: preview of deform patch (53 kbu) Server Time
1 Sep 2024 22:15:17 EDT (-0400)
  Re: preview of deform patch (53 kbu) (Message 11 to 20 of 20)  
<<< Previous 10 Messages Goto Initial 10 Messages
From: Wlodzimierz ABX Skiba
Subject: Re: preview of deform patch (53 kbu)
Date: 12 Dec 2000 04:57:21
Message: <3a35f681$1@news.povray.org>
Chris Huff wrote in message ...
> > > I would also use "weighted_normals" or "weight_normals" instead of
> > > "normal_weighted"
> > why ? this groups parameters for normal calculation ?
>
> You tell POV to weight the normals or to use weighted
> normals, not to use normals weighted.

Ok, thanks, I'll tell it to POV :-)


> your patch looks like it could be very fun just to play
> around with. :-)

I hope I do it not only for fun :-)
only with twist just imagine "airscrew", "drill"

> > 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 thought of your proposition and looked at the source of warps whole night and
finnaly I think there is big misunderstand, You Chris and Christoph Hormann
think that I deform point only ones but every deformation which I need must be
bi-directional/reversable/invertable
well defined deformation f(x,y,z) must have brather or sister as undeformation
g(x,y,z) where:
A=f(B) and B=g(A)
perhaps I don't understand warps source but I think this is hardly (if possible)
to inverse uniformly all warps
as I see twisting is bad example becouse is well defined for whole space and you
omit bi-directioning of calculation
I try explain again:
I start with patch becouse of bad normals in isosurface
I discover that normals of deformed object can be aproximated insted of
calculating

Here is symbolic notation of my method:

take depth1 and depth2 for container or bounding box
take function deform and undeform (opposite to deform)
for i=depth1 to depth2 step accuracy
  point1=evaluate_ray(trace_ray,i)
  point2=evaluate_ray(trace_ray,i+accuracy)
  pointA=undeform(point1)
  pointB=undeform(point2)
  deformed_ray=create_ray_beetwen(pointA,pointB)
  pointC=find_every_intersection(deformed_ray,base_object)
  for every pointC beetween pointA and pointB
    normal=normal(base_object,pointC)
    array[normal_accuracy_int] = neighbouring points
                                 around pointC
                                 distributed evenly on surface
                                 perpendicular to normal
    point3=deform(pointC)
    deformed_array=deform(each of neighbouring points)
    calculate (weighted) normal from deformed neighbours
    put on stack of intersections point3 and normal
  end for
end for

is inverted function of turbulance and/or warps builded in povray

> If you want only part of the object to be deformed,
> you should probably use
> a union of a deform object with ordinary objects.

with wasting memory if this could be omited ?
I'll consider this behavior

> BTW, multiple deformations would also be useful...

yes, I though of it

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

hmm, but parameters of accuracy should be defined for every deformation becouse
every type of deformations could have "density" of changing, "denisty" of
turbulencing
than perhaps

deform {
  box {<-1,-1,-1>, < 1, 1, 1> texture {Texture}}
  deformation {
    turbulence 0.2
    accuracy 0.1
    weighted_normals on
  }
  deformation {
    twist y, 8
    accuracy 0.5
  }
  deformation {
    black_hole ...
    accuracy 0.01
    normal_accuracy 10, 0.2
    weighted_normals on
  }
}

> Christopher James Huff

ABX with doughter at zuza.org


Post a reply to this message

From: Wlodzimierz ABX Skiba
Subject: Re: preview of deform patch (53 kbu)
Date: 12 Dec 2000 06:38:59
Message: <3a360e53$1@news.povray.org>

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


deform begining and end of normal and calculate returned direction ?
this is wrong method
sure, at first I thought of it but this not works with deformations
why ?
look on top surface of deformed box from begining of this thread
this is flat before and after deformation
and normal is parallel to axis of deformation
but imagine normal before deformation
normal's end_point twist just like other points and after deformation
normal is not parallel to axis of deformation
and smaller normal not help, direction is direction

explain more ?

ABX


Post a reply to this message

From: Jérôme M  Berger
Subject: Re: preview of deform patch (53 kbu)
Date: 12 Dec 2000 08:37:35
Message: <3A362A1E.AE7BA4CE@enst.fr>
Wlodzimierz ABX Skiba wrote:
> 
> deform begining and end of normal and calculate returned direction ?
> this is wrong method
> sure, at first I thought of it but this not works with deformations
> why ?
> look on top surface of deformed box from begining of this thread
> this is flat before and after deformation
> and normal is parallel to axis of deformation
> but imagine normal before deformation
> normal's end_point twist just like other points and after deformation
> normal is not parallel to axis of deformation
> and smaller normal not help, direction is direction
> 
> explain more ?
> 
	You're right, it probably cannot be done in a completely generic way
and would need to be done for each deformation. Mmm... maybe not as easy
as I first thought, let's see:

Let <nx, ny, nz> be the normal of the object before the deformation;
Let f be the transformation and fx, fy, fz its components;
Then the normal of the transformed point is:
<nx * dfx/dx + ny * dfy/dx + nz * dfz/dx,
 nx * dfx/dy + ny * dfy/dy + nz * dfz/dy,
 nx * dfx/dz + ny * dfy/dz + nz * dfz/dz>;

	Therefore, all that's needed is to be able to compute the various
df*/d*. In the case of the twist transform along the y axis:
fx = cos(k*y)*x - sin(k*y)*z
fy = y
fz = sin(k*y)*x + cos(k*y)*z
	And the transformed normal becomes:
<nx*cos(k*y) + nz*sin(k*y),
 nx*(-k*sin(k*y)*x-k*cos(k*y)*z) + ny + nz*(k*cos(k*y)*x-k*sin(k*y)*z),
 nx*(-sin(k*y)) + nz*cos(k*y)>

	Notice that for the flat faces, nx=0, ny=1 (or -1), nz=0 and the
transformed normal is correct.

	Hope this helps,


-- 

* 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

From: Wlodzimierz ABX Skiba
Subject: Re: preview of deform patch (53 kbu)
Date: 12 Dec 2000 09:00:57
Message: <3a362f99@news.povray.org>

> Hope this helps,


great, thank you for support

ABX


Post a reply to this message

From: Wlodzimierz ABX Skiba
Subject: Re: preview of deform patch (53 kbu)
Date: 12 Dec 2000 09:50:49
Message: <3a363b49@news.povray.org>
Christoph Hormann wrote in message <3A3537D9.67ED545C@gmx.de>...
> Probably Chris Huff's idea of using warps is even more universal.

but as I answer to Chris main part of my concept is using "bi-directional"
deformation and if warps support it this could be possible
but I'm affraid it is imposible

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

no, they aren't simple, only twister is simply
is this simple to calculate x from (A*x-B)(cosx-sinx)=C ?

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

this is misunderstanding
you think that I want function for whole space but I don't want
I want container for base space and deform function
with this I can describe space of deformed object and bound it
during trace I can recognize steps inside deformed container and undeform

are you curious about placing along spline ?
just like 2d drawing software puts text on curve
I'm not sure if it is possible but perhaps this is beginning:

1. get spline (begin at t=0 and end at t=1)
2. generate function for normal N=f(t) where t is beetween 0 and 1
3. generate function for point P=f(t) where t is beetween 0 and 1
4. generate equation for plane at point P(t) and with normal N(t)
5. resolve equation to find (perhaps derivative of sth) plane
    with minimal distance beetween my point and P(t)
6. calculate t for achived plane

looks this possible ?

ABX


Post a reply to this message

From: Chris Huff
Subject: Re: preview of deform patch (53 kbu)
Date: 12 Dec 2000 10:13:10
Message: <chrishuff-7B78FA.10140412122000@news.povray.org>
In article <3a35f681$1@news.povray.org>, "Wlodzimierz ABX Skiba" 
<abx### [at] abxartpl> wrote:

> I thought of your proposition and looked at the source of warps whole 
> night and finnaly I think there is big misunderstand, You Chris and 
> Christoph Hormann think that I deform point only ones but every 
> deformation which I need must be bi-directional/reversable/invertable 
> well defined deformation f(x,y,z) must have brather or sister as 
> undeformation g(x,y,z) where:
> A=f(B) and B=g(A)

Ok, I thought your patch used a method similar to the isosurface to find 
the intersections, but generated the functions automatically from a 
specified object and simply displaced the function. I still don't 
entirely understand what you are doing...but it looks more like 
simulating curved rays with short segments.


> is inverted function of turbulance and/or warps builded in povray

Unfortunately, no, there aren't any functions to invert warps in 
POV-Ray...and many warps aren't reversable.
If it only works with invertable warps, it is a lot more limited than I 
thought...maybe another method could be used in addition to what you 
wrote. Type 0 deform objects would be what you have now and would use 
special, reversable deformations, type 1 deform objects would convert 
the object to an isosurface function and apply a warp. Type 1 would be 
more versatile, but also potentially slower/less accurate.


> > If you want only part of the object to be deformed,
> > you should probably use
> > a union of a deform object with ordinary objects.
> with wasting memory if this could be omited ?

Hmm, I wasn't considering memory use...


> hmm, but parameters of accuracy should be defined for every 
> deformation becouse every type of deformations could have "density" 
> of changing, "denisty" of turbulencing than perhaps

Well, I was thinking of it in terms of warps, all the deformations would 
be put in a single chain of warps rather than nested deformations, so 
only a single accuracy would be needed, and it would only have to handle 
the finest detail of all the deformations put together.

-- 
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: 12 Dec 2000 10:26:13
Message: <3a364395@news.povray.org>
Chris Huff wrote in message ...
> but it looks more like
> simulating curved rays with short segments.

as I wrote at begining :-)

> > is inverted function of turbulance and/or warps builded in povray
>
> Unfortunately, no, there aren't any functions to invert warps in
> POV-Ray...and many warps aren't reversable.

yes, unfortunatly
but you wake up dreams on me :-)

> If it only works with invertable warps, it is a lot more limited than I
> thought...maybe another method could be used in addition to what you
> wrote. Type 0 deform objects would be what you have now and would use
> special, reversable deformations, type 1 deform objects would convert
> the object to an isosurface function and apply a warp. Type 1 would be
> more versatile, but also potentially slower/less accurate.

I'll consider this in next version :-)

thanks for support

ABX


Post a reply to this message

From: Christoph Hormann
Subject: Re: preview of deform patch (53 kbu)
Date: 12 Dec 2000 10:32:26
Message: <3A364505.1A11CAEB@gmx.de>
Wlodzimierz ABX Skiba wrote:
> 
> but as I answer to Chris main part of my concept is using "bi-directional"
> deformation and if warps support it this could be possible
> but I'm affraid it is imposible
> 

I recognized that, NTL it seems to be possible with isosurfaces. 

> 
> no, they aren't simple, only twister is simply
> is this simple to calculate x from (A*x-B)(cosx-sinx)=C ?
> 

That wasn't my point, i just meant that it would be better to enter the
function in a common way like an isosurface function than to hardcode it
and introduce a new keyword for each new function.  If it's not possible
to use warps, you maybe should consider using the isosurface function
parser as i first suggested.  

> 
> this is misunderstanding
> you think that I want function for whole space but I don't want
> I want container for base space and deform function
> with this I can describe space of deformed object and bound it
> during trace I can recognize steps inside deformed container and undeform
> 
> are you curious about placing along spline ?
> just like 2d drawing software puts text on curve
> I'm not sure if it is possible but perhaps this is beginning:
> [...]
> looks this possible ?
> 

Well, it's a bit too much for a tuesday afternoon :-) but anyway it seems
to be a function for whole space although it's constant in one or two
directions.  

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: 12 Dec 2000 10:52:35
Message: <3a3649c3@news.povray.org>
Christoph Hormann wrote in message <3A364505.1A11CAEB@gmx.de>...
> > no, they aren't simple, only twister is simply
> > is this simple to calculate x from (A*x-B)(cosx-sinx)=C ?
>
> That wasn't my point, i just meant that it would be better to enter the
> function in a common way like an isosurface function than to hardcode it
> and introduce a new keyword for each new function.  If it's not possible
> to use warps, you maybe should consider using the isosurface function
> parser as i first suggested.

my aim was give user-friendly interface deformations available
as isosurfeces to non math-users
if I back to function declaration than I return to begining
sometimes simple things are hardly to achive - equation above
simplest form achived for twist over spindle
(http://www.abx.art.pl/pov/nonlinear/zakrecony.jpg)
you don't like names for types of deformation ?
what about pigments - first was many types (with fast engine)
and than suppport for functions as pigment
perhaps I use the same way of evolution :-)

> Well, it's a bit too much for a tuesday afternoon :-) but anyway it seems
> to be a function for whole space although it's constant in one or two
> directions.

what about spline looped ?

ABX


Post a reply to this message

From: Jérôme M  Berger
Subject: Re: preview of deform patch (53 kbu)
Date: 13 Dec 2000 04:56:31
Message: <3A3747CF.31FE9B51@enst.fr>

> 
> Let <nx, ny, nz> be the normal of the object before the deformation;
> Let f be the transformation and fx, fy, fz its components;
	Something's not clear here... I should have said that f is the
transform that's applied to the *ray*, it's the inverse of the one
applied to the object.


-- 

* 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

<<< Previous 10 Messages Goto Initial 10 Messages

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