I remember seeing splines as objects, perhaps in Chris Colefax's include
file.  It's not just a means of decribing points but an "object."

What kind of pov primitive is that: sphere sweep,  bicubic, etc.

Post a reply to this message

On Tue, 17 Sep 2002 13:53:47 -0400, "Greg M. Johnson" <gregj:-)565### [at] aolcom>
wrote:
> What kind of pov primitive is that: sphere sweep,  bicubic, etc.

Spline is in general vector function (in POV 2D-5D). It's equations base on
set of points. Just like you have function based primitives you can spline
based primitives. There is whole chapter about it in documentation.

ABX

Post a reply to this message

I read the docs but thought someone had a utility that make "visible"
splines.

Post a reply to this message

On Tue, 17 Sep 2002 14:17:29 -0400, "Greg M. Johnson" <gregj:-)565### [at] aolcom>
wrote:
> I read the docs but thought someone had a utility that make "visible"
> splines.

There is no "visible" spline. There are only spline based objects. Examples of
splines "visible" this way are in sample docs. You have to precise what you
want to make visible.

ABX

Post a reply to this message

Has anyone else looked at Chris Colefax's spline include file?
http://www.geocities.com/ccolefax/spline/index.html

Is his
    preview_spline (MySpline, default_options)
simply a sphere sweep?

Post a reply to this message

> Is his
>     preview_spline (MySpline, default_options)
> simply a sphere sweep?

Don't confuse Chris Colefax's spline include file with POV-Ray 3.5 splines.
The include file was written well before splines were brought into POV-Ray,
so it doesn't make any use of them at all.

The preview_spline macro does not use sphere sweeps, though it may simulate
them. If you want the 3.5 equivalent of that macro, then use a sphere_sweep.

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.

 - Slime
[ http://www.slimeland.com/ ]

Post a reply to this message

Slime wrote:

> <snip>
> 
> 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.

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.

Greetings

Post a reply to this message

"Jellby" <jel### [at] M-softhomenet> wrote in message
news:3d87a619@news.povray.org...

> 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.
>

I've used this before in Imagine 2 on the amiga (where is was called
'Forms') and I think it will have to become my new project while I wait for
inspiration on the current IRTC topic

jim

Post a reply to this message

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

thanks for everyone's help.

I now have code that builds my railway with mesh2 based on any given spline.
Is there a spline visualizer scene file already out there based on mesh2:  I
could tweak mine to do this if it were a benefit to the community .    8o{|

Post a reply to this message

Greg M. Johnson <gregj:-)565### [at] aolcom> wrote:
> 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??

  If you are going to use duplicated (or triplicated/quadruplicated/whatever)
points, better use the regular mesh (as it internally joins duplicates into
one, thus saving memory).

-- 
#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

Warp <war### [at] tagpovrayorg> wrote in message news:3d88eaa4@news.povray.org...
>
>   If you are going to use duplicated (or
triplicated/quadruplicated/whatever)
> points, better use the regular mesh (as it internally joins duplicates
into
> one, thus saving memory).
>

Does this use less memory than joining them yourself into a mesh2
vertex_vector list? If so I have some recoding to do.

 -Shay

Post a reply to this message

Greg M. Johnson <gregj:-)565### [at] aolcom> wrote in message
news:3d88dc96$1@news.povray.org...
>
> Is there a spline visualizer scene file already out there based on mesh2:
I
> could tweak mine to do this if it were a benefit to the community .
8o{|
>

I don't see any benefit for visualizing splines. It's too easy to do this
with a #while loop. Your code could be modified into an extrusion macro,
however. I think that many would find use in that.

 -Shay

Post a reply to this message

>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.

This could be used to make the tubing for a neon sign. Use the spline once
for the outer part of the tube, then again with smaller radius for the
inner part. Perhaps this could be done with a loop inside the sphere_sweep
object. Then use csg to make the hollow tube.

Rohan _e_ii

Post a reply to this message

Shay <sah### [at] simcopartscom> wrote:
> Does this use less memory than joining them yourself into a mesh2
> vertex_vector list? If so I have some recoding to do.

  If you do the same job as POV-Ray does internally, ie. join all duplicate
points into one in the vertex_vector list, then you are doing exactly that:
the same job as POV-Ray.
  The advantage of allowing POV-Ray to do it (ie. by you using 'mesh') is
that it will save you work and will probably be a lot faster (finding
duplicate points is not a trivial task and needs clever data structures
in order to be fast). The best thing you can do is to figure out a way of
not creating duplicate points in the first place (this is possible and even
easy in many cases, and the issue in question is this kind of case).
  Of course the disadvantage of using mesh is that it takes more disk space
(if you write it to a file) and it may be a bit slower to parse (if nothing
else, because it's more to read, being a larger file).

-- 
#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:3d89beea@news.povray.org...
>
>   If you do the same job as POV-Ray does internally, ie. join all
duplicate
> points into one in the vertex_vector list, then you are doing exactly
that:
> the same job as POV-Ray.
>
Yes, but I still prefer to do it myself. Even if my mesh generation code is
sometimes crap, I like the output to be as perfect as possible. Besides, I
already have the code to identify the duplicates, so it's now only a matter
of waiting a few minutes for it to parse.

 -Shay

Post a reply to this message

In article <3d89d844@news.povray.org>, "Shay" <sah### [at] simcopartscom> 
wrote:

> Yes, but I still prefer to do it myself. Even if my mesh generation code is
> sometimes crap, I like the output to be as perfect as possible. Besides, I
> already have the code to identify the duplicates, so it's now only a matter
> of waiting a few minutes for it to parse.

The output will be identical. It is just that the built-in feature will 
always get the vertices right, while your duplicate-removal code might 
have a bug. Using the built-in feature will get a "perfect" result 
(correct image and minimal memory usage), and be much faster than doing 
the duplicate removal in POV script. The mesh2 syntax is mainly useful 
for working with mesh files...the files are smaller and faster to parse.

-- 
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

In article <web.3d89562229f3d87418ccf4f70@news.povray.org>,
 "Rohan Bernett" <rox### [at] yahoocom> wrote:

> This could be used to make the tubing for a neon sign. Use the spline once
> for the outer part of the tube, then again with smaller radius for the
> inner part. Perhaps this could be done with a loop inside the sphere_sweep
> object. Then use csg to make the hollow tube.

Why would this require a new syntax?

-- 
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

Christopher James Huff <chr### [at] maccom> wrote in message
news:chr### [at] netplexaussieorg...
>
> <snip>while your duplicate-removal code might
> have a bug.
>
In this case it's just too simple to f__k up.

> The mesh2 syntax is mainly useful
> for working with mesh files...the files are smaller and faster to parse.
>
That is a consideration, albeit a small one. My IRTC entry, currently one
large mesh2 file, already takes about 8 seconds to parse. Another
consideration is that when forming mesh objects not generated by an
equation, the vertices must be grouped anyway in order to calculate the
normal vectors. The work to translate the file into a mesh2 after having
grouped the vertices for the purpose of calculating the normal vectors is so
small that it is worth it to me to complete the conversion even for a small
consideration. This is of course provided that my code is error free, which
I am confident it is.

 -Shay

Post a reply to this message

Christopher James Huff <chr### [at] maccom> wrote:
> The output will be identical. It is just that the built-in feature will 
> always get the vertices right, while your duplicate-removal code might 
> have a bug.

  It's often the case that you can build the mesh without creating
duplicate vertex points at all. This way you don't have to remove anything.
  For example, if you make a box using mesh2, you simply create 8 points
in the vertex list and then use their index values in the faces list.
Similarly for more advanced shapes, usually created using loops (such
as cylinders, spheres, etc).

-- 
#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

"Shay" <sah### [at] simcopartscom> wrote in news:3d89f074@news.povray.org:

> 
> Christopher James Huff <chr### [at] maccom> wrote in message
> news:chr### [at] netplexaussieorg...
>>
>> <snip>while your duplicate-removal code might
>> have a bug.
>>
> In this case it's just too simple to f__k up.

Uh? What is this function? In which include file can I find it?
Does it look nice, used in an isosurface?
:-P

-- 
--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/

Post a reply to this message

On Wed, 18 Sep 2002 15:38:31 +0200, Jellby <jel### [at] M-softhomenet> 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 :)

It is not isosurface object, it is parametric object. It is not exactly the
same. And if something is possible with parametric object then it is possible
with mesh. Look at http://members.home.nl/seedseven/

ABX

Post a reply to this message

Philippe Lhoste <Phi### [at] GMXnet> wrote in message
news:Xns### [at] 204213191226...
> "Shay" <sah### [at] simcopartscom> wrote in news:3d89f074@news.povray.org:

> > In this case it's just too simple to f__k up.
>
> Uh? What is this function? In which include file can I find it?
> Does it look nice, used in an isosurface?
> :-P
>

This function can be found in many of my personal *.inc files. Output is a
harsh gong-type noise and a yellow highlight over one line of code.
Isosurface version produces an isosurface the exact shape and scale of the
bounding container.

 -Shay

Post a reply to this message

ABX wrote:

> On Wed, 18 Sep 2002 15:38:31 +0200, Jellby <jel### [at] M-softhomenet>
> 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 :)
> 
> It is not isosurface object, it is parametric object. It is not exactly
> the same. And if something is possible with parametric object then it is
> possible with mesh. Look at http://members.home.nl/seedseven/
> 
> ABX

Yes, now I have read the whole tutorial (I just had a quick look before). I 
see the difference between isosurfaces and parametric objects. And yes, 
almost everything is possible with meshes, but it's not the same, from my 
point of view it's just a fake, a useful, efficient, clever fake, but a 
fake.

Post a reply to this message

On Fri, 20 Sep 2002 20:00:31 +0200, Jellby <jel### [at] M-softhomenet> wrote:
> Yes, now I have read the whole tutorial (I just had a quick look before). I 
> see the difference between isosurfaces and parametric objects. And yes, 
> almost everything is possible with meshes, but it's not the same, from my 
> point of view it's just a fake, a useful, efficient, clever fake, but a 
> fake.

Is approximation a fake in your definition ?

ABX

Post a reply to this message

Jellby <jel### [at] M-softhomenet> wrote in message
news:3d8b623e@news.povray.org...

< And yes,
> almost everything is possible with meshes, but it's not the same, from my
> point of view it's just a fake, a useful, efficient, clever fake, but a
> fake.

I'd better get on the phone to Pixar right away!! <g>

 -Shay

Post a reply to this message

ABX wrote:

> On Fri, 20 Sep 2002 20:00:31 +0200, Jellby <jel### [at] M-softhomenet>
> wrote:
>> Yes, now I have read the whole tutorial (I just had a quick look before).
>> I see the difference between isosurfaces and parametric objects. And yes,
>> almost everything is possible with meshes, but it's not the same, from my
>> point of view it's just a fake, a useful, efficient, clever fake, but a
>> fake.
> 
> Is approximation a fake in your definition ?
> 
> ABX

Don't misunderstand me. Maybe 'fake' was not a very well-chosen word (I'm 
not an English speaker). I meant that meshes are not the 'true' object (if 
you are approximating an object by means of a mesh), if you zoom it you 
will eventually see the triangles in the shadow, and they are not quite 
'elegant', I think... We do have true spheres in povray, and they can be 
made as meshes too. I was just wondering if it would be possible to have 
such prismatic lathes in an optimized way (parametrics are slow, I've 
heard), without the need of converting to a mesh. I don't demand it, I 
can't do that and I don't want to do that, I was just giving an idea.

After all, everything in povray is just a fake of reality ;)

Post a reply to this message

On Fri, 20 Sep 2002 22:27:17 +0200, Jellby <jel### [at] M-softhomenet> wrote:
> > Is approximation a fake in your definition ?
>
> Don't misunderstand me. Maybe 'fake' was not a very well-chosen word (I'm 
> not an English speaker). I meant that meshes are not the 'true' object (if 
> you are approximating an object by means of a mesh).

When I asked above question I tried to point you that surfaces of isosurface
and parametric objects are approximations. You can control accuracy of this
approximation with max_gradient, accuracy and evaluate keywords. You can
control accuracy of the mesh with vertex resolution. So isosurface is a fake,
"a useful, efficient, clever fake, but a fake" quoting you. It is better
approximation becouse of its alogithms but for the same reason it is usually
slower.

> After all, everything in povray is just a fake of reality ;)

and animation features are just a fake of real movie www.POVtheMOVIE.com ;)

ABX

Post a reply to this message

ABX wrote:

> When I asked above question I tried to point you that surfaces of
> isosurface and parametric objects are approximations. You can control
> accuracy of this approximation with max_gradient, accuracy and evaluate
> keywords.

I had the feeling that was what you meant ;)

Post a reply to this message