 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I know a little about what nurbs are, but I'd like to know more about the
details.
First: what are the differences between nurbs and bicubic patches?
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated May 10)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Here's the answer I got when I asked a similar question some time ago:
> If anyone knows the Equations for NURBS, I'd be very grateful.
NURBS = Non Uniform Rational B-Splines, aka Bezier Patches, Bicubic Patches,
etc. It's all the same stuff.
...Chambers
--
/* Nekar Xenos */#local N=<-20,40,100>;#local K=<20,-40,100>;#local R=seed(0);
blob{#while((K-N).x>0)#local X=N;#local N=N+<rand(R),rand(R),1>/3;#local N=(
vlength(N-K)<vlength(X-K)?N:2*X-N);sphere{<N.y,-N.x,N.z>,1,1 scale .02}sphere{N
,1,1 scale.02}sphere{<-N.x-40,N.y,N.z>1,1 scale.01}sphere{<N.x+40,-N.y,N.z>1,1
scale.01 }#end pigment{rgbt 1}interior{media{emission <2,4,5>*5}}hollow}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 1 Jun 2001 16:32:23 +0200, Nekar Xenos wrote:
>Here's the answer I got when I asked a similar question some time ago:
>
>
>> If anyone knows the Equations for NURBS, I'd be very grateful.
>
>NURBS = Non Uniform Rational B-Splines, aka Bezier Patches, Bicubic Patches,
>etc. It's all the same stuff.
Not really. Bezier patches/bicubic patches are neither non-uniform nor
rational.
--
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbt 1}hollow interior{media{emission T}}finish{
reflection.1}}#end Z(-x-x.2y)Z(-x-x.4x)camera{location z*-10rotate x*90}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rune wrote:
>
> I know a little about what nurbs are, but I'd like to know more about the
> details.
>
http://www.cs.wpi.edu/%7ematt/courses/cs563/talks/nurbs.html
--
Christoph Hormann <chr### [at] gmx de>
IsoWood include, radiosity tutorial, TransSkin and other
things on: http://www.schunter.etc.tu-bs.de/~chris/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
What I would like to know is if anyone has any plans to add these things to
POV any time soon...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker <ron### [at] povrayorg> wrote:
: Not really. Bezier patches/bicubic patches are neither non-uniform nor
: rational.
I think this means in practice that you can fine-tune the parameters
of a NURBS more extensively than those of a bicubic patch.
I'm not completely sure about this, but I think that with a NURBS you can
control, among other things, the curvature and tangent of the curve at each
control point individually.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3b17c237@news.povray.org>, Warp <war### [at] tagpovrayorg> wrote:
>Ron Parker <ron### [at] povrayorg> wrote:
>: Not really. Bezier patches/bicubic patches are neither non-uniform nor
>: rational.
Ok, there's about 4 types of curves being discussed here, from (mathematically)
simplest to most complex, they are:
Bezier curves
Bicubic patches
B-Splines (uniform, non-rational)
NURBS (which stands for non-uniform, rational, b-spline)
All of them are based on the idea of a set of control points, and a set of
blending functions.
Starting in 2 dimensions, with Bezier curves:
A curve can be defined in terms of a single parameter, (typically 's' or 't'
are used, depending on your mathematical background) which represents the
normalized distance along the curve, from it's starting point (control point 0)
towards it's ending point (for a Bezier curve, this is control point 3,
although the algorithim could be generalized to any number of points). By
'normalized distance' I mean that the parameter (I'll use 't') is 0 at the
starting point, and 1 and the ending point.
Each control point will have an x and y co-ordinate (<x0,y0> to <x3,y3>), and
an associated blending function.
For Bezier curves, the blending functions are just the standard expansion
of ( t * (1-t) ) ^3, seperated according to the power of the 't' term.
(Historically, I don't think this was the motivation for development of
this set of blending functions, but this is how it works out)
So blending function 3 is t^3.
b.f. 2 = 3 * (t ^2)*(1-t)
b.f. 1 = 3 * t * ( (1-t)^2)
b.f. 0 = (1-t)^3
For any value of t, it is then possible to evaluate an <x,y> position by
the formula:
R = (point 0 * blending function 0) + (p1 * bf1) + (p2 * bf2) +
(p3 * bf3)
If you examine the blending functions, you'll notice that at t=0 blending
functions 1 to 3 are all 0, and blending function 0 is 1, so R = point 0.
Similarly at t=1, blending functions 0 to 2 are all 0, and blending fucntion3
is 1, so R = point 3. I.e. the curve passes through the start and end points.
It does not, however, always pass through points 1 and 2 (although there are
cases where it does)
The curve is drawn by evaluating <x,y> for various values of t, and joining
the results with line segments. Obviously the more values of t you evaluate
for, the smoother the curve that will be drawn.
Bicubic patches are generalizations of Bezier curves into 3-dimensional
sheets. Instead of a single parameter, the position on the sheet is determined
by 2 parameters, <u,v>.
The blending functions are also generalizations into two parameters. I think
(I'm doing this from memory, so don't take this as the final word) that they
can be given by doing the same seperation, according to powers of both u and
v, of the expansion of ( u * v * (1-u) * (1-v) ) ^3
Note that for a bicubic patch, the control points are not numbered
sequentially, but in a grid, and the blending functions are likewise seperated
on two axis. So:
bf0,0 = (1-u)^3 * (1-v)^3
bf1,0 = 3 * u * (1-u)^2 * (1-v)^3
bf2,0 = 3 * u^2 * (1-u) * (1-v)^3
bf3,0 = u^3 * (1-v)^3
bf0,1 = (1-u)^3 * v * (1-v)^2
bf1,1 = 3 * u * (1-u)^2 * v * (1-v)^2
bf2,1 = 3 * u^2 * (1-u) * v * (1-v)^2
bf3,1 = u^3 * v * (1-v)^2
And so on.
The final point is then given by:
R = sum(i from 0 to 3) {
sum (j from 0 to 3) {
point i,j * blending function i,j
}
}
Uniform, non-rational b-splines are again generated as a function of control
points an blending functions. However, the functions used are more complicated
than the simple polynomial expansion the Bezier/bi-cubics use. These blending
functions are products of something called the knot vector.
The knot vector is a list of numbers (I think they might have to be integers,
but I'm not sure about that) in non-decreasing order. The generation of the
blending functions from the knot vectors is some ugly algebra. There are
relationships between the number of knots (the elements of the knot vector),
the degree of the B-spline, and the number of control points, but I'm not
sure exactly what they are. For our purposes, the only thing that matters is
that the word 'uniform' implies that the spacing between knots is uniform.
There will be one knot vector for each dimension of the surface. So a curve
has a single knot vector, while a surface patch has two.
The non-rational part of the word means that each control point has the
same weight (i.e. all have weight 1)
And now, finially, NURBS. Non-uniform, rational, B-splines. A further
generalization of B-splines. The 'non-uniform' adjective means that the
elements in the knot vector(s) do not have to be evenly spaced (although
they are still non-decreasing). Repeating elements allows for sharp corners
and discontinuities.
Rational means that each control point has a weight associated with it. I'm
not sure how the weights interact with the points and blending functions,
but I believe that it's something like:
R = sum(i from 0 to 3) {
sum (j from 0 to 3) {
weight i,j * point i,j * blending function i,j
}
} / sum{all weights}
Ok, and that's enough math for one afternoon.
Jamie
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ok, so nurbs are much more powerful than bicubic patches.
Now, I don't understand all those formulas I've been shown, so I still have
many questions.
Bicubic patches always have 4 corners. Can nurbs have 3 or 5 corners?
If you want smooth results you can only match up bicubic patches joining the
corners of 4 bicubic patches at a time. Because of that they can only be
used for objects with very simple topology. I presume any number of nurbs
can be joined up smoothly (typically 3, 4 or 5) ...?
Would it be possible to implement nurbs in POV-Ray? Would it be reasonable?
If so, what would a possible syntax look like?
The reason I'm interested in these nurbs is that I find bicubic patches too
limiting for what I want to do. IMHO POV-Ray would really benefit from such
flexible surfaces that nurbs are. Besides, it seems they're the most common
way of generating surfaces in the CG industry, besides basic polygons...
The above are just my thoughts. I really don't know anything about the
subject...
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated May 10)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tony[B]" wrote:
>
> What I would like to know is if anyone has any plans to add these things to
> POV any time soon...
This comes up a couple of times a year. It is generally considered not
worth the effort. NURBS are great in a GUI modelling environment but
offer little to nothing to a text file based parsing program like POV-Ray.
Additionally anything you can model with NURBS in a modelling program
can be converted to triangles and rendered in POV-Ray anyway. So the
question is why bother ?
--
Ken Tyler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3b18336b@news.povray.org>,
Rune <run### [at] mobilixnetdk> wrote:
>Ok, so nurbs are much more powerful than bicubic patches.
In fact, bicubic/bezier patch/curves are just special cases of
nurbs objects. (Although I can't tell you offhand what the knot
vector would have to be)
>Bicubic patches always have 4 corners. Can nurbs have 3 or 5 corners?
Well, for quick and dirty results, you can space the control points in
a bicubic in such a way as to generate a triangular patch.
Alternatively, why not just clip the patch between diagonal corners?
But in general, any of the patches are just a method to convert from
a two-coordinate (u,v) system into a three-coordinate (x,y,z) one.
Typically, for a patch, u and v represent distances parallell to the
edges of the (non-deformed) patch, however, any two-coordinate system
could be used. For example, it would be possible to have u,v
correspond to angle, radius. So your default patch shape would be a
wedge-shape.
(Hmm, on further consideration, there could be a few difficulties with
this, as all the radius=0 points overlap. But it should be codeable-
around)
So, any number of corner figure can be used as the base shape, provided
you can find a nice way of representing it using two co-ordinates. The
tricky part is finding the 'nice' way, or even what constitutes nice.
For example, one of the properties of the square bicubic patch is that
curve along the edges depends only on the control points along that edge.
This is because moving along any edge of the patch involves a change in
only one parameter. ( You change u as you move along the top or bottom
edges, and v as you move along the sides). I consider this a 'nice'
property, so any triangular-based u-v system should preserve this.
Other people may disagree.
Nurbs are mathematically a bit more complicated to generate, but the
same theory applies... they're a mapping from (u,v) to (x,y,z)
>used for objects with very simple topology. I presume any number of nurbs
>can be joined up smoothly (typically 3, 4 or 5) ...?
Nope. Not unless someone comes up with a good method of representing
n-sided figures as (u,v) paramter pairs.
>Would it be possible to implement nurbs in POV-Ray? Would it be reasonable?
>If so, what would a possible syntax look like?
Ugly. Very ugly. A nurb patch requires a fair chunk of data to specify it.
There's the N x M array of control points. A weight for each point, and the
two knot vectors (each of which has N or M, plus degree, plus 1 (I think))
elements. Oh, and understanding what the knot vector does is not pleasant.
Jamie
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Because we can? Or as JFK would say: "Not because it is easy, but because it
is hard." OK. Real reason: I think it would make the files smaller and give
you more control later, no?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tony[B]" wrote:
>
> Because we can? Or as JFK would say: "Not because it is easy, but because it
> is hard." OK. Real reason: I think it would make the files smaller and give
> you more control later, no?
Smaller file sixes perhaps, greater control later, not. NURBS are great to
to use in a GUI environment. Trying to manipulate them without a GUI interface
would be madness. How many people do you personaly know (shut up, Ron) that can
hand code a single bezier patch ? Even if the syntax were simplified to the
maximum extent their complexity of use would still far surpass the difficulty
of use of a simple bezier patch.
--
Ken Tyler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 01 Jun 2001 22:13:21 -0700, Ken <tyl### [at] pacbellnet> wrote:
>Smaller file sixes perhaps, greater control later, not. NURBS are great to
>to use in a GUI environment. Trying to manipulate them without a GUI interface
>would be madness. How many people do you personaly know (shut up, Ron) that can
>hand code a single bezier patch ?
<raises hand>
>Even if the syntax were simplified to the
>maximum extent their complexity of use would still far surpass the difficulty
>of use of a simple bezier patch.
What about generating nurbs on the fly with macros? The tessellation
phase will be done by the pre-renderer and not by the parser and will
be much faster. It could be helpful for macros such as Stricia or the
rock macro.
In the current time frame, though, I think the Team has more important
work than nurbing POV. If anyone decides to patch POV to use NURBS,
well, ok :)
Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG e-mail : pet### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3B1875F1.645BC24C@pacbell.net>, Ken <tyl### [at] pacbellnet>
wrote:
> How many people do you personaly know (shut up, Ron) that
> can hand code a single bezier patch ?
<Raises hand...>
It's not that hard, really...easier than meshes.
> Even if the syntax were simplified to the maximum extent their
> complexity of use would still far surpass the difficulty of use of a
> simple bezier patch.
True. But they would be useful when automatically generated by macros,
or as output from GUI modellers. One clear advantage: it would be
possible to do some of the tesselation at render-time, so memory could
be saved and visible "facets" minimized.
--
Christopher James Huff - chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote:
>
> In article <3B1875F1.645BC24C@pacbell.net>, Ken <tyl### [at] pacbellnet>
> wrote:
>
> > How many people do you personaly know (shut up, Ron) that
> > can hand code a single bezier patch ?
>
> <Raises hand...>
> It's not that hard, really...easier than meshes.
<Raises hand...>
I've hand coded meshes...patches damage my brain.
--
Ken Tyler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rune <run### [at] mobilixnetdk> wrote:
: Would it be possible to implement nurbs in POV-Ray?
I see no reason why NURBS (or should it be said "NURBSes"?) couldn't be
implemented as macros which generate triangles or bicubic patches.
AFAIK NURBS can be simulated with bicubic patches if you use several
of them (spatch does exactly that). And if everything else fails, it could
just generate a triangle mesh.
The only drawback would be speed, specially if triangles are generated.
However, I think that's a quite small price to pay for the functionality
(as I have preached several times before, if humanly possible, every new
feature should be implemented as macros instead of a patch if it makes
sense and you don't have to make too many compromises).
However, I think that the biggest problem is your next question:
: Would it be reasonable?
As Ken said, NURBS are useful mainly in GUI modellers.
Perhaps it could be possible to make the NURBS macros as easy to use as
possible, but still it would be a pain to hand-code objects with them.
: The reason I'm interested in these nurbs is that I find bicubic patches too
: limiting for what I want to do.
Is it something you can't do with spatch (or hamapatch for that matter)?
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Ken" wrote:
> How many people do you personaly know (shut up, Ron)
> that can hand code a single bezier patch ?
<raises hand>
I can hand code them and I can also generate them by macros (and that way
I'm able to animate them).
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated May 10)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" wrote:
> "Rune" wrote
> : The reason I'm interested in these nurbs is that I
> : find bicubic patches too limiting for what I want to do.
>
> Is it something you can't do with spatch (or hamapatch
> for that matter)?
Yes.
First, I am modeler impaired. I can't use modelers. But even if I could, I
doubt it'd work for my purpose, since I need to animate my patches according
to certain variables.
Nurbs may not be exactly what I'm looking for, I'll post another message in
this thread where I describe my actual problem.
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated May 10)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
The reason I had these nurbs questions is that I have some problems with
bicubic patches, and wanted to know if it could possible have something to
do with the differences between nurbs and bicubic patches.
My actual problem is this: I need to model smooth shapes with relative
complicated topology. As far as I have understood bicubic patches always
have four corners and they can only be matched up four corners at a time if
the surface needs to be smooth. This means they can't be used for smooth
surfaces with complicated topology.
I have been wondering how the problem is usually handled. When looking at
wireframes made with nurbs I notice that there's almost always a few vital
patches with three or five corners. And the surface is still completely
smooth. Is that a special ability nurbs have or what...?
Anyway, any ideas how I can solve my problem? Would it work to create a
triangular bicubic patch by using a regular bicubic patch where one half is
transparent? I mean, would I get a smooth surface if I filled in such a half
patch between regular patches with four corners? In other words, do the
spline between 4 diagonal points behave the same way as the spline between 4
edge points?
I hope there's a solution out there.
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated May 10)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > How many people do you personaly know (shut up, Ron) that
> > can hand code a single bezier patch ?
>
> <Raises hand...>
> It's not that hard, really...easier than meshes.
done both, but not for a long while, and even then I want through a dozen or
so post it notes with teeny doodles on stuck all round my screen
--
Rick
Kitty5 WebDesign - http://Kitty5.com
Hi-Impact database driven web site design & e-commerce
TEL : +44 (01625) 266358 - FAX : +44 (01625) 611913 - ICQ : 15776037
POV-Ray News & Resources - http://Povray.co.uk
PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3b191185@news.povray.org>, Warp <war### [at] tagpovrayorg>
wrote:
> I see no reason why NURBS (or should it be said "NURBSes"?)
Probably "NURBSs". The "S" stands for "Spline", and you simply tack an
"s" on the end to make it "Splines", so I would do the same for the
acronym.
> The only drawback would be speed, specially if triangles are generated.
Not the only drawback...it will use more memory and the lack of adaptive
render-time tesselation means you would have more triangles than you
needed, or visible faceting.
> Is it something you can't do with spatch (or hamapatch for that matter)?
Well, I couldn't use spatch. I could use PatchDance, though...
--
Christopher James Huff - chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I wrote:
> When looking at wireframes made with nurbs I notice that
> there's almost always a few vital patches with three or
> five corners. And the surface is still completely smooth.
> Is that a special ability nurbs have or what...?
This and the others are questions I've had for a long time and I would
really appreciate if somebody could enlighten me. Do anybody know anything
about it?
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated May 10)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rune wrote in message <3b1ab995@news.povray.org>...
>I wrote:
>> When looking at wireframes made with nurbs I notice that
>> there's almost always a few vital patches with three or
>> five corners. And the surface is still completely smooth.
>> Is that a special ability nurbs have or what...?
>
>This and the others are questions I've had for a long time and I would
>really appreciate if somebody could enlighten me. Do anybody know anything
>about it?
>
>Rune
When you have an odd number of corners like that, there will be one or more
patch edges terminating. At that point you will have a discontinuity and a sharp
edge. My research indicates internally, all renderers convert patches to
polygons prior to rendering (possible exception: Hash Animator claims
otherwise). Knowing this most of them make allowances for these discontinuities
and smooth out the result. PoV also converts to triangles but has no method for
automatically smoothing discontinuities like this, apparently treating each
patch as a discrete object without regard for its neighbors within a union, with
any smoothness between patches being the natural result of the continuity
between patches as modeled.
My usual workaround to your problem, is to model without regard to the sharp
edges and then export my patch objects to smooth_triangle mesh objects, which
usually solves my 'smoothing' problems. I usually do this from sPatch, exporting
to .dxf and then several other conversion/processing steps depending on whether
I'm going to bone it for posing (Anim8or) and/or apply UV mapping (UVMapper)
etc.
Since you prefer to hand code, I suggest you look into the capabilities of Chris
Colefax's PCM macros and Warp's mesh compressor. They both support bicubic
patches as well as triangles. You could create your models with all the
complexity you wanted, and animate them the way you wanted, without concern for
smoothness (or lack thereof) and then shell out to the compressor between
frames.
Of course it won't be quite as simple as I've made it sound here, but it is
certainly do-able.
Hope that helps.
----------------------------------------
Batronyx ^"^
bat### [at] cadronhsacom
http://www.batronyx.com
Bhuddist monk to hotdog vendor:
"Make me one with everything."
----------------------------------------
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff <chr### [at] maccom> wrote:
: Not the only drawback...it will use more memory and the lack of adaptive
: render-time tesselation means you would have more triangles than you
: needed, or visible faceting.
Wouldn't render-time tesselation slow it down quite a lot (at least
compared to rendering a triangle mesh)?
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3b1b53d7@news.povray.org> , Warp <war### [at] tagpovrayorg> wrote:
> Wouldn't render-time tesselation slow it down quite a lot (at least
> compared to rendering a triangle mesh)?
Maybe some caching of frequently needed triangles could do. Not sure how
easy to implement that though...
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Batronyx" wrote:
> Since you prefer to hand code, I suggest you look into the
> capabilities of Chris Colefax's PCM macros and Warp's mesh
> compressor. They both support bicubic patches as well as
> triangles.
But they don't convert one format to the other. Nor do they do smoothing.
> You could create your models with all the complexity you
> wanted, and animate them the way you wanted, without
> concern for smoothness (or lack thereof) and then shell out
> to the compressor between frames.
My bicubic patches are written in POV-Ray script and they are dependent on
variables. No program can read that.
Thanks for the information anyway. It answered some of my questions.
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated May 10)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rune wrote:
>
> "Batronyx" wrote:
> > Since you prefer to hand code, I suggest you look into the
> > capabilities of Chris Colefax's PCM macros and Warp's mesh
> > compressor. They both support bicubic patches as well as
> > triangles.
>
> But they don't convert one format to the other. Nor do they do smoothing.
Warp's mesh compressor has a smoothing option.
--
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken <tyl### [at] pacbellnet> wrote:
: Warp's mesh compressor has a smoothing option.
This is not true, although I have thought about it for quite a long time
(and not implemented it because of laziness, which is partly caused by
the fact that my mesh smoother already does it...).
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Ken" wrote:
> Warp's mesh compressor has a smoothing option.
I'm using meshcomp v2.1 and it has no smoothing option as far as I can see.
Which version are you using? Can you copy the part of the manual regarding
the smoothing option?
Not that it would help me anyway, but it's always good to know for future
reference.
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated May 10)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rune wrote:
>
> "Ken" wrote:
> > Warp's mesh compressor has a smoothing option.
>
> I'm using meshcomp v2.1 and it has no smoothing option as far as I can see.
See Warp's reply. My bad.
--
Ken Tyler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3b1b53d7@news.povray.org>, Warp <war### [at] tagpovrayorg>
wrote:
> Wouldn't render-time tesselation slow it down quite a lot (at least
> compared to rendering a triangle mesh)?
It would be slower but save memory...you would have a choice, just like
you do with bicubic patches.
--
Christopher James Huff - chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 04 Jun 2001 16:58:11 -0700, Ken wrote:
>See Warp's reply. My bad.
Your bad what?
--
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbt 1}hollow interior{media{emission T}}finish{
reflection.1}}#end Z(-x-x.2y)Z(-x-x.4x)camera{location z*-10rotate x*90}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Ron Parker" <ron### [at] povrayorg> wrote in message
news:slr### [at] fwicom...
> On Mon, 04 Jun 2001 16:58:11 -0700, Ken wrote:
> >See Warp's reply. My bad.
>
> Your bad what?
>
It would mean "mistake."
--
Me (Daniel Lin (dli### [at] yahoocom))
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 4 Jun 2001 22:16:48 -0400, Daniel Lin wrote:
>"Ron Parker" <ron### [at] povrayorg> wrote in message
>news:slr### [at] fwicom...
>> On Mon, 04 Jun 2001 16:58:11 -0700, Ken wrote:
>> >See Warp's reply. My bad.
>>
>> Your bad what?
>>
>It would mean "mistake."
It would, if it did. But it doesn't. "Bad" is still an adjective.
--
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbt 1}hollow interior{media{emission T}}finish{
reflection.1}}#end Z(-x-x.2y)Z(-x-x.4x)camera{location z*-10rotate x*90}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
>
> On Mon, 04 Jun 2001 16:58:11 -0700, Ken wrote:
> >See Warp's reply. My bad.
>
> Your bad what?
I know it was a bad thing to say but the Devil made me do it.
--
Ken Tyler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken <tyl### [at] pacbellnet> wrote:
: I know it was a bad thing to say but the Devil made me do it.
Ah, so it was your evil brother? ;)
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rune wrote:
>
> I know a little about what nurbs are, but I'd like to know more about the
> details.
>
> First: what are the differences between nurbs and bicubic patches?
>
> Rune
> --
NURBS in PovRay - my dream or 150 MB of memory necessary for mesh of my
last plane's model exported from Rhino (please see
www.angelfire.com/sk/gatial)
Jozef
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
James Tonkin wrote:
> In article <3b17c237@news.povray.org>, Warp <war### [at] tagpovrayorg> wrote:
>
>>Ron Parker <ron### [at] povrayorg> wrote:
>>: Not really. Bezier patches/bicubic patches are neither non-uniform nor
>>: rational.
>>
>
> Ok, there's about 4 types of curves being discussed here, from (mathematically)
> simplest to most complex, they are:
>
> Bezier curves
> Bicubic patches
> B-Splines (uniform, non-rational)
> NURBS (which stands for non-uniform, rational, b-spline)
>
> All of them are based on the idea of a set of control points, and a set of
> blending functions.
>
> Starting in 2 dimensions, with Bezier curves:
>
> A curve can be defined in terms of a single parameter, (typically 's' or 't'
> are used, depending on your mathematical background) which represents the
> normalized distance along the curve, from it's starting point (control point 0)
> towards it's ending point (for a Bezier curve, this is control point 3,
> although the algorithim could be generalized to any number of points). By
> 'normalized distance' I mean that the parameter (I'll use 't') is 0 at the
> starting point, and 1 and the ending point.
>
> Each control point will have an x and y co-ordinate (<x0,y0> to <x3,y3>), and
> an associated blending function.
>
> For Bezier curves, the blending functions are just the standard expansion
> of ( t * (1-t) ) ^3, seperated according to the power of the 't' term.
>
> (Historically, I don't think this was the motivation for development of
> this set of blending functions, but this is how it works out)
>
> So blending function 3 is t^3.
> b.f. 2 = 3 * (t ^2)*(1-t)
> b.f. 1 = 3 * t * ( (1-t)^2)
> b.f. 0 = (1-t)^3
>
Could you please tell me what separation of a formule is? i.e., how do
you get the blending functions from ( t*(1-t))^3?
Thanks in advance,
Remco Poelstra
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Remco Poelstra <rjp### [at] homenl> wrote:
>James Tonkin wrote:
[a bunch of stuff about the math behind bicubic patches]
>Could you please tell me what separation of a formule is? i.e., how do
>you get the blending functions from ( t*(1-t))^3?
Well, it would help if I had of put the correct formula down in the first
place... sorry bout that. Here's the full derivation
(t + (1-t) ) ^3
= (t + (1-t)) * (t + (1-t)) * (t + (1-t))
= [ t*t + t*(1-t) + (1-t)*t + (1-t)*(1-t)] * [ t + (1-t)]
= [ t^2 + 2 * t * (1-t) + (1-t)^2] * [t + (1-t)]
= ( t^2 * t) + (2 * t * (1-t) * t) + ( (1-t)^2 * t) + (t^2 * (1-t))
+ (2 * t * (1-t) * (1-t) ) + ( (1-t)^2 * (1-t))
= t^3 + ( 2 * t^2 * (1-t) ) + (t * (1-t)^2) + (t^2 * (1-t))
+ ( 2 * t * (1-t)^2) + (1-t)^3
= t^3 + (3 * t^2 * (1-t)) + (3 * t * (1-t)^2) + (1-t)^3
So the 4 terms in the last line correspond to the 4 blending functions.
Hope that helps,
Jamie
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
James Tonkin wrote:
>
> Well, it would help if I had of put the correct formula down in the first
> place... sorry bout that. Here's the full derivation
>
> (t + (1-t) ) ^3
>
> = (t + (1-t)) * (t + (1-t)) * (t + (1-t))
>
> = [ t*t + t*(1-t) + (1-t)*t + (1-t)*(1-t)] * [ t + (1-t)]
>
> = [ t^2 + 2 * t * (1-t) + (1-t)^2] * [t + (1-t)]
>
> = ( t^2 * t) + (2 * t * (1-t) * t) + ( (1-t)^2 * t) + (t^2 * (1-t))
> + (2 * t * (1-t) * (1-t) ) + ( (1-t)^2 * (1-t))
>
> = t^3 + ( 2 * t^2 * (1-t) ) + (t * (1-t)^2) + (t^2 * (1-t))
> + ( 2 * t * (1-t)^2) + (1-t)^3
>
> = t^3 + (3 * t^2 * (1-t)) + (3 * t * (1-t)^2) + (1-t)^3
>
> So the 4 terms in the last line correspond to the 4 blending functions.
>
Thanks, exactly what I wanted to know.
Remco Poelstra
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3b40f28b$1@news.povray.org>, James Tonkin says...
> Remco Poelstra <rjp### [at] homenl> wrote:
> >James Tonkin wrote:
>
> [a bunch of stuff about the math behind bicubic patches]
>
> >Could you please tell me what separation of a formule is? i.e., how do
> >you get the blending functions from ( t*(1-t))^3?
>
> Well, it would help if I had of put the correct formula down in the first
> place... sorry bout that. Here's the full derivation
>
> (t + (1-t) ) ^3
>
> = (t + (1-t)) * (t + (1-t)) * (t + (1-t))
>
> = [ t*t + t*(1-t) + (1-t)*t + (1-t)*(1-t)] * [ t + (1-t)]
>
> = [ t^2 + 2 * t * (1-t) + (1-t)^2] * [t + (1-t)]
>
> = ( t^2 * t) + (2 * t * (1-t) * t) + ( (1-t)^2 * t) + (t^2 * (1-t))
> + (2 * t * (1-t) * (1-t) ) + ( (1-t)^2 * (1-t))
>
> = t^3 + ( 2 * t^2 * (1-t) ) + (t * (1-t)^2) + (t^2 * (1-t))
> + ( 2 * t * (1-t)^2) + (1-t)^3
>
> = t^3 + (3 * t^2 * (1-t)) + (3 * t * (1-t)^2) + (1-t)^3
>
> So the 4 terms in the last line correspond to the 4 blending functions.
>
> Hope that helps,
> Jamie
>
Not to criticize the way you calculate the result, starting from
(t + (1-t) ) ^3, but in school we went from (a+b)^3 straight to
a^3 + 3*a^2*b + 3*a*b^2 + b^3.... :)
--
Regards, Sander
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
