I can't find the bug. No-one else can either (I have consulted with Ron,
Nathan and Chris H).
  There's a persistent bug (I wrote about it some time ago) and I just can't
find what's wrong with the code. I don't think that it's typing mistake
or anything, but I have the feeling that some povray functions might work
a bit differently than I expect and that's what's causing the problem.
Finding the problem would require more knowledge about povray and/or a lot
of testing.
  The patch would be more or less ready if there wasn't that bug.

  So I'm sorry. I can't make it.

-- 
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?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););}    /*- Warp -*/

Post a reply to this message

Warp wrote in message <3a6479cc@news.povray.org>...
>  So I'm sorry. I can't make it.


what a pity!

ABX

Post a reply to this message

Warp wrote:
> 
>   I can't find the bug. No-one else can either (I have consulted with Ron,
> Nathan and Chris H).
>   There's a persistent bug (I wrote about it some time ago) and I just can't
> find what's wrong with the code. I don't think that it's typing mistake
> or anything, but I have the feeling that some povray functions might work
> a bit differently than I expect and that's what's causing the problem.
> Finding the problem would require more knowledge about povray and/or a lot
> of testing.
>   The patch would be more or less ready if there wasn't that bug.
> 
>   So I'm sorry. I can't make it.
> 
Oh, man, don't quit like this! This tesselation is quite promising (I
think about implementing displacement shaders in POV-Ray and tesselation
of POV-Ray primitives will become handy in this case, as it is
relatively easy to displace meshes).

Is this bug related to the translation of primitive (i.e. is this
described in message 
Subject:    Re: Tesselation and mesh data extraction patches
Date:       19 Dec 2000 04:14:55 -0500)? 
Are the triangles teared off from others or are additional triangles
generated? Lighting in these pictures does not allow to see "under the
crack" and I can't make it out, which is the case. 
Hmm, You make me really curious, can you make source available (or mail
me)? I feel challenge here...

Or alternatively:
You work in university? Here is tip: offer this bug hunting to some
student and promise to give assessment (is it right word?) or other
bonus, if he/she can find it. Next "Linus Torvalds" can spot it for
sure!

Post a reply to this message

Warp wrote:
> 
>   I can't find the bug. No-one else can either (I have consulted with Ron,
> Nathan and Chris H).
>   There's a persistent bug (I wrote about it some time ago) and I just can't
> find what's wrong with the code. I don't think that it's typing mistake
> or anything, but I have the feeling that some povray functions might work
> a bit differently than I expect and that's what's causing the problem.
> Finding the problem would require more knowledge about povray and/or a lot
> of testing.
>   The patch would be more or less ready if there wasn't that bug.
> 
>   So I'm sorry. I can't make it.
> 

Oh, please don't give up.  

Anyway, do you mind giving some more detailed description about the
problem.  Not that i think i can find a bug that you, Ron, Nathan and
Chris Huff have not found during long search, but i would be interested
where the problem lies.  

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

Vahur Krouverk <vah### [at] aetecee> wrote:
: Is this bug related to the translation of primitive

  It's the same bug, but it's not related to the translation of the primitive.
It seems that it's just related to its location (that is, surfaces at
certain locations are not tesselated correctly for some reason).

  Perhaps I should just make the patch public and let it be. Perhaps someone
would come up with a solution.

-- 
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?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););}    /*- Warp -*/

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote:
: Anyway, do you mind giving some more detailed description about the
: problem.  Not that i think i can find a bug that you, Ron, Nathan and
: Chris Huff have not found during long search, but i would be interested
: where the problem lies.  

  Well, Ron and Nathan are quite busy with pov3.5 so they don't have too
much time to look at my code. However, Nathan already found a serious bug
earlier.
  (This bug might be similar to the one fixed by Nathan because the
effects are similar, but I just can't find the reason.)

-- 
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?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););}    /*- Warp -*/

Post a reply to this message

>   The patch would be more or less ready if there wasn't that bug.

then publish and be dammed. ( a few bugs never stopped anybody else!)

>   So I'm sorry. I can't make it.

just publish with an open request for bug hunters


--
Rick

POV-Ray News & Resources - http://povray.co.uk
Kitty5 WebDesign - http://kitty5.com
Hi-Impact web site design & database driven e-commerce
TEL : +44 (01625) 266358 - FAX : +44 (01625) 611913 - ICQ : 15776037

PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA

Post a reply to this message

In article <3A648358.7C22C85F@gmx.de>, Christoph Hormann 
<chr### [at] gmxde> wrote:

> Anyway, do you mind giving some more detailed description about the
> problem.

It basically seems to be that triangles don't always end up where they 
are expected...every once in a while, in a very reproduceable but 
unpredictable manner, one (or more?) vertex of a triangle will end up 
where it shouldn't be, leaving a hole in the mesh. At least, that is 
what I could figure out...(A similar problem killed my warpable mesh 
patch.)
I have been planning to dive into the main mesh functions to figure out 
how they work, but I don't know much about the way that code works and 
the code isn't very self explanatory...

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

In article <3a6479cc@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   The patch would be more or less ready if there wasn't that bug.

I'd release it anyway...it isn't useless, and someone else may see 
something. At least people would be able to work on object-specific 
tesselation, patches that will depend on the tesselation patch, etc...

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

Warp wrote:

>   I can't find the bug. No-one else can either (I have consulted with Ron,
> Nathan and Chris H).
>   There's a persistent bug (I wrote about it some time ago) and I just can't
> find what's wrong with the code. I don't think that it's typing mistake
> or anything, but I have the feeling that some povray functions might work
> a bit differently than I expect and that's what's causing the problem.
> Finding the problem would require more knowledge about povray and/or a lot
> of testing.
>   The patch would be more or less ready if there wasn't that bug.
>
>   So I'm sorry. I can't make it.

Aagh. Debugging is the bain of your existence no doubt. Knowing your programming
skill no doubt if you can't find it it is quite a problem indeed. There's so
much complicated inner workings that can elude you, I remember a long time ago
trying to make some program with pointers to structures that read the structure
from a binary file, got all screwed up by byte alignment and I had to break the
fread()s down into the individual elements once my brother found the problem.

--
David Fontaine  <dav### [at] faricynet>  ICQ 55354965
My raytracing gallery:  http://davidf.faricy.net/

Post a reply to this message

Did you try the tessellation method for which I sent you a link?  It even
included C++ source code and was free (GPL)

Jim


"Warp" <war### [at] tagpovrayorg> wrote in message
news:3a6479cc@news.povray.org...
>   I can't find the bug. No-one else can either (I have consulted with Ron,
> Nathan and Chris H).
>   There's a persistent bug (I wrote about it some time ago) and I just
can't
> find what's wrong with the code. I don't think that it's typing mistake
> or anything, but I have the feeling that some povray functions might work
> a bit differently than I expect and that's what's causing the problem.
> Finding the problem would require more knowledge about povray and/or a lot
> of testing.
>   The patch would be more or less ready if there wasn't that bug.
>
>   So I'm sorry. I can't make it.
>
> --
> 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?puts(""):m)for(_=(
> c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););}    /*- Warp -*/

Post a reply to this message

Chris Huff <chr### [at] maccom> wrote:
: I'd release it anyway...it isn't useless, and someone else may see 
: something. At least people would be able to work on object-specific 
: tesselation, patches that will depend on the tesselation patch, etc...

  Ok.
  I could release it right now, with the current syntax, that is, the
tesselate-block is a separate object, or I could see if it's easy to
put the tesselate-block inside the mesh-block and make the proper
modifications (that would really add flexibility to it).
  Which one do you people prefer?

  I doubt that anyone can use the patch for anything serious, though.
Although the bug happens rather rarely, it still happens too often. You
only need an object that is large enough, and you'll get holes here and
there...

-- 
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?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););}    /*- Warp -*/

Post a reply to this message

Jim Kress <kre### [at] kressworkscom> wrote:
: Did you try the tessellation method for which I sent you a link?  It even
: included C++ source code and was free (GPL)

  Nope, sorry.
  I don't think that the problem is in the tesselation algorithm, but
somewhere else, that's why I haven't looked into other algorithms.

-- 
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?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););}    /*- Warp -*/

Post a reply to this message

Warp wrote:
> 
> Chris Huff <chr### [at] maccom> wrote:
> : I'd release it anyway...it isn't useless, and someone else may see
> : something. At least people would be able to work on object-specific
> : tesselation, patches that will depend on the tesselation patch, etc...
> 
>   Ok.
>   I could release it right now, with the current syntax, that is, the
> tesselate-block is a separate object, or I could see if it's easy to
> put the tesselate-block inside the mesh-block and make the proper
> modifications (that would really add flexibility to it).
>   Which one do you people prefer?
> 

<fool speaking>
Release it now, just like it is as a separate object,
so I can try to add it to my pov-source and try to find where is that bug...


>   I doubt that anyone can use the patch for anything serious, though.
> Although the bug happens rather rarely, it still happens too often. You
> only need an object that is large enough, and you'll get holes here and
> there...
> 

<More fool to come>
If you can also provide two sample scenes, one without any bug and
one in which the bug manifest itself (holding a big sign and asking
for recognition of bug's rights...)

<no more fool (?)>

Whatever your choice for the syntax, please release this patch...

Post a reply to this message

Warp wrote:

>   So I'm sorry. I can't make it.

I agree with what other people said. Release the patch. Even with the bug it
could still be useful enough for many things and I'm pretty sure that somebody
(or even yourself) will come along and find what happens. Tesselation, like
shaders or radiosity, opens too many significant fields for POV.
Just credit some big software corporation for the bug if you don't want to take
the blame ;-)


G.

--

**********************
http://www.oyonale.com
**********************
Graphic experiments
Pov-ray gallery

Post a reply to this message

I'm just making the required additions to support the tesselate-block
inside meshes. It's a lot easier than I thought.

-- 
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?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););}    /*- Warp -*/

Post a reply to this message

By the way, instead of _moving_ the tesselate block inside the mesh block,
I'm _adding_ it there.
  That is, the old method still works, ie. you can just create a tesselated
object alone like this:

tesselate { MyObject accuracy 20 smooth }

but you can also add tesselated objects into a mesh like this:

mesh
{ (optionally triangles and smooth triangles)
  tesselate { MyObject1 }
  tesselate { MyObject2 }
}

-- 
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?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););}    /*- Warp -*/

Post a reply to this message

In article <3a653acf$1@news.povray.org>, "Jim Kress" 
<kre### [at] kressworkscom> wrote:

> Did you try the tessellation method for which I sent you a link?  It even
> included C++ source code and was free (GPL)

His tesselation code seems to be working fine, it seems to be the adding 
of the triangles to the mesh which is the problem.
I'm beginning to think it would be worth it to write new mesh code for 
use in this kind of patch...a new object type that would be used 
internally and a group of functions for manipulating the data. Or find 
someone to explain the mesh code...

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

Warp wrote in message <3a65aa59@news.povray.org>...
>  By the way, instead of _moving_ the tesselate block inside the mesh block,
>I'm _adding_ it there.


did you consider my proposition to put tesselation as part of object modifiers ?

ABX

Post a reply to this message

> mesh
> { (optionally triangles and smooth triangles)
>   tesselate { MyObject1 }
>   tesselate { MyObject2 }
> }

	My question will sound weird, but...
	Can you tesselate a mesh object ?

	The use would be to change the number of triangles in the
initial mesh, for instance to get a 'preview' mesh that would have
10 times less triangles - a little faster to render, but much faster
to parse especially when creating the bounding box tree.
	For me it would be quite interesting. In my patch I'm using
a simple (and crude) vertex decimation method to quickly simplify
mesh objects (from binary files, so it's different from the normal
parsing) for previewing purpose. The resulting mesh looks like a
building of cubic blocks rather than a smooth thing. See some
examples on this page:

http://pov4grasp.free.fr/features/grasp_surface/preview.php3

	If your code works for mesh objects, and is really fast,
then I've two reasons more to support you for releasing your patch
pretty soon so that someone can fix the bug you mention (I'm not
this superguy I suspect) !


*** Nicolas Calimet
*** http://pov4grasp.free.fr

Post a reply to this message

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.
  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.
  I'm not sure if there is any advantage in this either.

-- 
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?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););}    /*- Warp -*/

Post a reply to this message

Nicolas Calimet <pov### [at] freefr> wrote:
: 	Can you tesselate a mesh object ?

  The patch can tesselate any solid object with a finite bounding box.
  If you want to tesselate a mesh, you'll have to make it solid (with
the inside_vector feature). I haven't tested it, but it should work
(as long as the solid mesh patch works).

-- 
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?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););}    /*- Warp -*/

Post a reply to this message

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 *)
and change Parse_*() functions.

> 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

>  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 twisting,
bending, screwing and neighbours for smoothing by removing of vertex, incresing
amount of vertex and something.

I you have ready function Parse_Tesselation() I can try simple apply to my
modified source of deform patch to apply your syntax and my proposed syntax.

hmm, I don't think that I explained :-(

ABX

Post a reply to this message

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

Jérôme Grimbert wrote in message <3A66B445.C9C8BA03@atosorigin.com>...
> > and change Parse_*() functions.
>
> But not that one : do you have an idea of the number of functions
> to patch ?

everyone which calls parse_object_mods()
or I don't understand question
as I said I did it for source of megapov 0.6
and it took about 1 hour and it works

> 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

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

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

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

but you still can do it with tesselation as part of object modifiers, just with
this

#declare Object=csg{}
object{ Object }
object{ Object translate x*10 tesselate { 10, 7, 11 ... } }

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

But I've resolved this in my putch a little :-)

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

> 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

This cause a lot of new types of objects.
All this stuff shuld be IMO in object modifiers.

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


when I twist box, my eyes see twisted box, not another type of object
even if it is triangulated

ABX

Post a reply to this message

Wlodzimierz ABX Skiba wrote:
> 
> Jérôme Grimbert wrote in message <3A66B445.C9C8BA03@atosorigin.com>...

> > 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).
But I do not think it may be a reason for the tesselation as
an object modifier.


> > 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.
And you may as well have a single line
#local to_be_tessalated = <<your big construct>>

tesselate { object { to_be_tessaleted } }

If clear and understandable source is your purpose.




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

to make a cylinder, add a cylinder modifier
to make a box, add a box modifier
to make a cone, add a cone modifier
to make a superellipsoid, add a superellipsoid modifier
to make a quartic, ...

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

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

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.

It's too much for a modifier, at least for me ! 
(probably the only object which play this
kind of trick is the sphere when scaled unevenly: it replace the pointers
with the ones for the ellipsoid. But then, they are really similar object
and they are coded in the very same file, so that's very different from
your suggestion with tesselate).



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

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

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

> 
> 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.
And if it is not really a box, it should not be parsed as a box...

Best regards, and probably more to come once I will have read the
tesselation patch...

Post a reply to this message

Jérôme Grimbert wrote in message <3A671B8F.A4774B74@atosorigin.com>...
> Wlodzimierz ABX Skiba wrote:
> > Jérôme Grimbert wrote in message <3A66B445.C9C8BA03@atosorigin.com>...
>
> > > 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

Chris Huff wrote:
> 
> It basically seems to be that triangles don't always end up where they
> are expected...every once in a while, in a very reproduceable but
> unpredictable manner, one (or more?) vertex of a triangle will end up
> where it shouldn't be, leaving a hole in the mesh. At least, that is
> what I could figure out...(A similar problem killed my warpable mesh
> patch.)

Funny. I had the same problem when I tried to do a tessellation macro, which
used the marching tetrahedrons technique (the same as Warp's patch, no?)...
Of course I never did bother to do a thorough debugging session, so 'twas
probably just something silly.

-- 
Margus Ramst

Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg
Home page http://www.hot.ee/margusrt

Post a reply to this message

Jérôme Grimbert wrote in message <3A66B445.C9C8BA03@atosorigin.com>...
>Wlodzimierz ABX Skiba wrote:
>> and change Parse_*() functions.
>
>But not that one : do you have an idea of the number of functions
>to patch ?


26 in the official version, more in MegaPOV.

--
Mark

Post a reply to this message

This discussion is starting to be too long...

Wlodzimierz ABX Skiba wrote:
> 
> Jérôme Grimbert wrote in message <3A671B8F.A4774B74@atosorigin.com>...
> > 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

Jérôme Grimbert wrote in message <3A68263D.D04702C7@atosorigin.com>...
> > 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

Wlodzimierz ABX Skiba wrote:
> 
> Jérôme Grimbert wrote in message <3A68263D.D04702C7@atosorigin.com>...

> 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

Jérôme Grimbert wrote in message <3A684B88.BCAEDE32@atosorigin.com>...
> > 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

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