Rune <run### [at] inamecom> wrote:
> AFAIK meshes, bicubic patches and perhaps iso-surfaces can be transformed
> nonlinearly. Or they could if there was functions in POV-ray that was
> designed to do this...
>
> I suggest that we begin to think of the possibilities of implementing such
> functions. I personally believe that it could improve POV-Ray
significantly
> in some of the areas where it is currently not as powerful as many other
> renderers.
>
> To make such functions useable it would probably be necessary to implement
> several different kinds of those nonlinearly transformations. They could
all
> be contained into a statement such as deform {} or something.
>
> One type of deform could be one that deforms dependent on warps:
>
> deform {
>    warp {...}
> }
>
> As you can sure imagine, this alone would be a very powerful and general
way
> of deforming the supported object.
>
> But more complicated ways of deforming may be useful. I have thought of a
> feature that would deform objects by several user-specified regular
> transforms, each weighted by a 3D field in space. I believe this could be
> used for many things. For example it could be used to make a kind of bone
> structure. One part of a mesh body could be enclosed by one field which
> would be transformed by one linear transform. Another part of the body
would
> by due to another field be transformed by another linear transform. The
> 3D-fields could be defined by patterns, which would be very flexible, but
> probably also rather difficult to master and somewhat slow, or they could
be
> controlled in a way similar to blobs, which would be less flexible, but
> surely easier to understand, and probably faster. Possible syntax:
>
> deform {
>    field_transform {
>       sphere {
>          location, radius, strength,
>          transformations (of the field)
>          apply_transform transform_id (of the mother object, such as mesh)
>       }
>       cylinder { (like sphere, but with end1, end2 instead of location) }
>       ...
>    }
> }
>
> alternative way:
>
> deform {
>    field_transform {
>       field {pattern_id, transform_id}
>       field {pattern_id, transform_id}
>       ...
>    }
> }
>
> The pattern way of field_deform could be used with blob_pattern to achieve
> same functionality I guess, but it would probably still be slower.
>
> Other deform types could possible be made too. What do you think of the
> whole idea?

If you would like to experiment a little with mesh and patch deformations,
without modifying the POV code just yet, perhaps you should look at the
Compressed Mesh macro file in conjunction with Warp's Mesh Compressor:

   http://www.geocities.com/ccolefax

The Compressor and Macros combined give you access to the vertices of meshes
(including bicubic patch models), and you are free to warp these at will.
Using various MegaPOV features (such as eval_pigment), you could even try
out ideas like your pattern warps.

Post a reply to this message

In article <3a5ba55b@news.povray.org>, "Chris Colefax" 
<chr### [at] tagpovrayorg> wrote:

> The Compressor and Macros combined give you access to the vertices of 
> meshes (including bicubic patch models), and you are free to warp 
> these at will. Using various MegaPOV features (such as eval_pigment), 
> you could even try out ideas like your pattern warps.

And don't forget the vwarp() function... ;-)
Actually, combined with the displace warp, vwarp() can do anything 
eval_pigment() could be used for.

-- 
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 in message ...
> This does look like a better syntax. If your technique allowed warps to
> be used as deformations, it would be perfect...maybe a compromise would
> be a "deform" warp, but there will be a lot of duplication, since people
> will want deforms that do the same things as many of the warps.
> Is your technique still limited to deformations that can be "reversed"?


yes I think there is compromise between my deform and warps
every deform has defined methods just like methods for objects
this way there could be simple to write type of warp
warp { deform { TYPE PARAMS } }
which call method not assigned to object
and calculate coordinates without duplication of code

I'll check it before release of patch

ABX

Post a reply to this message

Rune <run### [at] inamecom> wrote:
: AFAIK meshes, bicubic patches and perhaps iso-surfaces can be transformed
: nonlinearly. Or they could if there was functions in POV-ray that was
: designed to do this...

  No, meshes and bicubic patches can't be transformed non-linearly.

  If you apply a true non-linear transform to a mesh, that would bend the
individual triangles. This is very hard to do.
  You can, however, move the vertex points (with the triangles still being
flat) to get the impression of a non-linear transform.
  This, however, often introduces artifacts. With a very coarse mesh the
artifacts are more clear (just imagine trying to twist 180 degrees a cube
made of 12 triangles).

  And besides, you can already do this with the PCM macros.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

"Chris Colefax" wrote:
> If you would like to experiment a little with mesh and patch
> deformations, without modifying the POV code just yet,
> perhaps you should look at the Compressed Mesh macro file in
> conjunction with Warp's Mesh Compressor:
>
>    http://www.geocities.com/ccolefax
>
> The Compressor and Macros combined give you access to the
> vertices of meshes (including bicubic patch models), and you
> are free to warp these at will. Using various MegaPOV
> features (such as eval_pigment), you could even try out
> ideas like your pattern warps.

Yes, I've thought of that too. Actually I downloaded the said utilities a
little while ago for that exact reason.

I haven't tried out my ideas yet, but since quite a few
calculations-per-vertice have to be done, I think it will be rather slow in
POV-script. It is worth a try though.

Thanks for the feedback!

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

"Warp" wrote:
> Meshes and bicubic patches can't be transformed non-linearly.

How comes I just knew you would say that?

>   If you apply a true non-linear transform to a mesh, that
> would bend the individual triangles.

That would be a perfect non-linear transform. I'm talking about an
approximation. If things have to be perfect in order to be "true", there's
lots of things POV-Ray and MegaPov can't do:

TRUE atmospheric effects.
TRUE radiosity.
TRUE caustics.
TRUE focal blur.
TRUE fractals.
TRUE area lights.
TRUE motion blur.
...and the list goes on...

How come you never complain when people say these things can be done?

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

I wrote:
> "Warp" wrote:
> >   If you apply a true non-linear transform to a mesh, that
> > would bend the individual triangles.
>
> If things have to be perfect in order to be "true", there's
> lots of things POV-Ray and MegaPov can't do

> How come you never complain when people say these things can
> be done?

Sorry, I think "complain" is not the right English term here. I can't find
the right word right now. Anyway, no offence is intended...

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 <3a5b8dfc@news.povray.org>, "Rune" <run### [at] inamecom> 
wrote:

> I thought this method could work for meshes only, since it would do 
> moving of vertices.

Then it should probably be a specialized feature of meshes, not of a 
"deform" feature...hmm, am I the only one who has noticed there seems to 
be a lot more mesh ideas/patch work being done lately?


> The relative type would be useful for things like bone systems, where 
> every part of the mesh is deformed, and the original locations of the 
> vertices should not have any affection at all. In this case you would 
> want to make sure that your entire mesh is enclosed by the fields.

It might be a better idea to just implement a bone system. Maybe a new 
kind of mesh..."boned_mesh"...would be the easiest way to do things. I'm 
not sure the "deform fields" idea will be very easy to use...but inverse 
kinematics features could be worked into a boned mesh feature, and it 
might be easier to make a new kind of object instead of trying to work 
the additional data/algorithms/syntax into the existing mesh object.


> I still don't know what would be the best way to define the fields with.
> Patterns, blob-like fields, maybe both options, or maybe something 
> entirely different?

Patterns would be the most flexible way. Remember, you can make 
blob-like fields with a pattern, too. You might even be able to use the 
blob pattern. :-)

-- 
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 <run### [at] inamecom> wrote:
: How come you never complain when people say these things can be done?

  Usually people ask somethink like "is it possible to _simulate_ motion
blur with povray?".

-- 
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?putchar('\n'):m)for(_
=(c>>2)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););}  /*- Warp -*/

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3a5d98ee@news.povray.org...
>
>   Usually people ask somethink like "is it possible to _simulate_ motion
> blur with povray?".
>

...as opposed to hurling the monitor across the room or firing it out of a
cannon?

Post a reply to this message