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