 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
There seem to be a problem with the Supercone object from shapes.inc. The z
component of the input vectors are not handled correctly somehow.
#include "shapes.inc"
camera {location 5*x look_at 0}
background {color <0.4,0.8,1.0>}
light_source {<3,2,1>*1000, color 1}
object{
Supercone(0, 2.0,1.0, -z, 1.5,0.5)
// plus and minus ^ give equal result!
pigment {color rgb 1}
}
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Perhaps it could be better to define the supercone so that it just takes
the for radiuses and a height, and then it would create the object centered
in the origin and along the y-axis (so that one end is at the origin and
the other is at y*height). The user can then transform it with the
transformation macros from other includes.
Would this be a good idea?
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" wrote:
> Perhaps it could be better to define the supercone so
> that it just takes the for radiuses and a height, and
> then it would create the object centered in the origin
> and along the y-axis (so that one end is at the origin
> and the other is at y*height). The user can then
> transform it with the transformation macros from other
> includes. Would this be a good idea?
I really don't think so. I've been using the macro a bit, and the things
I've used it for would sure be much more clumsy and complicated if I had to
align it manually. No feature change thank you, just the bug fix! ;)
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rune <run### [at] mobilixnet dk> wrote:
: I really don't think so. I've been using the macro a bit, and the things
: I've used it for would sure be much more clumsy and complicated if I had to
: align it manually. No feature change thank you, just the bug fix! ;)
The real problem with the current implementation is that you can't control
how the cone is rotated around its longitudinal axis when it is rotated to
the correct position. IIRC the matrix transformation I used there (which was
got from the matrix page) rotates the cone in unwanted ways when it reorients
it.
I don't know what does the standard Reorient_Trans() macro do, but perhaps
I'll use that in the supercone, if not anything else, for modularity.
The idea in my suggestion was that the user himself could use the
Reorient_Trans() macro to orient the cone...
I have to look at this.
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
: I don't know what does the standard Reorient_Trans() macro do, but perhaps
: I'll use that in the supercone, if not anything else, for modularity.
Oops! With your example I get the error:
#error "error in Reorient_Trans macro: Axis1 may not be exact opposite of Axis2"
Why?
Shouldn't there be a code that just rotates or scales the object
accordingly in this case?
(By the way, the behaviour of the #error command should be better: It
should just print the error message (not the line where it is) and then
stop. Also I don't think that POV-Ray needs to open the file where the
#error was called.)
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ok, here is a fix I like. It uses the Reorient_Trans() macro which seems
to reorient it in a logical way (ie the cone doesn't rotate oddly). It
requires an #include "transforms.inc" in shapes.inc, but that's shouldn't be
a problem.
#macro Supercone(PtA, A, B, PtB, C, D)
intersection {
quartic {
<0, 0, 0, 0, 0, 0, 0, B*B-2*B*D+D*D, 2*(B*D-B*B), B*B,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, A*A-2*A*C+C*C, 2*(A*C-A*A), A*A, 0, 0, 0, 0,
-(A*A-2*A*C+C*C)*(B*B-2*B*D+D*D),
-(2*((B*D-B*B)*(A*A-2*A*C+C*C)+(A*C-A*A)*(B*B-2*B*D+D*D))),
-(B*B*(A*A-2*A*C+C*C)+4*(A*C-A*A)*(B*D-B*B)+A*A*(B*B-2*B*D+D*D)),
-(2*(B*B*(A*C-A*A)+A*A*(B*D-B*B))), -A*A*B*B>
sturm
}
cylinder {0, z, max(max(abs(A), abs(B)), max(abs(C), abs(D)))}
bounded_by {cone {0, max(abs(A), abs(B)), z, max(abs(C), abs(D))}}
#local Dirv = PtB - PtA;
scale <1,1,vlength(Dirv)>
#local Dirv = vnormalize(Dirv);
#if(vlength(Dirv-<0,0,-1>)=0) scale <1,1,-1>
#else Reorient_Trans(z, Dirv)
#end
}
#end
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Oops! Forgot the translate at the end:
#macro Supercone(PtA, A, B, PtB, C, D)
intersection {
quartic {
<0, 0, 0, 0, 0, 0, 0, B*B-2*B*D+D*D, 2*(B*D-B*B), B*B,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, A*A-2*A*C+C*C, 2*(A*C-A*A), A*A, 0, 0, 0, 0,
-(A*A-2*A*C+C*C)*(B*B-2*B*D+D*D),
-(2*((B*D-B*B)*(A*A-2*A*C+C*C)+(A*C-A*A)*(B*B-2*B*D+D*D))),
-(B*B*(A*A-2*A*C+C*C)+4*(A*C-A*A)*(B*D-B*B)+A*A*(B*B-2*B*D+D*D)),
-(2*(B*B*(A*C-A*A)+A*A*(B*D-B*B))), -A*A*B*B>
sturm
}
cylinder {0, z, max(max(abs(A), abs(B)), max(abs(C), abs(D)))}
bounded_by {cone {0, max(abs(A), abs(B)), z, max(abs(C), abs(D))}}
#local Dirv = PtB - PtA;
scale <1,1,vlength(Dirv)>
#local Dirv = vnormalize(Dirv);
#if(vlength(Dirv-<0,0,-1>)=0) scale <1,1,-1>
#else Reorient_Trans(z, Dirv)
#end
translate PtA
}
#end
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thanks Warp, I'll use this one.
The reason that the Reorient macro can't reorient when Axis1 is the opposite
of Axis2 is that it doesn't have enough information to align it. To mirror
the shape is not a acceptable solution because then it's not the same shape
anymore (except in some cases). The right solution would be to rotate the
object 180 degrees, but the macro can't know around which axis, and I don't
like to take a random approach to the problem.
The way you've solved it is right, because the mirroring is not a problem in
this case.
You're right about the way POV-Ray handles errors; I too have always found
it very strange. It doesn't even print the string after the error, so you
can't use a predefined string as you should be able to. I guess this is a
bug, I've just not thought about reporting it before.
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
