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

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


	Could you possibly develop that point further ? This duplication
of the mesh textures is a real problem for huge texture lists. It's actually
the only reason why I don't use megapov, and why I will have to patch
POV-Ray 3.5 as I did for 3.1g.
	So, if you know of a better solution involving a second matrix,
I'd like to see it  :o)

Post a reply to this message

Nicolas Calimet wrote:
> 
> > (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)
> 
>         Could you possibly develop that point further ? This duplication
> of the mesh textures is a real problem for huge texture lists. It's actually
> the only reason why I don't use megapov, and why I will have to patch
> POV-Ray 3.5 as I did for 3.1g.
>         So, if you know of a better solution involving a second matrix,
> I'd like to see it  :o)

I have no tested solution (i.e. no code), but from what I understood from
the explanation given on this server (See this group, answer from Nathan Kopp
dated 23 February 2002 to "Question regarding MegaPov").

There is potentially two different times (that I can think of, maybe
I missed some other and therefore my solution might then be bogus) when
an additional transformation (translate,rotate, scale, whatever) is applied
to an existing mesh with a collection of texture.
1. During the original declaration of the mesh (i.e. the mesh parsing is not
yet finished), and I believe the 3.1g handled this case well.
2. Whenever a mesh is reused (via its identifier) and then an additional
transformation
is performed. Traditionnal handling of this is to copy the object and update the
transform
matrix attached to the copy. This is where the 3.1g had problem with texture handling
in
mesh.

To sum up: an object has a transformation matrix and every texture has also a matrix.
First an object is created and get a matrix A (transformation before texture).
Then texture is applied and texture has its own matrix T.
Object is then transformed again and a new matrix B is used (transformation after
texture).
This later stage can be repeated with a new matrix Ci whenver an identifier is used.

Usually, A & B are combined in a single matrix (object level), 
while T & B are combined in a matrix (at texture level). (this is happening at parse
time!)

So far so good, but when adding Ci, the traditional approach with objects (not mesh)
is to
get a copy and then combined Ci at the object level (no problem with mesh, the top
level
is also
a copy which can be updated) as well as at the texture level (here mesh have a
problem,
because 
it is not allowed to update the data structure regarding the textures [in 3.1g, it's
not a
copy,
it's a reference to the first data]).

Instead of trying to combined the texture matrix with Ci, it could be possible to
store Ci
as 
a new matrix at the object level, because texture evaluation code for mesh is already
so
special,
it could as well apply an additional transform when evaluating the texture. It's
trading
memory
for speed but I believe that the real interest of mesh is really memory and the
additional
cost
to correct the initial bug is only paid when the mesh is hit, which I believe is a
small
price.

So: When parsing the initial mesh, the same behavior as 3.1g is kept;
When adding transformation to a copy of a mesh, the textures do not have to be copied,
but instead another matrix must also be updated at the object level of the mesh
structure,
which will be used by the texture evaluation code of the mesh. Of course the default
value
for this additional matrix should be Identity.

Allow me an analogy: transformation of textures in mesh are like a list of integers.
When you apply an additional transformation, you are adding a value to each integer of
the
list.
Rather than copying the list for each copy of the list that have a different (or
identical, you cannot
know) transform, it is simpler to keep a single list with various offset (one for each
copy).
It's trading memory for speed, because now each time you access a copy, you have to
perform
a calculation using the offset, but you have avoided to copy the whole list.

What is bigger: a transformation matrix or a texture list ?
I guess you know the answer...
-- 
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