POV-Ray : Newsgroups : povray.programming : Clarifying some issues and a General RFC Server Time
29 Jul 2024 10:21:05 EDT (-0400)
  Clarifying some issues and a General RFC (Message 11 to 20 of 23)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 3 Messages >>>
From: Tim Burton
Subject: Re: Clarifying some issues and a General RFC
Date: 10 Jul 1998 14:33:31
Message: <35A650E8.ED09DDF6@Thrt.Com>
If you don't like the v-card, dont read the message, who cares what you like?

tim jordan wrote:

> Justin Rogers wrote:
> >
> > Ron Parker wrote in message <35a39212.0@news.povray.org>...
> > >Please fix your newsreader to not use quoted-printable for posting.  Then
> > >turn off that stupid HTML crap and the vCard crap.  This is Usenet, not the
> > >web.  Thanks.
>
> > Sorry...  I like my VCard and my quoted printable...  It stays.
>
> Then you should expect flames.
>
> I *don't* like quoted-printable etc. either.
>
> tim


Post a reply to this message

From: Fran & Melissa
Subject: Re: Clarifying some issues and a General RFC
Date: 12 Jul 1998 14:55:36
Message: <35a8f898.0@news.povray.org>
Ron Parker wrote in message <35a39212.0@news.povray.org>...

<A lot clipped>

>Great, that's what we need.  Fragment the language to hell and back so
>nobody stands a chance of understanding every flavor of it.  It's not the
>language that most people want improved, it's the available primitives,
>textures, and transformations.  The one thing I hear asked for over and
over
>is nonlinear transformations, but the reason that hasn't been done is
nobody
>knows how to do it.
>

The last bit about the non-linear transformations....

Don't have any idea how to do this but something like

matrix {
    <formula,formula,formula>

etc

Sorta like a translation matrix.

So to get the new point, take old point and move( change) by formula amount.

Just an idea. anyway


Fran.


Post a reply to this message

From: Jon S  Berndt
Subject: Re: Clarifying some issues and a General RFC
Date: 12 Jul 1998 18:37:24
Message: <35A92DB0.FC4B4604@hal-pc.org>
> The last bit about the non-linear transformations....
> [...clipped...]
> So to get the new point, take old point and move( change) by formula amount.

I've been thinking about this one, too (non-linear transformations).
It's a difficult problem. It would be easy (relatively) to take a shape
and skew it based on some function. However, I think there would be a
lot of work to also take into account surface normal, textures and
everything else which dictates what an object would look like at a
skewed point. I don't think it is impossible at all, just a very tricky
and uncomfortable problem. I sure ain't the guy to take on that one!

jb


Post a reply to this message

From: Thorsten Froehlich
Subject: Re: Clarifying some issues and a General RFC
Date: 12 Jul 1998 18:41:42
Message: <35a92d96.0@news.povray.org>
Fran wrote:
>The last bit about the non-linear transformations....
>
>Don't have any idea how to do this but something like
>
>matrix {
>    <formula,formula,formula>
>
>etc
>
>Sorta like a translation matrix.

I am not sure, but a matrix may not work. I would try to deform the *RAY*, not the
object. This is the suggested method in "An introduction to ray tracing", page 115 -
"Deformed surfaces".


Thorsten


Post a reply to this message

From: Ron Parker
Subject: Re: Clarifying some issues and a General RFC
Date: 13 Jul 1998 12:21:44
Message: <35aa2608.0@news.povray.org>
On Sun, 12 Jul 1998 23:41:05 +0200, Thorsten Froehlich 
      <Tho### [at] compuservecom> wrote:
>Fran wrote:
>>The last bit about the non-linear transformations....
>>
>>Don't have any idea how to do this but something like
>>
>>matrix {
>>    <formula,formula,formula>
>>
>>etc
>>
>>Sorta like a translation matrix.
>
>I am not sure, but a matrix may not work. I would try to deform the *RAY*, 
>not the object. This is the suggested method in "An introduction to ray 
>tracing", page 115 - "Deformed surfaces".

Right, matrices won't work.  By definition, anything that can be represented
as a matrix is linear.  But Fran wasn't talking about what mathematicians 
traditionally call a matrix; he was talking about a notational system that
superficially resembles the one POV now uses for linear transformations.

POV now works by deforming the ray, and this works fine for invertible linear 
transformations, because a ray is still a ray after transformation.  With a 
nonlinear transformation, though, assuming you can even figure out how to 
invert it, the ray would end up being a curve of some type.  A number of 
objects already require the raytracer to solve a nasty polynomial to find the 
intersection with a straight line.  In general, the problem of intersection 
with an arbitrary curve might be so difficult as to be practically 
impossible.  Still, it might be possible to work with perspective 
transformations, because they also map lines to lines. They aren't always
invertible, though, so you'd have a problem with a ray that intersected such 
a surface at a singularity.  That's why zero is an illegal value in a scale.

The problem of general nonlinear transformations would likely only be solved 
by converting the object to a mesh and then using the forward transform on 
its constituent elements, but unless the inverse transform is easily 
calculable, I don't see how you could transform the texture as well.  

This brings us back to the problem of making a mesh from arbitrary objects,
which would be really, really nice but perhaps not terribly easy.  If we had
it, though, we could do a lot of other neato things we can't now, like real 
radiosity, conversions from POV to other formats like VRML, OpenGL preview,
and displacement mapping.  The object orientation of POV means that it could
have each object be responsible for its own mesh generation, and at least in
the short term it could just punt to an error message for objects that don't
know how to do so, just as POV does now for the insideness test on meshes.
Objects that might require this treatment are the polynomial surfaces.

If we wanted something useful, though, the bare minimum would be for CSG
operations to be able to do mesh generation by working with the meshes 
generated by sub-objects.  To me, this seems like the difficult part of the
job.


Post a reply to this message

From: Thorsten Froehlich
Subject: Re: Clarifying some issues and a General RFC
Date: 13 Jul 1998 16:49:36
Message: <35aa64d0.0@news.povray.org>
Ron Parker wrote:
>Right, matrices won't work.  By definition, anything that can be represented
>as a matrix is linear.  But Fran wasn't talking about what mathematicians 
>traditionally call a matrix; he was talking about a notational system that
>superficially resembles the one POV now uses for linear transformations.

I am not sure I fully understand what you are refering to English isn't my native
language), can you expail this a little bit more, please?

Ron Parker wrote:
>POV now works by deforming the ray, and this works fine for invertible linear 
>transformations, because a ray is still a ray after transformation.  With a 
>nonlinear transformation, though, assuming you can even figure out how to 
>invert it, the ray would end up being a curve of some type.  A number of 
>objects already require the raytracer to solve a nasty polynomial to find the 
>intersection with a straight line.  In general, the problem of intersection 
>with an arbitrary curve might be so difficult as to be practically 
>impossible.

To keep it simple (and possibly not covering all cases) a quadartic function (for each
component of the vector) would be enough to make an egg out of a sphere.

Ron Parker wrote:
>The problem of general nonlinear transformations would likely only be solved 
>by converting the object to a mesh and then using the forward transform on 
>its constituent elements, but unless the inverse transform is easily 
>calculable, I don't see how you could transform the texture as well.  

Splines could be used so solve this problem as well, couldn't they?

Ron Parker wrote:
>This brings us back to the problem of making a mesh from arbitrary objects,
>which would be really, really nice but perhaps not terribly easy.  If we had
>it, though, we could do a lot of other neato things we can't now, like real 
>radiosity, conversions from POV to other formats like VRML, OpenGL preview,
>and displacement mapping.  The object orientation of POV means that it could
>have each object be responsible for its own mesh generation, and at least in
>the short term it could just punt to an error message for objects that don't
>know how to do so, just as POV does now for the insideness test on meshes.
>Objects that might require this treatment are the polynomial surfaces.

Yes, to generate meshes out of objects is an important feature missing. But I think it
is no (too big) problem to determine the surface of any polynomial defined object,
however I have never tried so I cannot claim this to be right.
But having a few million triangles and all their energies, etc. to calculate the
radiosity with a itterative approach (not to talk about a full matrix inversion) will
still not be easier or faster. And inorder to use raytracing with it you would have to
re-apply the light (energy) data to the objects as something like a texture. Or you
would only be able to render with radiosity and meshes. Not to talk about the
reflection problem (e.g. mirrors) which is still (???) there with radiosity based on
meshes.

Ron Parker wrote:
>If we wanted something useful, though, the bare minimum would be for CSG
>operations to be able to do mesh generation by working with the meshes 
>generated by sub-objects.  To me, this seems like the difficult part of the
>job.

Yes, it is! Especially if you deal with more than one object it is hard to find out if
a specific part of an object (or to be more precise, the part of the objects mesh) is
to be displayed (and therefore a part of the surface), or not. I have tried to write a
program to do this (as a demo only - no real application!), but I ran exactly into
this problem. I have not done much more research to solve this because gettting the
Macintosh POV-Ray 3.1 beta ready was more urgent :-(  And other of the POV-Ray team
warned me that (my approach, like others) might not work. But I am still confident I
can get it to work if I spend more time with it!   Analysis is not my hobby math
subject, geometry is (with the as few polynoms as possible :-)


Thorsten


Post a reply to this message

From: Ron Parker
Subject: Re: Clarifying some issues and a General RFC
Date: 13 Jul 1998 18:17:12
Message: <35aa7958.0@news.povray.org>
On Mon, 13 Jul 1998 21:48:45 +0200, Thorsten Froehlich 
<Tho### [at] csicom> wrote:
>Ron Parker wrote:
>>Right, matrices won't work.  By definition, anything that can be represented
>>as a matrix is linear.  But Fran wasn't talking about what mathematicians 
>>traditionally call a matrix; he was talking about a notational system that
>>superficially resembles the one POV now uses for linear transformations.
>
>I am not sure I fully understand what you are refering to English isn't my native
language), can you expail this a little bit more, please?

I'm not sure how to explain this.  I just meant that he wasn't talking about
what you and I might call a matrix.  He was only talking about a syntactic
way to express an array of formulas.

>To keep it simple (and possibly not covering all cases) a quadartic function (for
each component of the vector) would be enough to make an egg out of a sphere.

A perspective transformation is sufficient to transform a sphere into an
egg.  Unfortunately, a perspective transformation can also turn a sphere into 
a weird barbell-shaped thing with a singularity in the middle.  In general, 
it might not be possible to transform the ray into the space of the object 
when using perspective transformations because working with rays passing 
through the singularity would require dividing by zero.  Also the concept of 
"inside" is seriously messed up by the presence of singularities.

>Ron Parker wrote:
>>The problem of general nonlinear transformations would likely only be solved 
>>by converting the object to a mesh and then using the forward transform on 
>>its constituent elements, but unless the inverse transform is easily 
>>calculable, I don't see how you could transform the texture as well.  
>
>Splines could be used so solve this problem as well, couldn't they?

Of course.  Anything that can still be tested for intersections after 
undergoing an arbitrary transformation is fine.  The idea is to eliminate
the need for an inverse transformation.

>Yes, to generate meshes out of objects is an important feature missing. But I think
it is no (too big) problem to determine the surface of any polynomial defined object,
however I have never tried so I cannot claim this to be right.

I, too, have no experience with trying to make meshes from higher-order
polynomial surfaces.  They may indeed be easier than I think.  But they can
also be infinite, and depending on what you plan to use the triangles for,
that can be an insurmountable obstacle.

>But having a few million triangles and all their energies, etc. to calculate the
radiosity with a itterative approach (not to talk about a full matrix inversion) will
still not be easier or faster. And inorder to use raytracing with it you would have to
re-apply the light (energy) data to the objects as something like a texture. Or you
would only be able to render with radiosity and meshes. Not to talk about the
reflection problem (e.g. mirrors) which is still (???) there with radiosity based on
meshes.

True, we might not want to try to implement radiosity this way in POV, but 
it might be nice to use some of the great tools available for POV and the 
expressiveness of the POV language to generate data that could be fed into 
other renderers, of which Radiance, OpenGL, and VRML are but obvious 
examples.  

Clearly, there'd have to be extra parameters to control the mesh-generation 
process, so you don't get a few million triangles unless you want or need 
them.


Post a reply to this message

From: Ben Paschke
Subject: Re: Clarifying some issues and a General RFC
Date: 13 Jul 1998 20:51:54
Message: <35AA9D70.167E@rsp.com.au>
As far as any type of mesh conversion of arbitrary objects, has anyone
checked out Ployray.  Last time i used it (quite a while ago now)
Wireframe was one of the rendering output options. For common primatives
you could use a default uv devision or define your own or use a three
plane projection to find a mesh of the objects. I'm no programmer but
this might be worth a look.

Ben


Post a reply to this message

From: Alain CULOS
Subject: Re: Clarifying some issues and a General RFC
Date: 15 Jul 1998 18:34:00
Message: <35A948ED.5ED167C5@bigfoot.com>
Fran & Melissa wrote:

> >is nonlinear transformations, but the reason that hasn't been done is nobody
> >knows how to do it.
>
> The last bit about the non-linear transformations....
> Don't have any idea how to do this but something like
> matrix {
>     <formula,formula,formula>
> etc
>
> Sorta like a translation matrix.
> So to get the new point, take old point and move( change) by formula amount.
> Just an idea. anyway


First of all, you really mean a transformation vector rather than a matrix.
Second, this sort of transformation is very easy to do if you want to plot a
number of points, but in ray-tracing, you cast rays and aim at finding out where
the objects intersect these rays, for this reason ray-tracing with a
transformation vector as you suggest is either extremely computer intensive
(many samples to have some sort of accuracy as to where the ray intersects an
object) or impossible if you really want exact intersections (as far as numeric
calculation allows) because for most of these mathematical equations it is
impossible to have a set of equations that describe the set of solutions. So you
have to give up this very nice fancy idea and restrict it to an easier
mathematical game, for example if you limit your functions to polynoms of degree
2, that makes it degree 6 as a whole, for this there exists powerful root
solvers. Such functions can be nice but you pretty quickly find lots of limits
to what you can do with them, you can only distort your objects in some set
patterns, nothing really weird. Another step is to look for more complex
equations for which we can find roots with a few iterations (not many), ... I'm
working on that sort of possibility but you'll have to wait a few years, unless
someone else comes up with it before I do.

Cheers,
Al.

--
ANTI SPAM / ANTI ARROSAGE COMMERCIAL :

To answer me, please take out the Z from my address.


Post a reply to this message

From: Mathias Broxvall
Subject: Re: Clarifying some issues and a General RFC
Date: 16 Jul 1998 15:50:19
Message: <1dc8533.5jt5jl1it95jeN@dialup148-3-29.swipnet.se>
Ron Parker <ron### [at] rongwmicrocom> wrote:

> The one thing I hear asked for over and over 
> is nonlinear transformations, but the reason that hasn't been done is nobody
> knows how to do it.

It is possible to do (but slow) by expressing the objects as 
mathematical isosurfaces and creating new composite functions that
distorts the object. The following code should work with the isosurface
patch of povray.

------
#declare F1 = function { .... my object ... }
#declare F2 = function { F1(x+noise3d(x,y,z),y+x*x,z) }

isosurface { .... F2 ... }
------

The function F2 declared above would distort the object F1 by
bending it along the y-axis as well as making it 'jagged' along
the x-axis. (At least I think so, haven't tried it yet).

The only problem (despite the speed) with doing this with arbitrary 
objects might be the difficulty with expressing them as mathematical
objects. But as long as all the primitive functions and the 
CSG-operations can be expressed mathematically this should not
be any serious problem.

/ Mathias

PS. For those who don't know what an isosurface object is, it is
an object expressed by a mathematical function where the "inside points"
of the objects evaluate to a value less than zero and the "outside 
points" evaluate to greater than zero.
Example: x*x + y*y + z*z - 1.0   defines a sphere of radius 1
.DS


Post a reply to this message

<<< Previous 10 Messages Goto Latest 10 Messages Next 3 Messages >>>

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