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