|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi everyone,
I'm trying to make my own sphere_sweep using triangles. I'm aligning the
points to a spline with Point_At_Trans. Terrible artifacts appear, and I
can't rid myself of them. You can see the image at p.b-images for an
example of my problem.
// code
#declare sp=spline{
natural_spline
-0.5, <0,-1,2>,
0.0, <-1,-1,1.5>,
0.25, <-1,0,1>,
0.5, <0,.75,0>,
0.75, <1,0,-1>,
1.0, <1,-1,-1.5>,
1.5, <0,-1,-2>
}
#declare incre = 1/20;
#declare rv = 360/12;
union{
#declare V=0;
#while(V<1-incre)
#declare R=0;
#while(R<360)
#declare p1=vrotate(<.3,0,0>,y*(R-rv/2));
#declare p2=vrotate(<.3,0,0>,y*(R+rv/2));
#declare p3=vrotate(<.3,0,0>,y*(R-rv/2));
#declare p4=vrotate(<.3,0,0>,y*(R+rv/2));
#declare pp1=( sp(V-incre/2)-sp(V+incre/2) );
#declare pp2=( sp(V+incre/2)-sp(V+incre*1.5) );
#declare p1=vtransform(p1,transform{ Point_At_Trans( sp(V-incre/2)-
sp(V+incre/2) ) translate sp(V)});
#declare p2=vtransform(p2,transform{ Point_At_Trans( sp(V-incre/2)-
sp(V+incre/2) ) translate sp(V)});
#declare p3=vtransform(p3,transform{ Point_At_Trans( sp(V+incre/2)-
sp(V+incre*1.5) ) translate sp(V+incre)});
#declare p4=vtransform(p4,transform{ Point_At_Trans( sp(V+incre/2)-
sp(V+incre*1.5) ) translate sp(V+incre)});
triangle{p1,p2,p3}
triangle{p2,p3,p4}
#declare R=R+rv;
#end
#declare V=V+incre;
#end
pigment{rgb<0,.5,.25> }
finish{specular 1 roughness .0125 reflection{0,1 falloff 3}}
}
// end code
As you can see, I'm using vtransform to kind of "cheat" my way to
rotating radially-placed points along the spline. How can I get rid of
the twists?
Sam
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Okay, I think I may have arrived at a resolution to my little problem. I
swapped Point_At_Trans for Reorient_Trans inside the vtransform
statements. I thought they were essentially the same thing, but no,
Reorient_Trans produces a better result. It seems I can tweak the heck
out of my spline without getting the twists. Yay!
// the updated code (requires POV-Ray with subdivision)
#declare sp=spline{
natural_spline
-0.5, <0,-1,2>,
0.0, <-1,-1,1.5>,
0.25, <-1,0,1>,
0.5, <0,.75,0>,
0.75, <1,0,-1>,
1.0, <1,-1,-1.5>,
1.5, <0,-1,-2>
}
#declare incre = 1/10;
#declare rv = 360/6;
mesh{
#declare V=0;
#while(V<1-incre)
#declare R=0;
#while(R<360)
#declare p1=vrotate(<.5-V*.499,0,0>,y*(R-rv/2));
#declare p2=vrotate(<.5-V*.499,0,0>,y*(R+rv/2));
#declare p3=vrotate(<.5-(V+incre)*.499,0,0>,y*(R-rv/2));
#declare p4=vrotate(<.5-(V+incre)*.499,0,0>,y*(R+rv/2));
#declare pp1=( sp(V-incre/2) - sp(V+incre/2) );
#declare pp2=( sp(V+incre/2) - sp(V+incre*1.5) );
#declare p1=
vtransform(p1,transform{ Reorient_Trans(y, pp1 )
translate sp(V)}
);
#declare p2=
vtransform(p2,transform{ Reorient_Trans(y, pp1 )
translate sp(V)}
);
#declare p3=
vtransform(p3,transform{ Reorient_Trans(y, pp2 )
translate sp(V+incre)}
);
#declare p4=
vtransform(p4,transform{ Reorient_Trans(y, pp2 )
translate sp(V+incre)}
);
triangle{p1,p2,p3}
triangle{p2,p3,p4}
#declare R=R+rv;
#end
#declare V=V+incre;
#end
subdivision{substeps 3}
pigment{rgb<0,.5,.25> }
finish{specular 1 roughness .0125 reflection{0,1 falloff 3}}
}
// end code
Now I can cap the ends and adjust the thickness with another spline.
Should I release it when I'm finished? It wouldn't support smoothing
unless you used POV-Sub...
Sam
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I had the same problem with SweepSpline.inc and never did find a general
solution. In most cases either SweepSpline.inc or SweepSplineV2.inc will
produce a twistless rendering, but there's no guarantee.
In your particular case, SweepSplineV2 produces a better result.
SweepSpline, and Ingo Janssen's makemesh.inc (which it uses) are in this
zip file:
http://www.econym.demon.co.uk/isotut/more35.zip
--
Mike Williams
Gentleman of Leisure
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Both Point_At_Trans and Reorient_Trans are ill fitted to this task. They
don't look at the context and it can be matematically proven that there will
always exist some bend that will create a severe twist, using either macro.
Instead, each iteration along the spline must look at the orientation of the
previous iteration and make the aligment in the new iteration as close as
possible to the previous one. Only this way can you be sure that you'll
never get any ugly twists. Have a look at the code below.
#declare sp=spline{
natural_spline
-0.5, <0,-1,2>,
0.0, <-1,-1,1.5>,
0.25, <-1,0,1>,
0.5, <0,.75,0>,
0.75, <1,0,-1>,
1.0, <1,-1,-1.5>,
1.5, <0,-1,-2>
}
#declare incre = 1/20;
#declare rv = 360/12;
#declare Tang = sp(-incre/2)-sp(incre/2);
#declare Norm = VPerp_Adjust(x,Tang);
union{
#declare V=0;
#while(V<1-incre)
#declare R=0;
#declare TangNew = sp(V+incre/2)-sp(V+incre+incre/2);
#declare NormNew = VPerp_Adjust(Norm,TangNew);
#while(R<360)
#declare p1 = vaxis_rotate(Norm*0.3,Tang,(R-rv/2))+sp(V);
#declare p2 = vaxis_rotate(Norm*0.3,Tang,(R+rv/2))+sp(V);
#declare p3 = vaxis_rotate(NormNew*0.3,TangNew,(R-rv/2))+sp(V+incre);
#declare p4 = vaxis_rotate(NormNew*0.3,TangNew,(R+rv/2))+sp(V+incre);
triangle{p1,p2,p3}
triangle{p2,p3,p4}
#declare R=R+rv;
#end
#declare Tang = TangNew;
#declare Norm = NormNew;
#declare V = V+incre;
#end
pigment{rgb<0,.5,.25> }
finish{ambient 0.5 specular 1 roughness .0125 reflection{0,1 falloff 3}}
}
Rune
--
http://runevision.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Oops, remember to #include "math.inc"
Rune
--
http://runevision.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rune wrote:
> Both Point_At_Trans and Reorient_Trans are ill fitted to this task. They
> don't look at the context and it can be matematically proven that there will
> always exist some bend that will create a severe twist, using either macro.
Yeah, I discovered that after removing the subdivision :(
> Instead, each iteration along the spline must look at the orientation of the
> previous iteration and make the aligment in the new iteration as close as
> possible to the previous one. Only this way can you be sure that you'll
> never get any ugly twists. Have a look at the code below.
You know, the idea of having values based on previous ones was one of my
ideas last night, but I had no_idea how to implement it.... I began to
think maybe it wasn't the solution, but your code works beautifully! I'm
going to study it later on, and I might even try to implement uv_mapping
when I have the chance. Finding the normals for smooth_triangles, well,
that's another thing :(
Sam
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Williams wrote:
> I had the same problem with SweepSpline.inc and never did find a general
> solution. In most cases either SweepSpline.inc or SweepSplineV2.inc will
> produce a twistless rendering, but there's no guarantee.
>
> In your particular case, SweepSplineV2 produces a better result.
>
> SweepSpline, and Ingo Janssen's makemesh.inc (which it uses) are in this
> zip file:
Thanks Mike! Looks like there's a bonus in there. I didn't know you
could wrap a function around a spline like that!
How come, after searching and searching for a mesh-based sphere_sweep, I
never found these files? Oh well :) It has been fun making my own
version. Plus, if I want to implement something extra into it, I can.
Sam
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Samuel Benge <stb### [at] THIShotmailcom> wrote:
> Rune wrote:
> > Both Point_At_Trans and Reorient_Trans are ill fitted to this task. They
> > don't look at the context and it can be matematically proven that there will
> > always exist some bend that will create a severe twist, using either macro.
>
> Yeah, I discovered that after removing the subdivision :(
>
> > Instead, each iteration along the spline must look at the orientation of the
> > previous iteration and make the aligment in the new iteration as close as
> > possible to the previous one. Only this way can you be sure that you'll
> > never get any ugly twists. Have a look at the code below.
>
> You know, the idea of having values based on previous ones was one of my
> ideas last night, but I had no_idea how to implement it.... I began to
> think maybe it wasn't the solution, but your code works beautifully! I'm
> going to study it later on, and I might even try to implement uv_mapping
> when I have the chance. Finding the normals for smooth_triangles, well,
> that's another thing :(
>
> Sam
For smoothing normals, create 2 vectors - one from -1 u vertex to +1 u
vertex and one from -1 to +1 v vertex, then use the cross product (i.e.,
perpendicular vector), just make sure you get it to point "out". I used
something similar for a mobius mesh generateing macro and it seemed to work
fine.
-tgq
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Samuel Benge wrote:
> You know, the idea of having values based on previous ones was one of
> my ideas last night, but I had no_idea how to implement it.... I
> began to think maybe it wasn't the solution, but your code works
> beautifully! I'm going to study it later on, and I might even try to
> implement uv_mapping when I have the chance. Finding the normals for
> smooth_triangles, well, that's another thing :(
I have a macro I used for the vines in my Metal & Flowers image which
supports UV mapping, UV deformation of the mesh, smooth normals, writing the
mesh to a file, variable radius and other things. I can post in a few days
it after cleaning it up. It's based on the code from the HF-macros in
shapes.inc that comes with POV-Ray 3.5+.
Rune
--
http://runevision.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|