POV-Ray : Newsgroups : povray.unofficial.patches : Seems that the tesselation patch died before even being born : Re: Seems that the tesselation patch died before even being born Server Time
2 Sep 2024 02:15:14 EDT (-0400)
  Re: Seems that the tesselation patch died before even being born  
From: Jérôme Grimbert
Date: 18 Jan 2001 04:15:48
Message: <3A66B445.C9C8BA03@atosorigin.com>
Wlodzimierz ABX Skiba wrote:
> 
> ough, I don't like write explanations becouse my vocabulary appears poor :-(
> 
> Warp wrote in message <3a65c258@news.povray.org>...
> >Wlodzimierz ABX Skiba <abx### [at] abxartpl> wrote:
> >: did you consider my proposition to put tesselation as part of object
> modifiers ?
> >
> >  I think that would be more difficult than it may sound.
> 
> I did it for my deform patch
> Everything what it need is to change parse_object_mod to return (OBJECT *)

That modification would be easy, maybe...

> and change Parse_*() functions.

But not that one : do you have an idea of the number of functions 
to patch ?

Moreover I found it counter-productive and dangerous:
 let's say we have a CSG operation (not a union) and
 you modify ONE of the component to tesselate while the
 other components remained unchanged.
 I'm not sure the CSG would still be possible.
 As a basic-final-user, I cannot understand why modifying a tiny attribute of
 a sphere/superellipsoid/cone/cylinder/box/whatever in a CSG construct 
 make a script failure...

Sincerely, I just like the way the tesselation object was introduced:
 it is a new object. dot. 
 Trying to be able to have the mesh object able to include it in
 its definition may or not be a good thing, I do not know.


> 
> > When povray parses an object, it creates internally an object of that
> > type. A tesselation modifier would have to change that object to a mesh
> > object.
> 
> when you tesselate object you do it probably to use it insted of original object
> for user there could be no difference - only speed up

No, at least for me: tesselation would also provide a different aspect
 (the 'polygon'/facet aspect), and that's also interesting.
 (instead of playing with the normal vector with a complex pattern)


> 
> >  I'm not sure if there is any advantage in this either.
> 
> I know that some peoples don't like such word like "modeller" according to
> POV-script
> but in modellers there is taskbar with operations applied to object and
> rotation, scale and other linear operations are neighbours for 

Yes the classical mods,

> twisting,
> bending, screwing 

This is the 'classical' problem with the POV approach: the intersection
of an object with a curved ray...

The 'twist/bend/screw' cannot be applied to all objects, but you
could make them to be some new 'object' (?) that would take a 
mesh-like object and some parameters:

 twist { object {my_mesh}, <center.x,center.y,center.z>,<axis.x,axis.y,axis.z>,
angle... }
 bend { object {my_mesh}, <center.x,center.y,center.z>,...}
 screw { object {my_mesh}, <center.x,center.y,center.z>,<axis.x,axis.y,axis.z>,
pitch... } 

Then when parsing, your 'object' is twisted/bent/screwed by 'simply' applying
a blind transformation to each vertex of the mesh

(beware: you not only have to transform the position of the vertex, but also
the normal... so the 'simply' is an overstatement).

>and neighbours for smoothing by removing of vertex, incresing
> amount of vertex and something.

That should be easy with the parameter of tesselation.


Post a reply to this message

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