This discussion is starting to be too long...

Wlodzimierz ABX Skiba wrote:
> 

> > Wlodzimierz ABX Skiba wrote:

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

Well, Off-topic, but I think that the CSG is not bugged.

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

Because I have applied (yes, now) the tesselation patch to
a non-megapov version (my personal experimental 3.1),
and within 3.1, mesh cannot be part of a CSG difference/intersection.



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

No sarcasm. Just the expression that your sentence triggered some thinking
in my head... Alas, my thinking seems to have been wrong.

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

As I do not have access to your patch, all I was able to do was 
guessing. Wrongly, I thought that to perform the twist/bend/screw,
you had transformed the object (let's it be a CSG or blob) into a mesh.
Then applying a transformation to the vertex of this mesh.


> 
> I think you are completly wrong in thinking about me.
> 

I agree.

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

Rotate/translate/scale : yes, the object definition must provide a function
for them

Set flag: no, it's part of the core structure of an object and it
is handled by a single parser function.

> almost all modifiers are independent of type of object
> (I'm talking about internal structure)

Yes, because all type of object have the core structure of object.

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

Well, you may have to reallocate the instanced object structure because some
object have bigger structure than other ones.

That's why I do not like the idea of an object modifier which nearly
substitute a structure for another.

When the script start saying it want a Pizza, I like to end
with a Pizza (even if you change the pepperoni for pineapple
and the sweet pepper for some corn).

From my point of view (nobody has to agree with it), the recipe
for the Pizza is in one single c file (sphere.c, csg.c, blob.c,
super.c, you name it...) and the other c files contains some
recipes for some other meals.

So, currently, my understanding of modifying on the fly the object
pointers via a generic object modifier , outside of the specific
object file, sounds to me like the script seems to ask for a Pizza
 and is finally served with a plate of Sushi.

I do not like this confusing approach, even if I can both like
Pizza and Sushi.


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

This may be the start of a full chapter of holy war about the pov syntax,
should it be object oriented or not, should it looks like C++ or some
others language, and so on.

I do not care, as I'm not in charge of defending the syntax.
I would prefer to see your patch public, even done with a way I do not
like , rather than nothing. Afterall, the povteam will be able 
to change it to the way they want if they ever find it too confusing
or too complex or inadequate (or whatever).
 
> my deformations are internal another kind of object and at first it was another
> object in povsyntax

Sound good for me...

> 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 

Warp are built-in the engine, so that's easy when evaluating the texture to 
apply a warp to it. 
But deforming an object

> - 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()
> 

I think you should not have listen to the advisers, it would have make
me happier :-)
Or maybe there was a misunderstanding when people see your picture:
(I was assuming you used a mesh due to a final sentence stating in one
of your message that it may be easier to modify the vertex of a mesh)

May be some where saying that since the warp option already provide
a transformation of the space, it would be productive to have your 
transformation to use the existing warp, so that adding a warp automatically
add a new transformation of object.
This is logical when one thing you're modifying a mesh: you enter the 
original vertex in the warp and you exit of it with the new coordinate vertex.
In this case, it is logical to have a syntax such as

mesh { .... deform { warp_element } }

because there is a definitive added value to the fact of reusing the
transformation made by the warps.

> 
> I've not finished it yet and I don't want publish not finished code only to
> proof something.

Good, but I would very like to see how you resolve the problem
of the shadow and reflection (transforming an object only for the camera,
I can do it, but my headache starts when I start thinking about
the reflected ray and the lights ray...).

> Although I don't think that I did miracle.

Well, the twist/bend/screw thing is resisting many pov-programmers, including
me recently...

> I don't want fight with you. 

Neither do I.

> Whole
> method was descibed here, in p.u-p with symbolic algorithm.

I found the thread, but did not see the symbolic algorithm. 
Can you provide the reference of the message, thanks.


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

I'm curious... I will have to wait...

> >
> > May be they may be just MESH modifiers.
> 
> meybe not

Well, with my previous hypothesis (which is wrong), 
they would only have been modified Mesh.

Now, the tesselate patch introduce an interesting approach.
Applying a mesh-deform patch using warp definition 
as mesh modifier to a tesselated
object allow get all the warp being available to play
with all objects that can be tesselated.

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

Ouch... 





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

Nice!!! 
I can imagine how to do it with a warp-based mesh deformation,
but you probably did it with a real checkered box.

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

I was wrong, 
But may I ask to have some background checkered planes and some
shadows of the box casted on them. I'm really curious.

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

May I ask who care ?
IMO, do your patch your way, then let people comment them and
use them.
I prefer to have a lot of patches than none... as long
as you do not break everything...

Post a reply to this message