POV-Ray : Newsgroups : povray.unofficial.patches : Seems that the tesselation patch died before even being born Server Time
2 Sep 2024 02:15:53 EDT (-0400)
  Seems that the tesselation patch died before even being born (Message 31 to 34 of 34)  
<<< Previous 10 Messages Goto Initial 10 Messages
From: Wlodzimierz ABX Skiba
Subject: Re: Seems that the tesselation patch died before even being born
Date: 19 Jan 2001 07:53:47
Message: <3a6838db@news.povray.org>

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

the main part of my plans is connected with features of 3.5 and
therefore I think always about features of megapov
but right - solid triangle mesh is part of "Meybe" of
http://www.povray.org/3.5-status.html

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

there is more about my idea in p.u-p in todays posts

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

I don't want tesselate anything without agreement of user

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

well written documentation should have description what deform{} cause

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

right

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

right

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

I plan support this built-in engine of warps

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

perhaps :-)
but I play with this syntax
and it is just simpler to me

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

I must finish my opened functions and than I prepare some images to p.b.i
I think it will be ready to send after weekend

> > Although I don't think that I did miracle.
>
> Well, the twist/bend/screw thing is resisting many pov-programmers, including
> me recently...

Well, currently I play with pure mechanism of inheriting of textures
You can halp me with type of deformations
every deformations should have described four things
b) undeform function
a) deform function (with calculation of new normal)
c) calculation of new bbox of deformed bbox
d) calculations of begining and ending of ray crossing deformed shape (for
twisting it is cylinder)

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

Here is symbolic notation of my all_intersections method:

take depth1 and depth2 for container or bounding box
take function deform and undeform (opposite to deform)
for i=depth1 to depth2 step accuracy
  point1=evaluate_ray(trace_ray,i)
  point2=evaluate_ray(trace_ray,i+accuracy)
  pointA=undeform(point1)
  pointB=undeform(point2)
  deformed_ray=create_ray_beetwen(pointA,pointB)
  all_intersections(deformed_ray,base_object)
  for every intersection beetween pointA and pointB
    get deformed intersection and deformed normal with deform(intersection)
    if it is beetween pointA and pointB than put it on stack
  end for
end for

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

after advice of Chris Huff I plan to omit this limitations

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

please read about my plans in "torus torture" thread in p.b.a or p.u.p

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

sorry, what's wrong ? :-)

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

right, with uv-mapping

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

as I said I'll prepare some images for you

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

if there is no difference for me where I put definition of patch
than I want do something for community - where they want

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

ok. here is current list of closed modifications

new module deform.c with definition of Deform object
new Parse_Deform() in parse.c
new closing parts of functions called Parse_Object_Mod()
new CASE in Parse_Object_Mod()
some new tokens
new field in ISTACK
new parameter to all All_Intersections with max_depth

Best regards,

ABX


Post a reply to this message

From: Jérôme Grimbert
Subject: Re: Seems that the tesselation patch died before even being born
Date: 19 Jan 2001 09:13:27
Message: <3A684B88.BCAEDE32@atosorigin.com>
Wlodzimierz ABX Skiba wrote:
> 


> there is more about my idea in p.u-p in todays posts
> 

Yes !!!

> I don't want tesselate anything without agreement of user
> 

Agreed, now that I've seen your approach...
I would still think it would have been a new object (kind of 
CSG variants/mutation...)


> well written documentation should have description what deform{} cause

Yes. But that's probably for later...


> I plan support this built-in engine of warps
> 

That's a good thing!



> 
> Well, currently I play with pure mechanism of inheriting of textures
> You can halp me with type of deformations
> every deformations should have described four things
> b) undeform function

This limit you to inversable transformation.
Beware, some warps have singularity...

> a) deform function (with calculation of new normal)

I am wrong in thinking that the deformation of the normal
is simply the resulting deformation of both extremity ?

> c) calculation of new bbox of deformed bbox

Yes, not obvious for some deformation.
But if you have a container object, I do not see the need
for that.

> d) calculations of begining and ending of ray crossing deformed shape (for
> twisting it is cylinder)

That's the all_intersection of the container, isn't it ?

> for i=depth1 to depth2 step accuracy

That was the reason of my 'Ouch...'
It may slow down a lot!


> 
> after advice of Chris Huff I plan to omit this limitations

Which one ? the reversable transform ? How ?


> > > > 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...
> 
> sorry, what's wrong ? :-)
> 

I just imagined the explosion of additional rays to cast...

> > > 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.
> 
> right, with uv-mapping
> 

Why ? a warp should have been enough...
(deform the box, warp the texture, with the same equations...)


> > But may I ask to have some background checkered planes and some
> > shadows of the box casted on them. I'm really curious.
> 
> as I said I'll prepare some images for you
> 

Thanks you.


> ok. here is current list of closed modifications
> 
> new module deform.c with definition of Deform object

So, it is an object... I like it.

> new Parse_Deform() in parse.c

Obviously.

> new closing parts of functions called Parse_Object_Mod()
> new CASE in Parse_Object_Mod()

Here we had a little divergence of opinions, but 
please do it your way.

> some new tokens

Yes, Obviously.

> new field in ISTACK
> new parameter to all All_Intersections with max_depth

These I will probably not like either...

Have a nice week-end.


Post a reply to this message

From: Wlodzimierz ABX Skiba
Subject: Re: Seems that the tesselation patch died before even being born
Date: 19 Jan 2001 09:38:00
Message: <3a685148@news.povray.org>

> > well written documentation should have description what deform{} cause
>
> Yes. But that's probably for later...

but before publicity of code/patch

> > I plan support this built-in engine of warps
>
> That's a good thing!

Thanks redirected to Chris

> > Well, currently I play with pure mechanism of inheriting of textures
> > You can halp me with type of deformations
> > every deformations should have described four things
> > b) undeform function
>
> This limit you to inversable transformation.
> Beware, some warps have singularity...

please read explanation about it in my todays posts in p.u.p

> > a) deform function (with calculation of new normal)
>
> I am wrong in thinking that the deformation of the normal
> is simply the resulting deformation of both extremity ?

yes, you are wrong, there was some posts about this problem
in this group and in p.a-u

> > c) calculation of new bbox of deformed bbox
>
> Yes, not obvious for some deformation.
> But if you have a container object, I do not see the need
> for that.

I'm talking exactly about container bounding

> > d) calculations of begining and ending of ray crossing deformed shape (for
> > twisting it is cylinder)
>
> That's the all_intersection of the container, isn't it ?

not exactly, but mainly yes

> > for i=depth1 to depth2 step accuracy
>
> That was the reason of my 'Ouch...'
> It may slow down a lot!

not so much
less than the same thing realized with isosurface
more than the same thing realized with mash
but as you can observe my method has better accuracy than mesh

> > after advice of Chris Huff I plan to omit this limitations
>
> Which one ? the reversable transform ? How ?

there is more about my idea in p.u-p in todays posts

> > > > by spliting ray to short segments and deform them and intersect base
object
> > > Ouch...
> > sorry, what's wrong ? :-)
> I just imagined the explosion of additional rays to cast...

you only imagine but I have tested this
it is not so bad solution

> > > > 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.
> >
> > right, with uv-mapping
>
> Why ? a warp should have been enough...
> (deform the box, warp the texture, with the same equations...)

why ? just for test that uv-mapping works correct with my patch

> > new closing parts of functions called Parse_Object_Mod()
> > new CASE in Parse_Object_Mod()
>
> Here we had a little divergence of opinions, but
> please do it your way.

thanks

> > new field in ISTACK
> > new parameter to all All_Intersections with max_depth
>
> These I will probably not like either...

perhaps max_depth could be added to ray structure instead of all_intersections
I will check this

ABX


Post a reply to this message

From: Chris Huff
Subject: Re: Seems that the tesselation patch died before even being born
Date: 19 Jan 2001 16:30:10
Message: <chrishuff-1B7207.16311519012001@news.povray.org>
In article <3a685148@news.povray.org>, "Wlodzimierz ABX Skiba" 
<abx### [at] abxartpl> wrote:

> > > I plan support this built-in engine of warps
> >
> > That's a good thing!
> 
> Thanks redirected to Chris

Me? I just suggested using warps...you are the one implementing this 
thing. I still don't quite understand how your algorithm works...though 
it obviously does.

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

<<< Previous 10 Messages Goto Initial 10 Messages

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