|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jellby <jel### [at] m-softhomenet> wrote:
> Something vaguely related that came to my mind: Is it possible with the
> current tools to define a sort of hybrid between a lathe and a prism? I
> mean: in a prism you specify the section with a spline, in a lathe you
> specify the generatrix (is that the word?) with a spline, what about
> specifying both? In case it isn't possible (as I guess), wouldn't it be
> cool to have this kind of objects (lathes with non-circular section /
> prisms with non-linear sweeps)? Just an idea, though.
It shouldn't be too difficult to make a macro which creates that kind
of surface as a mesh using the two splines. (It would probably render 10
times faster as a mesh, as well.)
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:3d87a619@news.povray.org Jellby wrote:
> Is it possible with the
> current tools to define a sort of hybrid between a lathe and a prism?
http://www.econym.demon.co.uk/isotut/splines.htm
prismatic lathe
Ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Greg M. Johnson" <gregj:-)565### [at] aolcom> skrev i melding
news:3d8771ed$1@news.povray.org...
> I read the docs but thought someone had a utility that make "visible"
> splines.
>
As ABX said, the spline itself is just a set of points. See the docs
[6.1.9] - "Spline Identifiers" for a better description..
If I understand your question right you want to make a spline "visible",
(show it's path). Then you just have to place objects along it with a #while
loop.
Something like this:
camera {
location z*-5 look_at 0
}
light_source {z*-15 1}
#declare My_Spline =
spline{
natural_spline
-1,< 1.5, 0,0>,// control point
0,< 1, 1,0>,
1,<-1, 1,0>,
2,<-1,-1,0>
3,< 1,-1,0>,
4,< 1, 0,0>,
5,< 0, 0,0>,
6,<-1, 0,0>// control point
}
#local Q = 0; // shows smoothed path
#while (Q < 5)
sphere {My_Spline(Q),0.1 pigment {rgb 1}}
#local Q = Q+0.1;// decrease to make smoother
#end
#local Q = -2;// shows spline points (control points too)
#while (Q < 7)
sphere {My_Spline(Q),0.15 pigment {rgb <1,0,0>}}
#local Q = Q+1;
#end
I reccomend docs [3.4.1.1] "Understanding The Concept of Splines", if you
haven't read it already!
Good luck!
-Peter
http://hertel.no/peter
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:3d87ea2f@news.povray.org...
>
> It shouldn't be too difficult to make a macro which creates that kind
> of surface as a mesh using the two splines. (It would probably render 10
> times faster as a mesh, as well.)
>
Thanks for the idea!
In order to be 10 times faster, would you have to "store" the coordinates
of the mesh first as an INC or would I lose speed if it were "calculated"
anew for each frame of an animation?
The application is that I want to make a railroad. I want to make the
rails, and want to identify the path of the rails with a spline. The
question then is what to make it out of: a sphere sweep seems
impractically slow in parsing/rendering, especially if it's "big".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ingo wrote:
> in news:3d87a619@news.povray.org Jellby wrote:
>
>> Is it possible with the
>> current tools to define a sort of hybrid between a lathe and a prism?
>
> http://www.econym.demon.co.uk/isotut/splines.htm
> prismatic lathe
>
> Ingo
Yeah, I should have thought of isosurfaces :) However, would an optimised
implementation be possible? Would anyone find it useful?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3d8881d6@news.povray.org>,
Jellby <jel### [at] M-softhomenet> wrote:
> Yeah, I should have thought of isosurfaces :) However, would an optimised
> implementation be possible? Would anyone find it useful?
You could do it with meshes.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Greg M. Johnson <gregj:-)565### [at] aolcom> wrote:
> In order to be 10 times faster, would you have to "store" the coordinates
> of the mesh first as an INC or would I lose speed if it were "calculated"
> anew for each frame of an animation?
I'm talking about render time, not parse time.
If you need to create the mesh for each frame separately (eg. because it
changes shape) then parsing can be slowish. However, if you need to create
it just once, then saving it in a file in mesh2 format should make parsing
quite fast as well.
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:3d888ca4@news.povray.org...
> However, if you need to create it just once, then saving it in a
> file in mesh2 format should make parsing quite fast as well.
>
I understand the benefit of "removing all duplicate vertices " as mentioned
in 3.5.2 Mesh2 Object.
Q: If I'm making something complex ( for my brain at least), is there still
a huge render/parse benefit from using an UNoptimized mesh2 over anything
else??
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Greg M. Johnson <gregj:-)565### [at] aolcom> wrote in message
news:3d88a54e$1@news.povray.org...
>
> I understand the benefit of "removing all duplicate vertices " as
mentioned
> in 3.5.2 Mesh2 Object.
>
> Q: If I'm making something complex ( for my brain at least), is there
still
> a huge render/parse benefit from using an UNoptimized mesh2 over anything
> else??
>
There is a considerable benefit over csg and some small benefit over
mesh(one). I'm not sure what you mean by an UNoptomized mesh2, but in order
to find vertex normals for your mesh(one) you will need to identify the
duplicate vertices anyway, so I cannot see any reason to use mesh(one) in
your final scene.
-Shay
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Slime <slm### [at] slimelandcom> wrote:
> Unfortunately, POV-Ray has no way to apply a separarely defined spline to a
> sphere_sweep object. Nor can it apply a separate spline to a prism object or
> something of that sort. I think this is a weakness in POV-Ray - it has the
> same data structure represented in different ways depending on what you're
> using it for.
>
> I understand that the data structures aren't *identical*, but they're darn
> similar and would be much more powerful if they were more portable.
I agree that this would be a handy feature. However, if I remember
correctly, there were no splines in POV-Ray 3.1 on which I based the
sphere_sweep stuff on, so I had to "build my own". Makes for a good
excuse, eh? ;)
However, I think it could be done now, with a bit of rework of the
sphere_sweep syntax. Just let the sphere_sweep take a four-dimensional
spline as input data. I'm not volunteering to do this in the foreseeable
future, though, just in case. ;)
Jochen Lippert
--
No smilies were harmed in the making of this message ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|