POV-Ray : Newsgroups : povray.binaries.images : SOR:nurbs or not? Server Time
1 Jul 2024 01:09:21 EDT (-0400)
  SOR:nurbs or not? (Message 5 to 14 of 14)  
<<< Previous 4 Messages Goto Initial 10 Messages
From: LanuHum
Subject: Re: SOR:nurbs or not?
Date: 4 Aug 2015 16:05:01
Message: <web.55c119d8795308e17a3e03fe0@news.povray.org>
Le_Forgeron <jgr### [at] freefr> wrote:

>
> there is bicubic_patch.
>
> http://povray.org/documentation/view/3.6.1/64/
> http://wiki.povray.org/content/Reference:Bicubic_Patch
> http://www.povray.org/documentation/view/3.6.1/290/
>
> It's a Bezier patch.
>
> > Badly. It strongly limits possibilities of data transmission from
> > the Blender to Povray.
>
> Most nurbs rendering transforms them in mesh anyway. (I recommend
> mesh2 format for them).
>
> It's not a concept (to refuse nurbs), it's just that solving the
> intersection of a ray with a nurbs is not something that can be easily
> solved mathematically (I would say: at once, without iterations or
> approximation).
>
> Now, if you can solve it (a nurbs, a ray, return the list of
> intersection points) (as well as "a nurbs, a 3D point, return a
> boolean for the point being inside the volume delimited by the nurbs),
> without generating a mesh under the cover, it can be considered for
> addition.
>
> But beware, even bicubic_patch has a cheating method (type 1), as
> solving pure (type 0) bezier is slow. (but memory effective)
>


Sorry!
No,no!
Before export I can convert all models in mesh.
No problem.
Problem with Constructive Solid Geometry
Not with all converted objects the blender correctly considers boolean.
Your(Povray) algorithms it is better!
Perhaps, it is connected with use by the Blender of quads.(Povray use tris)

And use while - problem.
I could set a cycle:
//Array =
//while (I < %s)
//translate Array%s[I]
but is compelled to calculate:
object {One translate<x1,y1,z1>}
...............................
object {Thousand  translate<x1000,y1000,z1000>}

And, for whom it is now easy? :):):)

The best wishes!


Post a reply to this message

From: clipka
Subject: Re: SOR:nurbs or not?
Date: 4 Aug 2015 16:38:33
Message: <55c122c9$1@news.povray.org>
Am 04.08.2015 um 18:11 schrieb LanuHum:

>> POV-Ray doesn't support NURBS (non-uniform rational B-splines).
>
> Thanks!
> There is no support of nurbs, there is no support of bezier (an exception of
> lathe and prism). Refusal of nurbs and bezier is a concept?

Bezier splines are just a special case of cubic splines, differing only 
in how the control points are translated into the coefficients for the 
polynomials used in the background.

Missing support for bezier in spline functions and sphere_sweep is just 
a matter of incomplete implementation, not of a philosophy.


One reason (the primary one in my book) for missing NURBS support has 
been the lack of affordable user interfaces to define NURBS surfaces and 
export the coefficients to a format suitable for POV-Ray. I wouldn't 
want to have to input NURBS coefficients directly to test such a 
feature, especially if I have no way of verifying the resulting shape.

I didn't know Blender supported NURBS surfaces. If it does, you could 
help by providing a very basic export function that just writes the 
coefficients to an array.

I only have a rudimentary understanding of the underlying math though, 
and there's other stuff high on my agenda at present, so don't hold your 
breath unless Jerome is willing to pick up the glove.

@Jerome: Even if the implementation would be similar to that of bicubic 
patch type 1, i.e. an internal translation to something mesh-like, so 
that in a sense the whole job could also be done by the exporter by 
generating a mesh2 object, I think a NURBS primitive would be beneficial 
in order to minimize file I/O in the workflow.


> If I wrote the AutodeskMaya2Povray exporter, I would meet the same problems?
> :(

I don't think so. I'm pretty sure Maya provides mechanisms for export 
filters to access mesh representations of NURBS surfaces rather than the 
NURBS coefficients themselves, so that would be an option.


Post a reply to this message

From: Le Forgeron
Subject: Re: SOR:nurbs or not?
Date: 5 Aug 2015 02:20:49
Message: <55c1ab41$1@news.povray.org>
Le 04/08/2015 22:37, clipka a écrit :

>
> Missing support for bezier in spline functions and sphere_sweep is just
> a matter of incomplete implementation, not of a philosophy.
>

the spline in povray support 4 kinds: natural_spline, linear_spline, 
quadratic_spline and cubic_spline. The latter three matching the 
equations given in https://en.wikipedia.org/wiki/B%C3%A9zier_curve for
linear/quadratic/cubic Bézier curves.

sphere_sweep, in regard to Bézier, is limited to linear_spline and 
cubic_spline. (b_spline is a more general curve, which can or cannot be 
a Bèzier curve according to the spacing of the points)



>
> One reason (the primary one in my book) for missing NURBS support has
> been the lack of affordable user interfaces to define NURBS surfaces and
> export the coefficients to a format suitable for POV-Ray. I wouldn't
> want to have to input NURBS coefficients directly to test such a
> feature, especially if I have no way of verifying the resulting shape.

Yep, I even get tired of the syntax of poly{} object which was not 
reader & writer friendly at all. It took maybe twenty years to get the 
polynomial syntax (same object, just easier to handle).

>
> I didn't know Blender supported NURBS surfaces. If it does, you could
> help by providing a very basic export function that just writes the
> coefficients to an array.
>
> I only have a rudimentary understanding of the underlying math though,
> and there's other stuff high on my agenda at present, so don't hold your
> breath unless Jerome is willing to pick up the glove.
>
> @Jerome: Even if the implementation would be similar to that of bicubic
> patch type 1, i.e. an internal translation to something mesh-like, so
> that in a sense the whole job could also be done by the exporter by
> generating a mesh2 object, I think a NURBS primitive would be beneficial
> in order to minimize file I/O in the workflow.

I have some other items on my to-do-list (from a long time), and I might 
get stalled in a hen-egg situation: without an array of valid values for 
a nurbs, no incentive to parse and implement such object.
(hint: please provide an interesting nurbs, not just a sphere or a 
torus, something that is unique to nurbs)

If I get something right, the array would be a 2D rectangular array of 
4D values (3D positions of control points and weight).
A global tunning of the nurbs would be its order (2 or 4 ? can it be 
anything ? blender's doc states from 2 to 6), and wether each axis (of 
array) is endpoint or uniform (which i do not understand yet, seems tied 
to the knots setting, allowing only 2 knots vectors)

The dimensions of the array can be anything, each dimension being at 
least the order.


>
>
>> If I wrote the AutodeskMaya2Povray exporter, I would meet the same
>> problems?
>> :(
>
> I don't think so. I'm pretty sure Maya provides mechanisms for export
> filters to access mesh representations of NURBS surfaces rather than the
> NURBS coefficients themselves, so that would be an option.
>


Post a reply to this message

From: Mr
Subject: Re: SOR:nurbs or not?
Date: 5 Aug 2015 08:15:01
Message: <web.55c1fc1b795308e116086ed00@news.povray.org>
> >> If I wrote the AutodeskMaya2Povray exporter, I would meet the same
> >> problems?
> >> :(
> >
> > I don't think so. I'm pretty sure Maya provides mechanisms for export
> > filters to access mesh representations of NURBS surfaces rather than the
> > NURBS coefficients themselves, so that would be an option.
> >

Blender does support an "everything to triangle mesh" export as well, that's
what is implemented in the current exporter, but the idea of treating nurbs as
nurbs just as treating metaballs / blobs as such and any other pov primitive as
its native type like LanuHum is trying to do is much more powerfull to
allow always smooth renders.

Personnally I think the most polyvalent should be to support what JPAtch 0.3
used to support, a curve network converted to four sided bicubic patches, but
it's true native Blender Interface is better designed for NURBS at the moment.
all that would be needed to replace JPatch is a control point tag to "tie
together" several of the curves control points snapped in the same location. The
application of such a tool would bring a whole "market" to both Blender and POV.
the bicubics could also use a mesh with catmull clark subdiv modifier as
graphical input.


Post a reply to this message

From: And
Subject: Re: SOR:nurbs or not?
Date: 5 Aug 2015 11:00:06
Message: <web.55c2249c795308e1ed1a9b950@news.povray.org>
I like the discussion.

clipka <ano### [at] anonymousorg> wrote:
>
> Bezier splines are just a special case of cubic splines, differing only
> in how the control points are translated into the coefficients for the
> polynomials used in the background.

So that's how it is. the bezier spline is just some polynomials in essence!!


Post a reply to this message

From: LanuHum
Subject: Re: SOR:nurbs or not?
Date: 5 Aug 2015 13:55:01
Message: <web.55c24d2c795308e17a3e03fe0@news.povray.org>
Why there was a question?
If I have the correct visualization of a curve in the editor, I can create
Constructive Solid Geometry.
On the picture green prism (bezier_spline) and red curve (bezier_spline).
If sphere_sweep, also as the prism, supported bezier_spline, it is possible to
write:
difference{
    object{prism}
    object(sphere_sweep}}

I can't make it.
I can't reel up a spiral on SOR.
I can SOR and sphere_sweep to model as nurbs, but to write down as cubic.
But, if to displace control points of a curve on Z, the geometry will be broken,
but control is absent also correction not to make.


Post a reply to this message


Attachments:
Download 'csg.jpg' (36 KB)

Preview of image 'csg.jpg'
csg.jpg


 

From: And
Subject: Re: SOR:nurbs or not?
Date: 6 Aug 2015 00:55:01
Message: <web.55c2e86f795308e1ed1a9b950@news.povray.org>
"LanuHum" <Lan### [at] yandexru> wrote:
> Why there was a question?
> If I have the correct visualization of a curve in the editor, I can create
> Constructive Solid Geometry.
> On the picture green prism (bezier_spline) and red curve (bezier_spline).
> If sphere_sweep, also as the prism, supported bezier_spline, it is possible to
> write:
> difference{
>     object{prism}
>     object(sphere_sweep}}
>
> I can't make it.
> I can't reel up a spiral on SOR.
> I can SOR and sphere_sweep to model as nurbs, but to write down as cubic.
> But, if to displace control points of a curve on Z, the geometry will be broken,
> but control is absent also correction not to make.

If bezier spline is nothing else than a cubic spline, maybe I can write a macro
for converting.


Post a reply to this message

From: scott
Subject: Re: SOR:nurbs or not?
Date: 6 Aug 2015 03:23:37
Message: <55c30b79$1@news.povray.org>
> If bezier spline is nothing else than a cubic spline, maybe I can write a macro
> for converting.

http://www.joshuarenglish.com/cyclopedia/bezier.html


Post a reply to this message

From: And
Subject: Re: SOR:nurbs or not?
Date: 6 Aug 2015 11:40:00
Message: <web.55c37f32795308e1ed1a9b950@news.povray.org>
scott <sco### [at] scottcom> wrote:
> > If bezier spline is nothing else than a cubic spline, maybe I can write a macro
> > for converting.
>
> http://www.joshuarenglish.com/cyclopedia/bezier.html

Uh huh,.. okay, I will try it.


Post a reply to this message

From: LanuHum
Subject: Re: SOR:nurbs or not?
Date: 6 Aug 2015 13:25:01
Message: <web.55c39752795308e17a3e03fe0@news.povray.org>
"And" <49341109@ntnu.edu.tw> wrote:

>
> If bezier spline is nothing else than a cubic spline, maybe I can write a macro
> for converting.

Thanks!


Post a reply to this message

<<< Previous 4 Messages Goto Initial 10 Messages

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.