> Wlodzimierz ABX Skiba wrote:

>
> > > 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.
> >
> > sometimes when you translate/rotate/scale component of CSG
> > rest of CSG dissapeare
>
> This may be a bug (unless the intersection/difference leave nothing,
> in such case I would considere that it is normal).

yes, I'm talking about  leaving nothing
but I can't understand your thinking that
tesselation as object modifier is dangerous
considering ideal tesselation - tesselated object has inside and
outside just like base object - than why it couldn't be part of csg ?

> > > Sincerely, I just like the way the tesselation object was introduced:
> > > it is a new object. dot.
> >
> > if you have large definition of object you must
> > jump over source to tesselate it : "tesselation {" at beginning and "}" at
end
> > when you put this as object modifier you must type only in one place.
>
> This is only a problem for the editor.

I agree

> And you may as well have a single line
> #local to_be_tessalated = <<your big construct>>
>
> tesselate { object { to_be_tessaleted } }

you still have to jump to write #local and tesselate, but nevermind

> > But consider that I'm talking about ideal tesselation with inheritance of
> > parameters such no_image, texture, hollow etc. from base object.
>
> Ring some bells here about 'object'

I'm sorry, my english is not enough to understand meaning of this sentence
is it some idom,  is it sarcasm ?

> > > > 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...
> >
> > But I've resolved this in my putch a little :-)
>
> Yep, looks like we do not have the same definition for 'object'
> If I understand your definition, and abuse it somehow,
> all we need in Pov is the sphere object.

I'm affraid you are completly wrong in understanding me

> My definition of object is based on the internal structure,
> once parsed.
> So, if you look at the source, there is a sphere object and
> another one which is an ellipsoid.
> and a box object,
> and a cone/cylinder object,
> and a superellipsoid object, and so on...

I think you are completly wrong in thinking about me.

> Basically, an object has a method which return all the intersection
> of a ray with the object.

right

> So from my current understanding of the tesselate patch (not opened yet),
> it is an easy way to obtain a mesh object.
> I can hardly see tesselate as
> a generic modifier, because pov does not end with the same parsed structure:
> without the modifier, the object structure holds pointers to the csg
functions,
> with the modifier, the object structure holds pointers to the mesh functions.

but for almost every modifer it calls soemthing like "method" to do something -
rotate, translate, set_flag

almost all modifiers are independent of type of object
(I'm talking about internal structure)
(independant this means that they have something like pointer->method or
function(pointer) and this "method" only internal depends of type of object)
never mind if it is sphere, cylinder or isosurface
if you smart replace pointer (internal) to currently parsed object you can make
it invisible
for that tesselated object is putted instead of original object

I play some years with pov
I don't like to be intruder in any community therefore since year I slowly read
whole news.povray.org to understand meaning of life :-) and I never meet opinion
that povsyntax should be mirror of internal structure. Perhaps I'm wrong but I
never meet. It shouldn't go far from internal but if there is something to
simply understand with syntax different than internal structure why not ?

my deformations are internal another kind of object and at first it was another
object in povsyntax
but when I announced my proposition in this group there was opposition that
deformation such like twist should be rather (compared with warp{}) modification
with proper parameters - therefore I changed syntax to object modifiers but
internals it is still another kind of object - it is just easier method to do it
for me becouse it has different method all_intersections()

> > > 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:
> >
> > What you mean by "cannot" ?
> > In my patch they can.
>
> Please, tell me where I can see the code for it.
> I'm interested to see how you perform this miracle.

I've not finished it yet and I don't want publish not finished code only to
proof something.
Although I don't think that I did miracle. I don't want fight with you. Whole
method was descibed here, in p.u-p with symbolic algorithm.
I don't think that my method is best way - it has limitations (reversable
deformations) and it has something like accuracy (like isosurfaces) but it works
for all objects, not only for meshes.

> > > Then when parsing, your 'object' is twisted/bent/screwed by 'simply'
applying
> > > a blind transformation to each vertex of the mesh
> >
> > This cause a lot of new types of objects.
> > All this stuff shuld be IMO in object modifiers.
>
> May be they may be just MESH modifiers.

meybe not

> But I cannot still understand
> how you can apply them into the resolving intersection of a line
> and a sphere (e.g. as is currently the function for the sphere object)
> when applied to a true basic object (and not a set of triangles)

by spliting ray to short segments and deform them and intersect base object

> > > (beware: you not only have to transform the position of the vertex, but
also
> > > the normal... so the 'simply' is an overstatement).
> >
> > perhaps you missed some images in p.b.i
>> just look at topics with word "deform" sended by me
>
> I also probably missed the deformation of the texture!

this is the part what I'm working on

> And in p.b.i, all I see from you is about ten posts, but
> none with deform
> (but I seems to remember some sliced/twisted box,
> so may be my newsreader is bogus)

http://www.abx.art.pl/pov/nonlinear/step3.jpg

> > when I twist box, my eyes see twisted box, not another type of object
> > even if it is triangulated
>
> Your eyes see a twisted box, but the code will probably see a mesh,
> which may look like a box but is not really a box.

I see the code, you not
believe me that code see not twisted box
even if I see twisted one

is there any other person who can vote against or opposite for:
a) deform as part of object modifiers
b) tesselate as part of object modifiers
it is not oblique voting for authors of patches but let's disscuse

ABX

Post a reply to this message