Regarding the tesselation patch, the source are now available from
http://jgrimbert.free.fr/pov/patch/tessel/index.html

Beware, if USA patent laws apply to you, you should not download it
(I refuse to take the responsability, you have been warned!)

This patch is obviously missing one big thing: use of formula & iso for various
effects!
This should come in when the source of 3.5 become available.

Also, lack of feedback during the linux-binary-only did not help with the syntax
improvement
process!
-- 
Non Sine Numine
http://grimbert.cjb.net/
Etiquette is for those with no breeding;
fashion for those with no taste.

Post a reply to this message

Le Forgeron scribis news:3D25F7A8.A0B3A0FA@free.fr:

> Beware, if USA patent laws apply to you, you should not download it
> (I refuse to take the responsability, you have been warned!)
> 

Who is going to tell on us?

-- 
Gis poste, Arto.

Post a reply to this message

Le Forgeron wrote:
> 
> Regarding the tesselation patch, the source are now available from
> http://jgrimbert.free.fr/pov/patch/tessel/index.html

Nice, but i think the documentation could be improved, i'm not sure about
the meaning of various parameters.  There are also differences between the
french and english version of the description.

I also have a suggestion:

The 'move < coeff_of_matrix(12) >' could be replaced with a transform.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 30 Jun. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

Arthur Flint wrote:
> 
> Le Forgeron scribis news:3D25F7A8.A0B3A0FA@free.fr:
> 
> > Beware, if USA patent laws apply to you, you should not download it
> > (I refuse to take the responsability, you have been warned!)
> >
> 
> Who is going to tell on us?

Echelon, NSA, your neighbourgs, your son or daughter, your wife or husband,
your father or mother, BSA, SPA, your best friend... who knows ?
(In fact, wo does not know, wy is at the first base, wo is at the second :-)

Just remember to take the fifth!

-- 
Non Sine Numine
http://grimbert.cjb.net/
Etiquette is for those with no breeding;
fashion for those with no taste.

Post a reply to this message

Christoph Hormann wrote:
> 
> Le Forgeron wrote:
> >
> > Regarding the tesselation patch, the source are now available from
> > http://jgrimbert.free.fr/pov/patch/tessel/index.html
> 
> Nice, but i think the documentation could be improved

Agreed... and then english version should be made by a native (i.e. not me!)
But before investing too much in documentation, it could be better to
first settle down the keyword and syntax (as well as the options).

>, i'm not sure about
> the meaning of various parameters.

I tried to keep the same meanings across the various keyword.
Innocent people are always welcome when writing documentation, because
they come with the natural questions of any newcomers, instead of
the overly complicated explications that "experts" usually exchange (in jargon, 
of course!)
So, Congratulation, you qualify yourself for this task! 
Now, please reorganise your thoughts, and precisely asks all you want to understand.
(Sorry, but the short answer "everything/all" must be detailed and is not allowed per
se).


>  There are also differences between the
> french and english version of the description.

What difference ? The only french/english is in the first table, which only explains
the colour code (mandatory or optional parameter/keyword part).

Aren't you rather confused by the difference between the second and third columns of 
the second table ? 
In the second columns, it is the syntax for using the object/modification just
like a single object (just like you would have typed "sphere { ... }" or
"object { .... }".
In the third columns, it is the syntax for using as part as a mesh, just as 
a replacement to "triangle" or "smooth_triangle".
Main difference is that from second to third, you loose the object modifiers,
and you gain a texture identifier to apply.

Of course, the detail of each page (which is only in french) covers the full
set of options.
Now, may be there is some inconsistencies, which you are welcome to signal too !
 
> I also have a suggestion:
> 
> The 'move < coeff_of_matrix(12) >' could be replaced with a transform.

Transform: I do not know about it, it seems that megapov introduced this element
 (at least with some id), but I do not know it from 3.1g (Or it escapes me, which
is also possible!) and I did not feel from reintegrating that patch too!
(My base was 3.1g, and I'm very reluctant to additions 
[for instance, I'm against all the UV-mapping stuff, but that's another subject/holy
war])

And I mainly introduced 'move' before getting the transformation
(rotate/translate/...) on
warp
(which is a good addition, IMNSHO, even if 3.5 do it another way), so I'm not
even sure 'move' is still usefull as option of 'warp {'.
As a full transformation, 'move {' would really gain from functions, for the time
being,
I found it rather useless as not fancy deformations could be described with a simple
linear matrix.
Moreover, if there was a warp which would do that (is there already ?), there would be
really no need for any 'move' at all.

-- 
Non Sine Numine
http://grimbert.cjb.net/
Etiquette is for those with no breeding;
fashion for those with no taste.

Post a reply to this message

Le Forgeron wrote:
> 
> >, i'm not sure about
> > the meaning of various parameters.
> 
> I tried to keep the same meanings across the various keyword.
> Innocent people are always welcome when writing documentation, because
> they come with the natural questions of any newcomers, instead of
> the overly complicated explications that "experts" usually exchange (in jargon,
> of course!)
> So, Congratulation, you qualify yourself for this task!
> Now, please reorganise your thoughts, and precisely asks all you want to understand.
> (Sorry, but the short answer "everything/all" must be detailed and is not allowed
per se).

All right.  The french description isn't that bad, but my ability to read
french with that many special vocabulary is not that good... Babelfish
also does not do a very good job on it.

So i'm not sure if i qualify for judging the french explanations. ;-) I
had most problems with the parameters specific to the different
tesselation methods.

What would probably help no matter what language are picture tables
varying the parameters.  Like on:

http://www-public.tu-bs.de:8080/~y0013390/pov/rmf/frame.html

The table on the bottom of

http://jgrimbert.free.fr/pov/patch/mesh.html

is a good start (BTW 'accuracy' has a quite different meaning in
isosurfaces or normals, this could lead to some misunderstanding).

> >  There are also differences between the
> > french and english version of the description.
> 
> What difference ? The only french/english is in the first table, which only explains
> the colour code (mandatory or optional parameter/keyword part).
> 
> Aren't you rather confused by the difference between the second and third columns of
> the second table ?

Right, the mixture of french and english in the main page is somewhat
confusing.

> > I also have a suggestion:
> >
> > The 'move < coeff_of_matrix(12) >' could be replaced with a transform.
> 
> Transform: I do not know about it, it seems that megapov introduced this element
>  (at least with some id), but I do not know it from 3.1g (Or it escapes me, which
> is also possible!) and I did not feel from reintegrating that patch too!
> (My base was 3.1g, and I'm very reluctant to additions
> [for instance, I'm against all the UV-mapping stuff, but that's another subject/holy
war])

transforms are already in 3.1.

> And I mainly introduced 'move' before getting the transformation
(rotate/translate/...) on
> warp
> (which is a good addition, IMNSHO, even if 3.5 do it another way), so I'm not
> even sure 'move' is still usefull as option of 'warp {'.
> As a full transformation, 'move {' would really gain from functions, for the time
being,
> I found it rather useless as not fancy deformations could be described with a simple
> linear matrix.
> Moreover, if there was a warp which would do that (is there already ?), there would
be
> really no need for any 'move' at all.

I think custom vector functions and function warps would probably be the
best solution for all those problems, but neither is implemented in 3.5. 
Without those i think 'move' with a transform and 'warp' are sufficient
(but i would consider not using the 'warp' keyword since what's inside the
'{}' isn't a warp like in other occurrences of the keyword.

Same applies for 'select' which is a float function in 3.5.

Another suggestion: using a texture for 'modulation' does not seem a good
idea to me.  A pattern or a function (in 3.5) would be better probably.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 30 Jun. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

Le Forgeron wrote:
> 
> Regarding the tesselation patch, the source are now available from
> http://jgrimbert.free.fr/pov/patch/tessel/index.html
> 

I had a look at the source and you don't seem to use preprocessor
conditionals for your changes.  This would be very helpful for the user,
especially in this case when you have several patches combined.

BTW, what is the 'nexus' object?

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 30 Jun. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

Le Forgeron scribis news:3D2855C5.56681427@free.fr:

> Just remember to take the fifth!
> 
> 

Well, I homebrew a little bit, maybe I'll drink a fifth instead..

-- 
Gis poste, Arto.

Post a reply to this message

Christoph Hormann wrote:
> 
> Le Forgeron wrote:
> >
> > Regarding the tesselation patch, the source are now available from
> > http://jgrimbert.free.fr/pov/patch/tessel/index.html
> >
> 
> I had a look at the source and you don't seem to use preprocessor
> conditionals for your changes.  This would be very helpful for the user,
> especially in this case when you have several patches combined.

I know... my first patchs were at least tagged with some comments...
alas, for the tesselation patch, I started with the source from Warp,
and totally forget to insert a minimal comment whenever a line was updated/added
in existing files. 
And this patch took so much time to experiment/debug/write that in the meantime
I made also some additional patches (unrelated), which means that I have no
clean image to invoke diff/patch from. It also extend a bit further than usual,
at least I had to introduce the triangle interpolation and the warp transformation,
while disregarding the transfer of texture list higher in the mesh structures.
(I have been explained why it was done in megapov, and I believe it is not
the correct solution to the problem, a second transformation matrix when
a mesh is duplicated should have been enough with enough care done for the
texture computation; at least, it would have been less memory intensive than
the megapov duplication of the texture)

> 
> BTW, what is the 'nexus' object?

It once started as a strange CSG like, limited to a container and a
containee. Whenever a ray it the container, another ray was launch 
against the containee from the intersection according to the normal at
the intersection. The intersection would have been kept only if the 
containee was hit. It was a trial for a strange idea (which turn out
bogus). 
Nexus is knot in latin.
Later, I reused the keyword to make a patch from an idea of JRG
(see "Merry Christmas to JRG", in p.b.i, 25 December 2001).
So like it is currently, a nexus is an object which return intersection
only when the ray and the normal of the surface are going the same way.
(kind of you only see the interior, whatever the view point, including 
via reflection !)
Only pathological use is probably easing architectural cut of a house,
assuming the external walls are a nexus, when performing a rotation around
that house... 
-- 
Non Sine Numine
http://grimbert.cjb.net/
Etiquette is for those with no breeding;
fashion for those with no taste.

Post a reply to this message

Christoph Hormann wrote:
> 
> Le Forgeron wrote:
> >
> > >, i'm not sure about
> > > the meaning of various parameters.
> >
> > I tried to keep the same meanings across the various keyword.
> > Innocent people are always welcome when writing documentation, because
> > they come with the natural questions of any newcomers, instead of
> > the overly complicated explications that "experts" usually exchange (in jargon,
> > of course!)
> > So, Congratulation, you qualify yourself for this task!
> > Now, please reorganise your thoughts, and precisely asks all you want to
understand.
> > (Sorry, but the short answer "everything/all" must be detailed and is not allowed
per se).
> 
> All right.  The french description isn't that bad, but my ability to read
> french with that many special vocabulary is not that good... Babelfish
> also does not do a very good job on it.

At least you can imagine my problem with the reversal, finding the right
english term for the special vocabulary is not easy either.
> 
> So i'm not sure if i qualify for judging the french explanations. ;-) I
> had most problems with the parameters specific to the different
> tesselation methods.
> 
> What would probably help no matter what language are picture tables
> varying the parameters.  Like on:
> 
> http://www-public.tu-bs.de:8080/~y0013390/pov/rmf/frame.html
> 
> The table on the bottom of
> 
> http://jgrimbert.free.fr/pov/patch/mesh.html
> 

Ouch! Now that one need to be updated or removed (keeping the picture,
pushing them in "Tesselation Patch" sub-section), because
the syntax is really out of date (and mostly wrong).

> is a good start (BTW 'accuracy' has a quite different meaning in
> isosurfaces or normals, this could lead to some misunderstanding).
> 

Put the blame on Warp, for that keyword it was like that in the original patch!
;-) na ni na na na...
Suggestion of alternative (more precise and relevant) keyword are very welcome.


> > >  There are also differences between the
> > > french and english version of the description.
> >
> > What difference ? The only french/english is in the first table, which only
explains
> > the colour code (mandatory or optional parameter/keyword part).
> >
> > Aren't you rather confused by the difference between the second and third columns
of
> > the second table ?
> 
> Right, the mixture of french and english in the main page is somewhat
> confusing.
> 
> > > I also have a suggestion:
> > >
> > > The 'move < coeff_of_matrix(12) >' could be replaced with a transform.
> >
> > Transform: I do not know about it, it seems that megapov introduced this element
> >  (at least with some id), but I do not know it from 3.1g (Or it escapes me, which
> > is also possible!) and I did not feel from reintegrating that patch too!
> > (My base was 3.1g, and I'm very reluctant to additions
> > [for instance, I'm against all the UV-mapping stuff, but that's another
subject/holy war])
> 
> transforms are already in 3.1.
> 

Yes, after checking the help file, it looks so.
But it seems that megapov had some more patch on this aspect, and 
I was relunctant to get too much code from it... 

> > And I mainly introduced 'move' before getting the transformation
(rotate/translate/...) on
> > warp
> > (which is a good addition, IMNSHO, even if 3.5 do it another way), so I'm not
> > even sure 'move' is still usefull as option of 'warp {'.
> > As a full transformation, 'move {' would really gain from functions, for the time
being,
> > I found it rather useless as not fancy deformations could be described with a
simple
> > linear matrix.
> > Moreover, if there was a warp which would do that (is there already ?), there
would be
> > really no need for any 'move' at all.
> 
> I think custom vector functions and function warps would probably be the
> best solution for all those problems, but neither is implemented in 3.5.

Well, it should not be too difficult once the functions evaluation code exists.
And then the 'move' could probably removed (because only one way to do a thing
is a good thing, two ways is often too much complication! [unless you end up
with a universal uniq command with a thousand switch/parameters, which is bad also:-])

> Without those i think 'move' with a transform and 'warp' are sufficient
> (but i would consider not using the 'warp' keyword since what's inside the
> '{}' isn't a warp like in other occurrences of the keyword.

Agreed, "warp" (mesh object) is currently a bad thing because inside it there is
another
real "warp" which might add confusion and a wrong idea of recursivity.

> 
> Same applies for 'select' which is a float function in 3.5.

Not guilty.

:->
I agree that with 3.5 it will be another bad choice, but at least
"select" with mesh does just what the dictionary says: it selects (and kept/copy)
part of a mesh.


> 
> Another suggestion: using a texture for 'modulation' does not seem a good
> idea to me.  A pattern or a function (in 3.5) would be better probably.

Function : yes, but I do not have the code for that!

Pattern: put it in a texture and use a [0 Black][1 White] pigment/color map; so
I do not see the need for just a pattern.

Evolution should probably allow the choice between a function and a texture.
(Texture is better than pattern, because of layered textures which allow
to combine two or more patterns and make nearly all you could dreams of).
I'm just sad that the finish part of the texture is wasted.

When functions would be available, it will mean that modulation will have
to be splitted in subcase (yet more keywords to find... 
I'm already against f_modulation and t_modulation [or whatever similar silly
refinement])

Suggestion of better keywords are always welcome.
(Better: clearer for the newbies.)



-- 
Non Sine Numine
http://grimbert.cjb.net/
Etiquette is for those with no breeding;
fashion for those with no taste.

Post a reply to this message