|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In Parse_Cylinder in parse.cpp
Parse_Vector(Object->apex); Parse_Comma ();
Parse_Vector(Object->base); Parse_Comma ();
should be?
Parse_Vector(Object->base); Parse_Comma ();
Parse_Vector(Object->apex); Parse_Comma ();
or does the intersection code require this?
It just seems logical that the base of a cylinder from the SDL should be
stored in a variable called base. Of course mathematically it probably
makes little difference. There is similar problem in Parse_Cone.
How have other ppl satisfied the POV licence wrt not enabling new
features unless #version unofficial is in the file?
My matrix math is a little rusty, so can anyone tell if MTransNormal
alters the length of a normal eg through a scale/translate/skew
transform?
This one for someone who is familiar with the hf code: how do I get the
height and normal (possibly smoothed) at a particular **noninteger** x,
z position? Yes I'm stupid.
Bye,
Pabs
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ooops forgot to ask how to interpolate a prism/lathe/sor spline using a
value in the range 0...1?
I know about Get_Spline_Val, but I think that is only for the spline
functions from the SDL.
Bye,
Pabs
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3D9A9B12.70DC2D1E@nospam_zip.to>,
Pabs <pab### [at] nospam_zipto> wrote:
> It just seems logical that the base of a cylinder from the SDL should be
> stored in a variable called base. Of course mathematically it probably
> makes little difference. There is similar problem in Parse_Cone.
It makes no difference, but I am surprised...it would seem more
"natural" to specify the base first.
> How have other ppl satisfied the POV licence wrt not enabling new
> features unless #version unofficial is in the file?
>
> My matrix math is a little rusty, so can anyone tell if MTransNormal
> alters the length of a normal eg through a scale/translate/skew
> transform?
I would say "yes". If MTransNormal were used several times on a normal,
all but the last normalization would be redundant and wasteful of CPU.
And I don't remember seeing a normalization in the code. The act of
transforming a normal can change its length, scaling and probably
shearing will do so. Translation has no effect on normals.
> This one for someone who is familiar with the hf code: how do I get the
> height and normal (possibly smoothed) at a particular **noninteger** x,
> z position? Yes I'm stupid.
Hmm...can't really help there, but I'd look at intersect_pixel(). There
could be a better way to do what you want, more information would help.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thanks for the tips Chris
Bye,
Pabs
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |