 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 24.07.2016 um 11:31 schrieb LanuHum:
> clipka <ano### [at] anonymous org> 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'
|
|
| |
| |
|
|
|
|
| |
