Yep, real nurbs, without tesselation.

(and nurbs also mean b-spline, as b-spline are nurbs with weight = 1 everywhere).

Short of transforming a square section into a circular section, it's hard to see a
manual application for it, but some people might have a modeler to generate them.

It's a 2D finite object.

Syntax is :

nurbs { u_size, v_size [accuracy a_value]

 followed by the u_vsize*v_size 4D vectors (fourth coordinates is the weight, which
must not be negative),
as first line for v, second line for v and so on.

Minimal value for v_size and u_size is 2. The max value is up to your patience and
memory, as more points mean slowing down the render.

uv_mapping and clipped_by are supported.

And now for the good & bad news: this is not supported in hgpovray, but on my master
branch (because the rewrite of the code in the official master branch made it easier
to deals with the involved maths).

==== [Rendering...] ========================================================
Rendered 1228800 of 1228800 pixels (100%)
----------------------------------------------------------------------------
Render Statistics
Image Resolution 1280 x 960
----------------------------------------------------------------------------
Pixels:          1305600   Samples:          461097   Smpls/Pxl: 0.35
Rays:            1766697   Saved:                 0   Max Level: 1/10
----------------------------------------------------------------------------
Ray->Shape Intersection          Tests       Succeeded  Percentage
----------------------------------------------------------------------------
Box                             307149           45020     14.66
Cone/Cylinder                   178476           41510     23.26
Nurbs                          7234487         1006956     13.92
Bounding Box                  21742788        10255503     47.17
----------------------------------------------------------------------------
Shadow Ray Tests:           1760307   Succeeded:                139322
Shadow Cache Hits:           139038
----------------------------------------------------------------------------
----------------------------------------------------------------------------
Render Time:
  Photon Time:      No photons
  Radiosity Time:   No radiosity
  Trace Time:       0 hours  0 minutes 56 seconds (56.541 seconds)
              using 12 thread(s) with 610.511 CPU-seconds total
POV-Ray finished

Post a reply to this message

Attachments:
Download 'bb.png' (113 KB) Download 'bb.pov.txt' (2 KB)

Preview of image 'bb.png'

Am 23.07.2016 um 23:03 schrieb Le_Forgeron:
> Yep, real nurbs, without tesselation.
> 
> (and nurbs also mean b-spline, as b-spline are nurbs with weight = 1 everywhere).
> 
> Short of transforming a square section into a circular section, it's hard to see
> a manual application for it, but some people might have a modeler to generate them.

There are most certainly no modellers out there yet that support this
new POV-Ray syntax extension. Therefore...

@LanuHum:
Does Blender provide full support for NURBS? If so, then this looks like
an urgent job for you!

Post a reply to this message

Am 23.07.2016 um 23:03 schrieb Le_Forgeron:

> And now for the good & bad news: this is not supported in hgpovray,
> but on my master branch (because the rewrite of the code in the
> official master branch made it easier to deals with the involved maths).

To me that's mostly good news (though I guess it also means that there's
some code review and merging waiting for me to spend my very next batch
of fresh round tuits on.)

What's been bothering me about POV-Ray's Bezier patches is that we don't
have some kind of bezier mesh to support non-union CSG. Do you think you
can throw together a nurbs mesh primitive?

Post a reply to this message

Le 24/07/2016 04:13, clipka a écrit :
> What's been bothering me about POV-Ray's Bezier patches is that we don't
> have some kind of bezier mesh to support non-union CSG. Do you think you
> can throw together a nurbs mesh primitive?

what do you want ? or what is the need ?

It's a 2D finite surface, involving it in CSG does not seem to make sense (to me).
(it is rarely closed, until you glue many nurbs together)

It might be "easy" (might cost a few round tuits) to have an evaluation function like
for splines.

Something like

#declare Nu = nurbs { .... }

#for( V, 0, 1, 0.1 )
#for( U, 0, 1, 0.1 )

#declare Point = Nu.get_vertex( U, V );

#end
#end

For more round tuits, the evaluation of normal with Nu.get_normal( U, V ) can be
considered.

Would get_vertex & get_normal answer your request ?
Or did I misunderstand the need ?

Post a reply to this message

Am 24.07.2016 um 07:55 schrieb Le_Forgeron:
> Le 24/07/2016 04:13, clipka a écrit :
>> What's been bothering me about POV-Ray's Bezier patches is that we don't
>> have some kind of bezier mesh to support non-union CSG. Do you think you
>> can throw together a nurbs mesh primitive?
> 
> what do you want ? or what is the need ?
> 
> It's a 2D finite surface, involving it in CSG does not seem to make sense (to me).
> (it is rarely closed, until you glue many nurbs together)

... and that's exactly what I'd love to see. Just like you glue many
triangles together in a mesh.

Post a reply to this message

Le 24/07/2016 08:17, clipka a écrit :
> Am 24.07.2016 um 07:55 schrieb Le_Forgeron:
>> Le 24/07/2016 04:13, clipka a écrit :
>>> What's been bothering me about POV-Ray's Bezier patches is that we don't
>>> have some kind of bezier mesh to support non-union CSG. Do you think you
>>> can throw together a nurbs mesh primitive?
>>
>> what do you want ? or what is the need ?
>>
>> It's a 2D finite surface, involving it in CSG does not seem to make sense (to me).
>> (it is rarely closed, until you glue many nurbs together)
> 
> ... and that's exactly what I'd love to see. Just like you glue many
> triangles together in a mesh.
> 

So, do you want a "container" for multiple nurbs with additional "inside" property so
it can be used in further CSG operation ?
(assuming such container would assert that the collection of nurbs defines one or more
closed surfaces with non-zero enclosed volume(s))

Using the same approach as for mesh (inside_vector), it might be possible.
I just anticipate a high cpu cost.

On the same line, while we are at it, such container could also handle bicubic_patch
the same way.

Any suggestion of name for that container ?

Still any interest for nurbs.get_vertex() ? or can I forget it ?

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

> @LanuHum:
> Does Blender provide full support for NURBS? If so, then this looks like
> an urgent job for you!

It is very good that made Le Forgeron!
Le Forgeron, thank you!
Hair in Blender - NURBS.
There are also some tools for editing NURBS curves.
If it can be used in CSG - it is very good

:D

Post a reply to this message

Le 24/07/2016 11:31, LanuHum a écrit :
> Hair in Blender - NURBS.

Duck & Cover.

As illustrated in the first post, a simple scene with only 4 nurbs of degree 6 & 3, a
box and a cylinder took already 1 minute on 6+6 cores... and there is nothing fancy in
the scene. And I do not believe the box or the cylinder to cost.

The bounding box might helps a bit, but I predict a sky-rocketed render time if you
model any individual hair with nurb, short of modeling only Britney after the barber
shop.

Of course, not a problem if using nurbs for the head of hair, with some mapped
pigments or textures.

Post a reply to this message

"LanuHum" <Lan### [at] yandexru> wrote:
> clipka <ano### [at] anonymousorg> wrote:
>
> > @LanuHum:
> > Does Blender provide full support for NURBS? If so, then this looks like
> > an urgent job for you!
>
> It is very good that made Le Forgeron!
> Le Forgeron, thank you!
> Hair in Blender - NURBS.
> There are also some tools for editing NURBS curves.
> If it can be used in CSG - it is very good
>
> :D

Example:

Post a reply to this message

Attachments:
Download 'nurbs.jpg' (65 KB)

Preview of image 'nurbs.jpg'

Sorry! This is surface.
Nurbs surface also supported

Post a reply to this message

Attachments:
Download 'nurbs_surface.jpg' (192 KB)

Preview of image 'nurbs_surface.jpg'

Am 24.07.2016 um 11:31 schrieb LanuHum:
> clipka <ano### [at] anonymousorg> wrote:
> 
>> @LanuHum:
>> Does Blender provide full support for NURBS? If so, then this looks like
>> an urgent job for you!
> 
> It is very good that made Le Forgeron!
> Le Forgeron, thank you!
> Hair in Blender - NURBS.

Are you sure Blender hair uses NURBS /patches/ (which is what LeForgeron
has implemented) and not NURBS /curves/?

Post a reply to this message

Am 24.07.2016 um 09:08 schrieb Le_Forgeron:

> So, do you want a "container" for multiple nurbs with additional "inside" property
so it can be used in further CSG operation ?
> (assuming such container would assert that the collection of nurbs defines one or
more closed surfaces with non-zero enclosed volume(s))

You got it :)

> Using the same approach as for mesh (inside_vector), it might be possible.
> I just anticipate a high cpu cost.

Can't be worse than using a simple union of individual patches.

> On the same line, while we are at it, such container could also handle bicubic_patch
the same way.
> 
> Any suggestion of name for that container ?

"nurbs_mesh"?


> Still any interest for nurbs.get_vertex() ? or can I forget it ?

Sounds like a useful idea.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 24.07.2016 um 11:31 schrieb LanuHum:
> > clipka <ano### [at] anonymousorg> wrote:
> >
> >> @LanuHum:
> >> Does Blender provide full support for NURBS? If so, then this looks like
> >> an urgent job for you!
> >
> > It is very good that made Le Forgeron!
> > Le Forgeron, thank you!
> > Hair in Blender - NURBS.
>
> Are you sure Blender hair uses NURBS /patches/ (which is what LeForgeron
> has implemented) and not NURBS /curves/?

I realized this later, and wrote about it.
Blender has four primitive NURBS.
They can edit: transform vertices and extrude.
You can also create NURBS surfaces from NURBS curves using loft.
Create patches 4 x 4 - uncomfortable modeling.

Post a reply to this message

Attachments:
Download 'nurbs_surface1.jpg' (142 KB)

Preview of image 'nurbs_surface1.jpg'

clipka <ano### [at] anonymousorg> wrote:

> > Any suggestion of name for that container ?
>
> "nurbs_mesh"?


If it's a closed 3d shape composed of NURBS mesh(es), then maybe "envelope" to
differentiate and disambiguate from a (simple) open mesh?

Post a reply to this message

Am 24.07.2016 um 18:10 schrieb Bald Eagle:
> clipka <ano### [at] anonymousorg> wrote:
> 
>>> Any suggestion of name for that container ?
>>
>> "nurbs_mesh"?
> 
> If it's a closed 3d shape composed of NURBS mesh(es), then maybe "envelope" to
> differentiate and disambiguate from a (simple) open mesh?

Sounds far too vague and unrelated. Besides, I think it would be smart
to also support non-closed NURBS patch meshes, just like mesh also
supports non-closed triangle meshes.

Post a reply to this message

Le 24/07/2016 18:32, clipka a écrit :
> Am 24.07.2016 um 18:10 schrieb Bald Eagle:
>> clipka <ano### [at] anonymousorg> wrote:
>>
>>>> Any suggestion of name for that container ?
>>>
>>> "nurbs_mesh"?
>>
>> If it's a closed 3d shape composed of NURBS mesh(es), then maybe "envelope" to
>> differentiate and disambiguate from a (simple) open mesh?
> 
> Sounds far too vague and unrelated. Besides, I think it would be smart
> to also support non-closed NURBS patch meshes, just like mesh also
> supports non-closed triangle meshes.
> 

"package", "bundle", "parcel", "lot", "bunch" ?????

On the same way as mesh supports flat triangle and smooth triangle, I do not see why
the "object" holding nurbs couldn't also hold other 2D finite primitives.
To the risk of getting another (bad & slow) kind of mesh (as a collection of
triangles).

nurbs, bicubic_patch... may be some other objects could also be added ?

Post a reply to this message

Am 24.07.2016 um 19:19 schrieb Le_Forgeron:
> Le 24/07/2016 18:32, clipka a écrit :
>> Am 24.07.2016 um 18:10 schrieb Bald Eagle:
>>> clipka <ano### [at] anonymousorg> wrote:
>>>
>>>>> Any suggestion of name for that container ?
>>>>
>>>> "nurbs_mesh"?
>>>
>>> If it's a closed 3d shape composed of NURBS mesh(es), then maybe "envelope" to
>>> differentiate and disambiguate from a (simple) open mesh?
>>
>> Sounds far too vague and unrelated. Besides, I think it would be smart
>> to also support non-closed NURBS patch meshes, just like mesh also
>> supports non-closed triangle meshes.
>>
> 
> "package", "bundle", "parcel", "lot", "bunch" ?????
> 
> On the same way as mesh supports flat triangle and smooth triangle,
> I do not see why the "object" holding nurbs couldn't also hold other 2D finite
primitives.
> To the risk of getting another (bad & slow) kind of mesh (as a collection of
triangles).

I presume that the `nurbs_mesh` object's data structure and algorithms
would be optimized for nurbs patches, just like the `mesh` object's are
optimized for triangles.

Both triangle meshes and NURBS-based meshes have the property that any
one of them can be used to (approximately) represent arbitrary shapes.
It makes sense to support both, because each has its own unique
advantages and disadvantages, but any single object can be modelled
using just one of the two -- so it makes sense to design not just one
container to support both approaches, but to design different
containers, each optimized to support just one of them.

And even if the first implementation would be non-optimized and could
handle other 2D elements as well, it still makes sense to limit it to
NURBS patches, so that optimizations can easily be implemented in the
future.


As for having a generic container to combine surface-only primitives
into an object with a defined volume, I think that would be nice to have
as well, but that would be yet another thing (at least at the SDL level;
the NURBS-specific construct could initially be implemented by means of
such a more generic container, but as mentioned before, it would make
sense to provide a dedicated SDL syntax, so that future optimizations
are possible).

Post a reply to this message

On 24/07/2016 1:19 PM, Le_Forgeron wrote:
> Le 24/07/2016 18:32, clipka a écrit :
>> Am 24.07.2016 um 18:10 schrieb Bald Eagle:
>>> clipka <ano### [at] anonymousorg> wrote:
>>>
>>>>> Any suggestion of name for that container ?
>>>>
>>>> "nurbs_mesh"?
>>>
>>> If it's a closed 3d shape composed of NURBS mesh(es), then maybe "envelope" to
>>> differentiate and disambiguate from a (simple) open mesh?
>>
>> Sounds far too vague and unrelated. Besides, I think it would be smart
>> to also support non-closed NURBS patch meshes, just like mesh also
>> supports non-closed triangle meshes.
>>
>
> "package", "bundle", "parcel", "lot", "bunch" ?????
group

> On the same way as mesh supports flat triangle and smooth triangle, I do not see why
the "object" holding nurbs couldn't also hold other 2D finite primitives.
> To the risk of getting another (bad & slow) kind of mesh (as a collection of
triangles).
>
> nurbs, bicubic_patch... may be some other objects could also be added ?
>
light_group{}
nurb_group{}, nurbs_group{}

Moray modeller used group to mean union{} only, so you can include 
lights and still transform them.

Stephen S

Post a reply to this message

Am 24.07.2016 um 19:47 schrieb StephenS:

> light_group{}
> nurb_group{}, nurbs_group{}

Just as a side note, NURBS is both singular and plural ;)
NURBS = Non-Uniform Rational B-Spline(s)

(B-Splines, in turn, is not to be confused with Bezier Splines.)

Post a reply to this message

Le 24/07/2016 17:10, clipka a écrit :
> 
>> > Still any interest for nurbs.get_vertex() ? or can I forget it ?
> Sounds like a useful idea.
> 

Ok, done (with a different syntax, dot was not appropriate )

nurbs_vertex( NURBS_ID, U_Value, V_Value )
nurbs_normal( NURBS_ID, U_Value, V_Value )


I also removed some useless computations on the main core of nurbs, speed up a bit the
rendering.(less allocation, less computation)

----------------------------------------------------------------------------
Render Statistics
Image Resolution 1280 x 960
----------------------------------------------------------------------------
Pixels:          1305600   Samples:          789102   Smpls/Pxl: 0.60
Rays:            2094702   Saved:                 0   Max Level: 1/10
----------------------------------------------------------------------------
Ray->Shape Intersection          Tests       Succeeded  Percentage
----------------------------------------------------------------------------
Box                             336551           50706     15.07
Cone/Cylinder                  1918809          286999     14.96
Nurbs                          9422584         1377518     14.62
Sphere                         1045795          330840     31.64
Bounding Box                 119974750        36967270     30.81
----------------------------------------------------------------------------
Shadow Ray Tests:           2685134   Succeeded:                398144
Shadow Cache Hits:           395904
----------------------------------------------------------------------------
----------------------------------------------------------------------------
Render Time:
  Photon Time:      No photons
  Radiosity Time:   No radiosity
  Trace Time:       0 hours  0 minutes 38 seconds (38.230 seconds)
              using 12 thread(s) with 434.075 CPU-seconds total
POV-Ray finished

Post a reply to this message

Attachments:
Download 'bb.png' (183 KB) Download 'bb.pov.txt' (2 KB)

Preview of image 'bb.png'

When can I test?

Post a reply to this message

Le 24/07/2016 21:44, LanuHum a écrit :
> 
> When can I test?
> 

Now also available in hg-povray.

Post a reply to this message

Yay, NURBS!

Yippee!

=D

-- 
________________________________________

-Nekar Xenos-

Post a reply to this message

Does not work. Empty image. :(

#version 3.7;

#include "functions.inc"
global_settings {
    assumed_gamma 1.000000
    max_trace_level 3
    charset utf8
}
sky_sphere {
    pigment {rgb<0.051, 0.051, 0.051>}
}

#declare Default_texture = texture{pigment {rgb 0.8}}

#declare data_SurfPatch_ob =
nurbs {7,4 accuracy 0.01
 <-1.5000,-5.4790,0.0000> <-1.5000,-4.3181,2.0249> <-1.5000,-2.8825,0.0000>
<-1.5000,-1.5000,0.0000> <-1.5000,-0.5000,0.0000>
 <-1.5000,0.5000,0.0000> <-1.5000,1.5000,0.0000> <-0.5000,-5.4790,0.0000>
<-0.5000,-4.3181,0.0000>
 <-0.5000,-2.8825,1.7624> <-0.5000,-1.5000,0.0000> <-0.5000,-0.5000,1.0000>
<-0.5000,0.5000,1.0000>
 <-0.5000,1.5000,0.0000> <0.5000,-5.4790,0.0000> <0.5000,-4.3181,0.0000>
<0.5000,-2.8825,0.0000>
 <0.5000,-1.5000,1.1552> <0.5000,-0.5000,1.0000> <0.5000,0.5000,1.0000>
<0.5000,1.5000,0.0000>
 <1.5000,-5.4790,1.9780> <1.5000,-4.3181,0.0000> <1.5000,-2.8825,0.0000>
<1.5000,-1.5000,0.0000>
 <1.5000,-0.5000,0.0000> <1.5000,0.5000,0.0000> <1.5000,1.5000,0.0000>
texture{Default_texture}
}
object {data_SurfPatch_ob
    matrix <1.000000, 0.000000, 0.000000,  0.000000, -0.000000, -1.000000,
0.000000, 1.000000, -0.000000,  0.000000, -0.000000, -3.620508>
}

light_source {
    <4.08,5.9,-1.01>
    color rgb<1, 1, 1>
    fade_distance 29.9999828339
    fade_power 1
}
camera {
    perspective
    location  <0,0,0>
    look_at  <0,0,-1>
    right <-1.7777777777777777, 0, 0>
    up <0, 1, 0>
    angle  49.134343
    rotate  <-26.440706, 46.691945, -0.000003>
    translate <7.481132, 5.343666, 6.507640>
}

Post a reply to this message

"LanuHum" <Lan### [at] yandexru> wrote:
> Does not work. Empty image. :(

Sorry!I do not put a fourth option 'W'!
It works, but the model is different from the render result.

Post a reply to this message

Attachments:
Download 'nurbs.jpg' (131 KB)

Preview of image 'nurbs.jpg'

"LanuHum" <Lan### [at] yandexru> wrote:
> "LanuHum" <Lan### [at] yandexru> wrote:
> > Does not work. Empty image. :(
>
> Sorry!I do not put a fourth option 'W'!
> It works, but the model is different from the render result.

Compare renderings:

Post a reply to this message

Attachments:
Download 'nurbs_diff.jpg' (99 KB)

Preview of image 'nurbs_diff.jpg'

Le 29/07/2016 à 18:11, LanuHum a écrit :
> "LanuHum" <Lan### [at] yandexru> wrote:
>> "LanuHum" <Lan### [at] yandexru> wrote:
>>> Does not work. Empty image. :(
>>
>> Sorry!I do not put a fourth option 'W'!
>> It works, but the model is different from the render result.
> 
> Compare renderings:
> 
> 

Can you provide the set of control points ?

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:

> Can you provide the set of control points ?

Yes!
#version 3.7;

#include "functions.inc"
global_settings {
    assumed_gamma 1.000000
    max_trace_level 3
    charset utf8
}
sky_sphere {
    pigment {rgb<0.051, 0.051, 0.051>}
}

#declare Default_texture = texture{pigment {rgb 0.8}}

#declare Material = texture{
    pigment{color srgbft <0.8000,0.0946,0.0441,0.0000,0.0000>}
    finish{
        diffuse 0.8000
        brilliance 1.8000
          }
}
#declare data_SurfPatch_ob =
nurbs {7,7 accuracy 0.01
 <-4.1894,-5.4790,0.0000,1.0000> <-4.1894,-4.3181,2.0249,1.0000>
<-4.1894,-2.8825,0.0000,1.0000> <-4.1894,-1.5000,0.0000,1.0000>
<-4.1894,-0.5000,0.0000,1.0000> <-4.1894,0.5000,0.0000,1.0000>
<-4.1894,1.5000,0.0000,1.0000> <-2.6808,-4.8585,0.6794,1.0000>
 <-2.6808,-4.3181,2.0249,1.0000> <-2.6808,-2.8825,0.0000,1.0000>
<-2.6808,-1.5000,3.2519,1.0000> <-2.6808,-0.5000,0.0000,1.0000>
<-2.6808,0.5000,0.0000,1.0000> <-2.6808,1.5000,3.2103,1.0000>
<-1.5000,-5.4790,0.0000,1.0000>
 <-1.5000,-4.3181,2.0249,1.0000> <-1.5000,-2.8825,0.0000,1.0000>
<-1.5000,-1.5000,0.0000,1.0000> <-1.5000,-0.5000,1.2319,1.0000>
<-1.5000,0.5000,0.0000,1.0000> <-1.5000,1.5000,0.0000,1.0000>
<-0.5000,-5.4790,0.0000,1.0000>
 <-0.5000,-4.3181,0.0000,1.0000> <-0.5000,-2.8825,1.7624,1.0000>
<-0.5000,-1.5000,0.0000,1.0000> <-0.5000,-0.5000,1.0000,1.0000>
<-0.5000,0.5000,1.0000,1.0000> <-0.5000,1.5000,0.0000,1.0000>
<0.5000,-5.4790,0.0000,1.0000>
 <0.5000,-4.3181,0.0000,1.0000> <0.5000,-2.8825,0.0000,1.0000>
<0.5000,-1.5000,1.1552,1.0000> <0.5000,-0.5000,1.0000,1.0000>
<0.5000,0.5000,1.0000,1.0000> <0.5000,1.5000,0.0000,1.0000>
<1.5000,-5.4790,1.9780,1.0000>
 <1.5000,-4.3181,0.0000,1.0000> <1.5000,-2.8825,1.7335,1.0000>
<1.5000,-1.5000,0.0000,1.0000> <1.5000,-0.5000,0.0000,1.0000>
<1.5000,0.5000,0.0000,1.0000> <1.5000,1.5000,1.5217,1.0000>
<2.9668,-5.4790,-0.2469,1.0000>
 <2.9668,-4.3181,0.0000,1.0000> <2.9668,-2.8825,0.0000,1.0000>
<2.9668,-1.5000,0.0000,1.0000> <2.9668,-0.5000,-2.9599,1.0000>
<2.9668,0.5000,0.0000,1.0000> <2.9668,1.5000,0.0000,1.0000>
texture{Material}
}
object {data_SurfPatch_ob
    matrix <1.000000, 0.000000, 0.000000,  0.000000, -0.000000, -1.000000,
0.000000, 1.000000, -0.000000,  0.000000, -0.000000, -3.620508>
}

light_source {
    <4.08,5.9,-1.01>
    color rgb<1, 1, 1>
    fade_distance 29.9999828339
    fade_power 1
}
camera {
    perspective
    location  <0,0,0>
    look_at  <0,0,-1>
    right <-1.7777777777777777, 0, 0>
    up <0, 1, 0>
    angle  49.134343
    rotate  <-26.440706, 46.691945, -0.000003>
    translate <7.481132, 5.343666, 6.507640>
}

But, I have found the cause elsewhere.
Blender has a nurbs option warrant.
Increasing the value closer look, but the maximum value of 6 does not give an
exact match. 7 or 8 is required, but the maximum value of 6. :(

Post a reply to this message

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

Preview of image 'nurbs_order.jpg'

Le 29/07/2016 à 18:37, LanuHum a écrit :
> But, I have found the cause elsewhere.
> Blender has a nurbs option warrant.
> Increasing the value closer look, but the maximum value of 6 does not give an
> exact match. 7 or 8 is required, but the maximum value of 6. :(
> 

Ok, so all is fine, and no need to investigate, right ?

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:
> Le 29/07/2016 à 18:37, LanuHum a écrit :
> > But, I have found the cause elsewhere.
> > Blender has a nurbs option warrant.
> > Increasing the value closer look, but the maximum value of 6 does not give an
> > exact match. 7 or 8 is required, but the maximum value of 6. :(
> >
>
> Ok, so all is fine, and no need to investigate, right ?

Your wish. But your nurbs difficult terrain models. Blender nurbs - good terrain
model. Your model also need a order_u and order_v. :)
I added nurbs export code to Povray-HG. Mr can move it to the official version
of the exporter, if it becomes available in the Povray-3.7.1.

Post a reply to this message

Le 29/07/2016 à 20:01, LanuHum a écrit :
> Le_Forgeron <jgr### [at] freefr> wrote:
>> Le 29/07/2016 à 18:37, LanuHum a écrit :
>>> But, I have found the cause elsewhere.
>>> Blender has a nurbs option warrant.
>>> Increasing the value closer look, but the maximum value of 6 does not give an
>>> exact match. 7 or 8 is required, but the maximum value of 6. :(
>>>
>>
>> Ok, so all is fine, and no need to investigate, right ?
> 
> Your wish. But your nurbs difficult terrain models. Blender nurbs - good terrain
> model. Your model also need a order_u and order_v. :)
> I added nurbs export code to Povray-HG. Mr can move it to the official version
> of the exporter, if it becomes available in the Povray-3.7.1.


That request opens more things than expected: unclamped vs clamped ( closed vs opened
curve) and combination of different options by direction(u,v)

I would need a few more round tuits and my stock is low.

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:

> I would need a few more round tuits and my stock is low.

:))))))
And who is now easy to live?

Post a reply to this message

Le 30/07/2016 à 13:13, LanuHum a écrit :
> Le_Forgeron <jgr### [at] freefr> wrote:
> 
>> I would need a few more round tuits and my stock is low.
> 
> :))))))
> And who is now easy to live?
> 

For the technically inclined, it would involves replacing the de Casteljau's algorithm
with de Boor's algorithm.

And it breaks a lot of things, including the weights used at each iteration of the leg
reduction.

Post a reply to this message

On 24.07.2016 4:13, clipka wrote:

> What's been bothering me about POV-Ray's Bezier patches is that we don't
> have some kind of bezier mesh to support non-union CSG. Do you think you
> can throw together a nurbs mesh primitive?

 From what I remember of B-splines I think a B-spline patch
of degree d is essentially the same thing as a mesh of bezier
patches of degree d (with the smoothest possible transition
where the bezier control blocks are joined).

So I'm not sure an extra mesh object is needed since you can simply
increase the number of control points. Or maybe I misunderstood?

Now that I think about it I didn't see any mention of degree,
so maybe the new NURBS implementation is for degree 2 only?

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 24.07.2016 um 11:31 schrieb LanuHum:
> > clipka <ano### [at] anonymousorg> wrote:
> >
> >> @LanuHum:
> >> Does Blender provide full support for NURBS? If so, then this looks like
> >> an urgent job for you!
> >
> > It is very good that made Le Forgeron!
> > Le Forgeron, thank you!
> > Hair in Blender - NURBS.
>
> Are you sure Blender hair uses NURBS /patches/ (which is what LeForgeron
> has implemented) and not NURBS /curves/?


Indeed Blender hair does not use NURBS. it's some kind of pixel/screen space
geometry, derived from particles historically, I believe. It used to drop
calculations for any hair that looked smaller than one pixel fraction on screen,
according to antialiasing settings.

At one point, Blender NURBS were implemented from an external open source
library : libNurbana
https://sourceforge.net/projects/nurbana/?source=directory
Don't know if it's still the case.

I think what Lanuhum intended to say is that he would chose povray NURBS to
export Blender Hair. Personnally I find sphere_sweep a fine compromise though by
far slower than the blender native option.

POV-Ray NURBS however, are a GREAT addition for other uses, and I indeed hope
that I will be able to integrate Lanuhum's exporter branch script lines inside
official version without breaking things.

THANKS a lot to Le Forgeron, Clipka, and the POV-Ray developers !

Post a reply to this message

Am 01.08.2016 um 01:51 schrieb Christian Froeschlin:
> On 24.07.2016 4:13, clipka wrote:
> 
>> What's been bothering me about POV-Ray's Bezier patches is that we don't
>> have some kind of bezier mesh to support non-union CSG. Do you think you
>> can throw together a nurbs mesh primitive?
> 
> From what I remember of B-splines I think a B-spline patch
> of degree d is essentially the same thing as a mesh of bezier
> patches of degree d (with the smoothest possible transition
> where the bezier control blocks are joined).
> 
> So I'm not sure an extra mesh object is needed since you can simply
> increase the number of control points. Or maybe I misunderstood?

You misunderstood indeed. While B-splines and Bezier splines are indeed
equivalent (in the sense that whatever you can model with one you can
also model with the other), this is not true for NURBS (non-uniform
rational B-splines), as they are a more general superset of B-splines.
As such they obviously need more parameters than plain vanilla B-splines
or Bezier splines, and are also more difficult to compute.

It is therefore reasonable to presume that a dedicated Bezier patch mesh
would be more performant than a NURBS patch mesh.

Post a reply to this message

Le 01/08/2016 à 12:19, clipka a écrit :
> Am 01.08.2016 um 01:51 schrieb Christian Froeschlin:
>> On 24.07.2016 4:13, clipka wrote:
>>
>>> What's been bothering me about POV-Ray's Bezier patches is that we don't
>>> have some kind of bezier mesh to support non-union CSG. Do you think you
>>> can throw together a nurbs mesh primitive?
>>
>> From what I remember of B-splines I think a B-spline patch
>> of degree d is essentially the same thing as a mesh of bezier
>> patches of degree d (with the smoothest possible transition
>> where the bezier control blocks are joined).
>>
>> So I'm not sure an extra mesh object is needed since you can simply
>> increase the number of control points. Or maybe I misunderstood?
> 
> You misunderstood indeed. While B-splines and Bezier splines are indeed
> equivalent (in the sense that whatever you can model with one you can
> also model with the other), this is not true for NURBS (non-uniform
> rational B-splines), as they are a more general superset of B-splines.
> As such they obviously need more parameters than plain vanilla B-splines
> or Bezier splines, and are also more difficult to compute.
> 
> It is therefore reasonable to presume that a dedicated Bezier patch mesh
> would be more performant than a NURBS patch mesh.
> 

for the time being, what I called "nurbs" object is actually a
non-uniform-rational-bezier :
* the order of the rational B-spline is the number of control point (it's an implict
value), so actually that a ration Bezier.

It is non-uniform before the also implicit (hard-coded) knot vectors are not uniform
(because bezier are clamped: passing through the first and last control point)
(knot vector would be something along 0{order), 1/n, 2/n, ..., n-1/n, 1{order} , not
something uniform as 0, 1, 2, ... m-1, m )
It is rational because there is a weight on control points.

Sorry for the false joy, maybe I should rename it to "nurbz" (Non Uniform Rational
BeZier) and try to provide a real nurbs.
But for the time being, all I could provide easily for nurbs would be a function to
compute the vertex for any u,v value. Even that would apply to only the clamped on
each side of nurbs. (and "easily" is not really the right term)
(nurbs can be clamped, opened or closed; and while "closed" on a direction apply to
both ends, the alternative clamped or opened could be different for each extremity (or
they can be the same).
I cannot so far even compute the normal at a u,v value for a nurbs.
And having a solver for ray intersection seems even more difficult.

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:

> I cannot so far even compute the normal at a u,v value for a nurbs.
> And having a solver for ray intersection seems even more difficult.


Sorry, I do not quite understand your conversations

Post a reply to this message

Attachments:
Download 'splinemesh.java.txt' (51 KB)

Le 01/08/2016 à 22:24, LanuHum a écrit :
> Le_Forgeron <jgr### [at] freefr> wrote:
> 
>> I cannot so far even compute the normal at a u,v value for a nurbs.
>> And having a solver for ray intersection seems even more difficult.
> 
> 
> Sorry, I do not quite understand your conversations
> 

Thanks for that code, but the computed normal is an approximation, not the real value.

It's like computing the derivative of a polynomial expression by sampling values
around the point of interest, instead of actually performing the derivation of the
equation: you get an approximated value, but no formula.

Post a reply to this message

Le 01/08/2016 à 11:08, Mr a écrit :
> At one point, Blender NURBS were implemented from an external open source
> library : libNurbana
> https://sourceforge.net/projects/nurbana/?source=directory
> Don't know if it's still the case.

thanks for the link, I will have a look later.

Post a reply to this message

On 01.08.2016 17:51, Le_Forgeron wrote:

> for the time being, what I called "nurbs" object is actually a
non-uniform-rational-bezier :
> * the order of the rational B-spline is the number of control point (it's an implict
value), so actually that a ration Bezier.

Thanks for the clarification that makes sense.

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:
> Le 01/08/2016 à 11:08, Mr a écrit :
> > At one point, Blender NURBS were implemented from an external open source
> > library : libNurbana
> > https://sourceforge.net/projects/nurbana/?source=directory
> > Don't know if it's still the case.
>
> thanks for the link, I will have a look later.

A blender dev told me it's no longer the case, the Blender NURBS code is now
specific. but both code sources are probably good references.

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:

> Thanks for that code, but the computed normal is an approximation, not the real
value.
>
> It's like computing the derivative of a polynomial expression by sampling values
around the point of interest, instea
d of actually performing the derivation of the equation: you get an approximated
value, but no formula.

polynom bernstein no?

Post a reply to this message

Attachments:
Download 'beziermesh.java.txt' (10 KB)

Le 30/07/2016 à 13:13, LanuHum a écrit :
> Le_Forgeron <jgr### [at] freefr> wrote:
> 
>> I would need a few more round tuits and my stock is low.
> 
> :))))))
> And who is now easy to live?
> 
> 
> 

A bit of progress.

The number on the image is the order (aka degree+1) of the curve used in the Nurbs.

I hope you are ready to handle the knot vectors, because I gave up the
user-friendliness of opened/clamped/closed

nu7 is similar to the rational bezier that was previously available. (because with 7
control points, at order 7, the nurbs (with the knot vectors that were provided) is a
single rational bezier)

nu3 is more similar to your provided picture, or it could be nu4.



Still to do: implement the computation of normal (I found a nice formula, but I lack
the time to code it), not used so far.

Also attached is the SDL scene with what is the equivalent of Jar-Jar in front of the
Chamber:
I do not know yet who is Palpatine, but there is a big step towards the dark side of
the Force.

Because the nurbs is transformed into a mesh (in the SDL so far).

Post a reply to this message

Attachments:
Download 'nu7.png' (40 KB) Download 'nu6.png' (43 KB) Download 'nu5.png' (45 KB) Download 'nu4.png' (47 KB) Download 'nu3.png' (56 KB) Download 'nu2.png' (79 KB) Download 'nurbsmesh.inc.txt' (2 KB) Download 'nu.pov.txt' (4 KB)

Preview of image 'nu7.png'

Preview of image 'nu6.png'

Preview of image 'nu5.png'

Preview of image 'nu4.png'

Preview of image 'nu3.png'

Preview of image 'nu2.png'

Le_Forgeron <jgr### [at] freefr> wrote:

>
> Also attached is the SDL scene with what is the equivalent of Jar-Jar in front of
the Chamber:
> I do not know yet who is Palpatine, but there is a big step towards the dark side of
the Force.
>

Deep Purple:
Child in time
"Sweet child in time
You'll see the line
The line that's drawn between
Good and bad

See the blind man
Shooting at the world
Bullets flying
Ohh taking toll

If you've been bad
Oh Lord I bet you have
And you've not been hit
Oh by flying lead

You'd better close your eyes
Ooohhhh bow your head
Wait for the ricochet"


> Because the nurbs is transformed into a mesh (in the SDL so far).

In the universe there are objects with sharp corners. I'm glad you saw them.

:)))))))))

Post a reply to this message

#declare ORDER=clock;
#declare DEN=8-ORDER;
#declare OBJE=
nurbs {ORDER,ORDER,7,7,
#for(C,0,1,1)
#for(B,1,ORDER-1,1)
0,
#end
#for(A,0,1,1/DEN)
A,
#end
#for(B,1,ORDER-1,1)


if u != v ???
if nurbs{3,9,3,9} ???
Error.

Post a reply to this message

Le 04/09/2016 à 20:16, LanuHum a écrit :
> #declare ORDER=clock;
> #declare DEN=8-ORDER;
> #declare OBJE=
> nurbs {ORDER,ORDER,7,7,
> #for(C,0,1,1)
> #for(B,1,ORDER-1,1)
> 0,
> #end
> #for(A,0,1,1/DEN)
> A,
> #end
> #for(B,1,ORDER-1,1)
> 
> 
> if u != v ???
> if nurbs{3,9,3,9} ???
> Error.
> 
> 
> 

Of course "error", That part describes the know vector for each direction.
What did you expect ?

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:
> Le 04/09/2016 à 20:16, LanuHum a écrit :
> > #declare ORDER=clock;
> > #declare DEN=8-ORDER;
> > #declare OBJE=
> > nurbs {ORDER,ORDER,7,7,
> > #for(C,0,1,1)
> > #for(B,1,ORDER-1,1)
> > 0,
> > #end
> > #for(A,0,1,1/DEN)
> > A,
> > #end
> > #for(B,1,ORDER-1,1)
> >
> >
> > if u != v ???
> > if nurbs{3,9,3,9} ???
> > Error.
> >
> >
> >
>
> Of course "error", That part describes the know vector for each direction.
> What did you expect ?

I was expecting a rational decision. If the length is 1000, and the width is
0.1. Why do I need the same division?

Post a reply to this message

Le 04/09/2016 à 21:47, LanuHum a écrit :
> Le_Forgeron <jgr### [at] freefr> wrote:
>> Le 04/09/2016 à 20:16, LanuHum a écrit :
>>> #declare ORDER=clock;
>>> #declare DEN=8-ORDER;
>>> #declare OBJE=
>>> nurbs {ORDER,ORDER,7,7,
>>> #for(C,0,1,1)
>>> #for(B,1,ORDER-1,1)
>>> 0,
>>> #end
>>> #for(A,0,1,1/DEN)
>>> A,
>>> #end
>>> #for(B,1,ORDER-1,1)
>>>
>>>
>>> if u != v ???
>>> if nurbs{3,9,3,9} ???
>>> Error.
>>>
>>>
>>>
>>
>> Of course "error", That part describes the know vector for each direction.
>> What did you expect ?
>
> I was expecting a rational decision. If the length is 1000, and the width is
> 0.1. Why do I need the same division?

This is SDL. It was used for that nurbs to generate the knot vectors.

You can use whatever knot vectors you want (as long as valid for knot 
vector).

I won't explain knot vectors.

Post a reply to this message

Le 26/07/2016 à 19:06, Nekar Xenos a écrit :
> Yay, NURBS!

And now with normal computation too, in Hgpovray (branch Hgpovray of
https://github.com/LeForgeron/povray.git ), if someone ever need it
(what is a smooth_triangle ?)

That should finish that nurbs part... oh wait, documentation is still
not done... Winter is coming.

Post a reply to this message

Attachments:
Download 'nu.pov.txt' (6 KB) Download 'nu5.png' (161 KB) Download 'nu4.png' (184 KB) Download 'nu3.png' (189 KB) Download 'nu2.png' (198 KB) Download 'nu1.png' (217 KB) Download 'nu0.png' (217 KB)

Preview of image 'nu5.png'

Preview of image 'nu4.png'

Preview of image 'nu3.png'

Preview of image 'nu2.png'

Preview of image 'nu1.png'

Preview of image 'nu0.png'