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'

Le_Forgeron <jgr### [at] freefr> wrote:
> 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.

I can not build its own version of Rosa-Linux.
If:
../configure --with-x COMPILED_BY="Lanuhum" LIBS="-lboost_system -lboost_thread
-lboost_date_time"

leonid@lanucomp ~/workspace/build/povray (Hg-povray) $ ./configure --with-x
--prefix=/usr COMPILED_BY="Lanuhum" LIBS="-lboost_system -lboost_thread"

===============================================================================
Configure POV-Ray version 3.7.0
===============================================================================

This is an unofficial version compiled by:
 Lanuhum
The POV-Ray Team(tm) is not responsible for supporting this version.

Environment
-----------
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking whether $C_INCLUDE_PATH contains the "." path... no
checking whether $CPLUS_INCLUDE_PATH contains the "." path... no

Programs
--------
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/home/leonid/workspace/build/povray':
configure: error: C compiler cannot create executables
See `config.log' for more details

If:
../configure --with-x COMPILED_BY="Lanuhum"
make

lots of undefined reference to boost


The official version I built using CMake.
Your version CMake does not want to build:

leonid@lanucomp ~/workspace/programming/povray_animator/povray $ LC_ALL=C make
[  0%] Building CXX object CMakeFiles/povray.dir/source/pov_mem.cpp.o
In file included from
/home/leonid/workspace/programming/povray_animator/hgpovray/source/backend/control/messagefactory.h:39:0,
                 from
/home/leonid/workspace/programming/povray_animator/hgpovray/source/backend/frame.h:59,
                 from
/home/leonid/workspace/programming/povray_animator/hgpovray/source/pov_mem.cpp:36:
/home/leonid/workspace/programming/povray_animator/hgpovray/source/backend/control/renderbackend.h:112:34:
error: template argument 2 is invalid
   map<SceneId, shared_ptr<Scene> > scenes;
                                  ^
/home/leonid/workspace/programming/povray_animator/hgpovray/source/backend/control/renderbackend.h:112:34:
error: template argument 4 is invalid
/home/leonid/workspace/programming/povray_animator/hgpovray/source/backend/control/renderbackend.h:113:32:
error: template argument 2 is invalid
   map<ViewId, shared_ptr<View> > views;
                                ^
/home/leonid/workspace/programming/povray_animator/hgpovray/source/backend/control/renderbackend.h:113:32:
error: template argument 4 is invalid
In file included from
/home/leonid/workspace/programming/povray_animator/hgpovray/source/pov_mem.cpp:36:0:
/home/leonid/workspace/programming/povray_animator/hgpovray/source/backend/frame.h:1273:3:
error: reference to 'shared_ptr' is ambiguous
   shared_ptr<SubsurfaceInterior> subsurface;

Perhaps I missed something. I do not see. :(

Post a reply to this message

Le 09/10/2016 à 22:05, LanuHum a écrit :
> Le_Forgeron <jgr### [at] freefr> wrote:
>> 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.

> Programs
> --------
> checking for gcc... gcc
> checking whether the C compiler works... no
> configure: error: in `/home/leonid/workspace/build/povray':
> configure: error: C compiler cannot create executables
> See `config.log' for more details
>

>
> Perhaps I missed something. I do not see. :(
>

First fix the first reported problem:
* why do you need -lboost_date_time" ?
* See config.log and get C compiler to work.
* why do you need --with-x ?

My usual sequence is :
* cd unix
* ./prebuild.sh
* cd ..
* ./configure COMPILED_BY="LanuHum" LIBS="-lboost_system -lboost_thread"
* make -j 4

Have you installed boost for development ? all of it ?

Post a reply to this message

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


>
> Have you installed boost for development ?

Yes. I have successfully built the official Povray.

> My usual sequence is :
> * cd unix
> * ./prebuild.sh
> * cd ..
> * ./configure COMPILED_BY="LanuHum" LIBS="-lboost_system -lboost_thread"
> * make -j 4
>

To do so:

leonid@lanucomp ~ $ cd /home/leonid/workspace/build/povray/unix
leonid@lanucomp ~/workspace/build/povray/unix (Hg-povray) $ ./prebuild.sh
Detected autoconf 2.69
Detected automake 1.15
Create ../AUTHORS
Create ../ChangeLog
Create ../configure.ac
Create ../COPYING
Create ../NEWS
Create ../README
Create ../VERSION
Create ../povray.1
Create ../povray.conf
Create ../scripts/
Create ../ini/
Create ../include/
Create ../scenes/
Create ../INSTALL
Create ../icons/file_inc_crystal_32.png
Create ../icons/povray_16.png
Create ../icons/file_pov_classic_16.png
Create ../icons/file_pov_classic_32.png
Create ../icons/file_inc_classic_32.png
Create ../icons/file_inc_slick_32.png
Create ../icons/file_inc_classic_16.png
Create ../icons/file_inc_classic_64.png
Create ../icons/file_inc_slick_48.png
Create ../icons/povray_64.png
Create ../icons/file_pov_crystal_32.png
Create ../icons/file_inc_crystal_64.png
Create ../icons/povray_48.png
Create ../icons/file_pov_slick_32.png
Create ../icons/file_pov_slick_16.png
Create ../icons/file_inc_classic_48.png
Create ../icons/file_inc_crystal_48.png
Create ../icons/file_pov_crystal_48.png
Create ../icons/file_pov_classic_48.png
Create ../icons/file_inc_slick_64.png
Create ../icons/file_pov_crystal_16.png
Create ../icons/file_pov_classic_64.png
Create ../icons/file_pov_crystal_64.png
Create ../icons/file_inc_crystal_16.png
Create ../icons/file_pov_slick_48.png
Create ../icons/file_pov_slick_64.png
Create ../icons/povray_32.png
Create ../icons/file_inc_slick_16.png
Create ../doc/html
Create ./Makefile.am
Create ../kde_install.sh
Create ../povray.ini.in
Create ../Makefile.am
Create ../bootstrap
Create ../source/Makefile.am
Create ../vfe/Makefile.am
Run ../bootstrap
+ rm -f config.log config.status
+ aclocal -I .
configure.ac:302: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in
body
.../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from...
.../../lib/autoconf/general.m4:2590: _AC_COMPILE_IFELSE is expanded from...
.../../lib/autoconf/general.m4:2606: AC_COMPILE_IFELSE is expanded from...
.../../lib/m4sugar/m4sh.m4:639: AS_IF is expanded from...
.../../lib/autoconf/general.m4:2031: AC_CACHE_VAL is expanded from...
.../../lib/autoconf/general.m4:2052: AC_CACHE_CHECK is expanded from...
unix/config/ax_boost_thread.m4:32: AX_BOOST_THREAD is expanded from...
configure.ac:302: the top level
+ autoheader --warnings=all
configure.ac:302: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in
body
.../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from...
.../../lib/autoconf/general.m4:2590: _AC_COMPILE_IFELSE is expanded from...
.../../lib/autoconf/general.m4:2606: AC_COMPILE_IFELSE is expanded from...
.../../lib/m4sugar/m4sh.m4:639: AS_IF is expanded from...
.../../lib/autoconf/general.m4:2031: AC_CACHE_VAL is expanded from...
.../../lib/autoconf/general.m4:2052: AC_CACHE_CHECK is expanded from...
unix/config/ax_boost_thread.m4:32: AX_BOOST_THREAD is expanded from...
configure.ac:302: the top level
+ automake --add-missing --warnings=all
configure.ac:302: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in
body
.../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from...
.../../lib/autoconf/general.m4:2590: _AC_COMPILE_IFELSE is expanded from...
.../../lib/autoconf/general.m4:2606: AC_COMPILE_IFELSE is expanded from...
.../../lib/m4sugar/m4sh.m4:639: AS_IF is expanded from...
.../../lib/autoconf/general.m4:2031: AC_CACHE_VAL is expanded from...
.../../lib/autoconf/general.m4:2052: AC_CACHE_CHECK is expanded from...
unix/config/ax_boost_thread.m4:32: AX_BOOST_THREAD is expanded from...
configure.ac:302: the top level
/usr/share/automake-1.15/am/library.am: warning: 'libpovray.a': linking
libraries using a non-POSIX
/usr/share/automake-1.15/am/library.am: archiver requires 'AM_PROG_AR' in
'configure.ac'
source/Makefile.am:32:   while processing library 'libpovray.a'
/usr/share/automake-1.15/am/library.am: warning: 'libvfe.a': linking libraries
using a non-POSIX
/usr/share/automake-1.15/am/library.am: archiver requires 'AM_PROG_AR' in
'configure.ac'
vfe/Makefile.am:32:   while processing library 'libvfe.a'
+ autoconf --warnings=all
configure.ac:295: warning: The macro `AC_LANG_SAVE' is obsolete.
configure.ac:295: You should run autoupdate.
.../../lib/autoconf/lang.m4:125: AC_LANG_SAVE is expanded from...
unix/config/acx_pthread.m4:78: ACX_PTHREAD is expanded from...
configure.ac:295: the top level
configure.ac:295: warning: The macro `AC_LANG_C' is obsolete.
configure.ac:295: You should run autoupdate.
.../../lib/autoconf/c.m4:72: AC_LANG_C is expanded from...
unix/config/acx_pthread.m4:78: ACX_PTHREAD is expanded from...
configure.ac:295: the top level
configure.ac:295: warning: The macro `AC_TRY_LINK' is obsolete.
configure.ac:295: You should run autoupdate.
.../../lib/autoconf/general.m4:2687: AC_TRY_LINK is expanded from...
unix/config/acx_pthread.m4:78: ACX_PTHREAD is expanded from...
configure.ac:295: the top level
configure.ac:295: warning: The macro `AC_LANG_RESTORE' is obsolete.
configure.ac:295: You should run autoupdate.
.../../lib/autoconf/lang.m4:134: AC_LANG_RESTORE is expanded from...
unix/config/acx_pthread.m4:78: ACX_PTHREAD is expanded from...
configure.ac:295: the top level
configure.ac:302: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in
body
.../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from...
.../../lib/autoconf/general.m4:2590: _AC_COMPILE_IFELSE is expanded from...
.../../lib/autoconf/general.m4:2606: AC_COMPILE_IFELSE is expanded from...
.../../lib/m4sugar/m4sh.m4:639: AS_IF is expanded from...
.../../lib/autoconf/general.m4:2031: AC_CACHE_VAL is expanded from...
.../../lib/autoconf/general.m4:2052: AC_CACHE_CHECK is expanded from...
unix/config/ax_boost_thread.m4:32: AX_BOOST_THREAD is expanded from...
configure.ac:302: the top level
+ cat ./configure
+ sed -e 's,configure.gnu  --help=recursive,& --srcdir=$ac_srcdir,g' -e 's,\(cd
\)\($ac_\)\(pop\)*\(dir\),\1"\2\3\4",g' -e
's,$am_aux_dir/missing,\\"$am_aux_dir\\"/missing,g'
+ mv -f ./configure.tmp ./configure
+ chmod +x ./configure
+ rm -f -r ./autom4te.cache
leonid@lanucomp ~/workspace/build/povray/unix (Hg-povray) $ cd ..
leonid@lanucomp ~/workspace/build/povray (Hg-povray) $ ./configure
COMPILED_BY="LanuHum" LIBS="-lboost_system -lboost_thread"

===============================================================================
Configure POV-Ray version 3.7.0
===============================================================================

This is an unofficial version compiled by:
 LanuHum
The POV-Ray Team(tm) is not responsible for supporting this version.

Environment
-----------
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking whether $C_INCLUDE_PATH contains the "." path... no
checking whether $CPLUS_INCLUDE_PATH contains the "." path... no

Programs
--------
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/home/leonid/workspace/build/povray':
configure: error: C compiler cannot create executables
See `config.log' for more details

config.log:

This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by POV-Ray configure 3.7.0, which was
generated by GNU Autoconf 2.69.  Invocation command line was

  $ ./configure COMPILED_BY=LanuHum LIBS=-lboost_system -lboost_thread

## --------- ##
## Platform. ##
## --------- ##

hostname = lanucomp
uname -m = x86_64
uname -r = 4.1.33-nrj-desktop-1rosa-x86_64
uname -s = Linux
uname -v = #1 SMP PREEMPT Sun Sep 18 20:20:09 UTC 2016

/usr/bin/uname -p = unknown
/bin/uname -X     = unknown

/bin/arch              = unknown
/usr/bin/arch -k       = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo      = unknown
/bin/machine           = unknown
/usr/bin/oslevel       = unknown
/bin/universe          = unknown

PATH: /usr/bin
PATH: /bin
PATH: /usr/local/bin
PATH: /usr/X11R6/bin/
PATH: /usr/games
PATH: /usr/lib/qt4/bin
PATH: /home/leonid/.local/bin
PATH: /home/leonid/bin


## ----------- ##
## Core tests. ##
## ----------- ##

configure:3706: result:
===============================================================================
Configure POV-Ray version 3.7.0
===============================================================================

This is an unofficial version compiled by:
 LanuHum
The POV-Ray Team(tm) is not responsible for supporting this version.
configure:3727: result:
Environment
-----------
configure:3736: checking build system type
configure:3750: result: x86_64-unknown-linux-gnu
configure:3770: checking host system type
configure:3783: result: x86_64-unknown-linux-gnu
configure:3820: checking for a BSD-compatible install
configure:3888: result: /usr/bin/install -c
configure:3899: checking whether build environment is sane
configure:3954: result: yes
configure:4105: checking for a thread-safe mkdir -p
configure:4144: result: /bin/mkdir -p
configure:4151: checking for gawk
configure:4167: found /usr/bin/gawk
configure:4178: result: gawk
configure:4189: checking whether make sets $(MAKE)
configure:4211: result: yes
configure:4240: checking whether make supports nested variables
configure:4257: result: yes
configure:4384: checking whether to enable maintainer-specific portions of
Makefiles
configure:4393: result: no
ax_fix_incorrect_path_regexp = [=:]*\.:*
ax_fix_incorrect_path_old =
ax_fix_incorrect_path_new =
configure:4420: checking whether $C_INCLUDE_PATH contains the "." path
configure:4430: result: no
ax_fix_incorrect_path_regexp = [=:]*\.:*
ax_fix_incorrect_path_old =
ax_fix_incorrect_path_new =
configure:4448: checking whether $CPLUS_INCLUDE_PATH contains the "." path
configure:4458: result: no
configure:4469: result:
Programs
--------
configure:4525: checking for gcc
configure:4541: found /usr/bin/gcc
configure:4552: result: gcc
configure:4781: checking for C compiler version
configure:4790: gcc --version >&5
gcc (Linaro GCC 4.9-2014.08) 4.9.2 20140811 (ROSA)
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

configure:4801: $? = 0
configure:4790: gcc -v >&5
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/usr --libdir=/usr/lib64
--libexecdir=/usr/lib64 --mandir=/usr/share/man --infodir=/usr/share/info
--disable-libjava-multilib
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-java-awt=gtk
--enable-gtk-cairo --with-cloog --with-ppl --enable-cloog-backend=isl
--disable-cloog-version-check --disable-libssp --disable-libunwind-exceptions
--disable-werror --enable-__cxa_atexit --enable-gold=default
--with-plugin-ld=/usr/bin/ld --enable-bootstrap --enable-checking=release
--enable-gnu-unique-object
--enable-languages=c,ada,c++,fortran,go,java,lto,objc,obj-c++
--enable-linker-build-id --enable-plugin --enable-lto --enable-shared
--enable-threads=posix --with-system-zlib
--with-bugurl=http://bugs.rosalinux.ru/ --with-tune=generic --with-arch_32=i586
--with-multilib-list=m32,m64 --host=x86_64-unknown-linux-gnu
--build=x86_64-unknown-linux-gnu --target=x86_64-unknown-linux-gnu
Thread model: posix
gcc version 4.9.2 20140811 (ROSA) (Linaro GCC 4.9-2014.08)
configure:4801: $? = 0
configure:4790: gcc -V >&5
gcc: error: unrecognized command line option '-V'
gcc: fatal error: no input files
compilation terminated.
configure:4801: $? = 1
configure:4790: gcc -qversion >&5
gcc: error: unrecognized command line option '-qversion'
gcc: fatal error: no input files
compilation terminated.
configure:4801: $? = 1
configure:4821: checking whether the C compiler works
configure:4843: gcc    conftest.c -lboost_system -lboost_thread >&5
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_system.so:
undefined reference to `operator delete(void*)'
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_thread.so:
undefined reference to `std::_Rb_tree_decrement(std::_Rb_tree_node_base*)'
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_thread.so:
undefined reference to `typeinfo for std::bad_alloc'
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_thread.so:
undefined reference to `std::_Rb_tree_increment(std::_Rb_tree_node_base*)'
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_thread.so:
undefined reference to `__cxa_end_catch'
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_thread.so:
undefined reference to `__cxa_allocate_exception'
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_thread.so:
undefined reference to `std::basic_ostringstream<char, std::char_traits<char>,
std::allocator<char> >::~basic_ostringstream()'
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_thread.so:
undefined reference to `std::_Rb_tree_increment(std::_Rb_tree_node_base const*)'
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_system.so:
undefined reference to `std::basic_string<char, std::char_traits<char>,
std::allocator<char> >::basic_string(std::string const&)'
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_system.so:
undefined reference to `__cxa_guard_release'
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_thread.so:
undefined reference to `std::string::append(char const*, unsigned long)'
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_thread.so:
undefined reference to `std::basic_ostringstream<char, std::char_traits<char>,
std::allocator<char> >::basic_ostringstream(std::_Ios_Openmode)'
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_thread.so:
undefined reference to `std::string::_M_mutate(unsigned long, unsigned long,
unsigned long)'
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_thread.so:
undefined reference to `std::string::append(std::string const&)'
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_thread.so:
undefined reference to `typeinfo for std::runtime_error'
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_system.so:
undefined reference to `__cxa_pure_virtual'
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_thread.so:
undefined reference to `std::bad_alloc::~bad_alloc()'
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_system.so:
undefined reference to `std::basic_string<char, std::char_traits<char>,
std::allocator<char> >::~basic_string()'
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_thread.so:
undefined reference to `std::string::assign(char const*, unsigned long)'
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_thread.so:
undefined reference to `std::bad_exception::~bad_exception()'
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_thread.so:
undefined reference to `std::runtime_error::runtime_error(std::string const&)'
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_thread.so:
undefined reference to `std::runtime_error::what() const'
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_system.so:
undefined reference to `__gxx_personality_v0'
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_thread.so:
undefined reference to `std::bad_exception::what() const'
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_thread.so:
undefined reference to
`std::_Rb_tree_rebalance_for_erase(std::_Rb_tree_node_base*,
std::_Rb_tree_node_base&)'
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_thread.so:
undefined reference to `__cxa_begin_catch'
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_system.so:
undefined reference to `std::basic_string<char, std::char_traits<char>,
std::allocator<char> >::basic_string(char const*, std::allocator<char> const&)'
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_thread.so:
undefined reference to `__cxa_rethrow'
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_thread.so:
undefined reference to `__cxa_throw'
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_thread.so:
undefined reference to `std::basic_stringbuf<char, std::char_traits<char>,
std::allocator<char> >::str() const'
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_system.so:
undefined reference to `vtable for __cxxabiv1::__si_class_type_info'
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_thread.so:
undefined reference to `std::exception::~exception()'
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_thread.so:
undefined reference to `std::string::_Rep::_M_destroy(std::allocator<char>
const&)'
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_thread.so:
undefined reference to `operator new(unsigned long)'
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_thread.so:
undefined reference to `std::string::swap(std::string&)'
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_thread.so:
undefined reference to `typeinfo for std::bad_exception'
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_thread.so:
undefined reference to `std::string::_Rep::_S_empty_rep_storage'
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_system.so:
undefined reference to `__cxa_guard_abort'
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_thread.so:
undefined reference to `vtable for std::runtime_error'
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_system.so:
undefined reference to `vtable for __cxxabiv1::__class_type_info'
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_thread.so:
undefined reference to `std::_Rb_tree_insert_and_rebalance(bool,
std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, std::_Rb_tree_node_base&)'
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_thread.so:
undefined reference to `__cxa_call_unexpected'
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_thread.so:
undefined reference to `std::runtime_error::~runtime_error()'
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_thread.so:
undefined reference to `std::basic_ostream<char, std::char_traits<char> >&
std::__ostream_insert<char, std::char_traits<char> >(std::basic_ostream<char,
std::char_traits<char> >&, char const*, long)'
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_thread.so:
undefined reference to `vtable for __cxxabiv1::__vmi_class_type_info'
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_thread.so:
undefined reference to `__cxa_free_exception'
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_system.so:
undefined reference to `__cxa_guard_acquire'
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/libboost_thread.so:
undefined reference to `std::bad_alloc::what() const'
collect2: error: ld returned 1 exit status
configure:4847: $? = 1
configure:4885: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "POV-Ray"
| #define PACKAGE_TARNAME "povray"
| #define PACKAGE_VERSION "3.7.0"
| #define PACKAGE_STRING "POV-Ray 3.7.0"
| #define PACKAGE_BUGREPORT "uni### [at] povrayorg"
| #define PACKAGE_URL ""
| #define VERSION_BASE "3.7"
| #define DISTRIBUTION_MESSAGE_2 " LanuHum"
| #define PACKAGE "povray"
| #define VERSION "3.7.0"
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:4890: error: in `/home/leonid/workspace/build/povray':
configure:4892: error: C compiler cannot create executables
See `config.log' for more details

## ---------------- ##
## Cache variables. ##
## ---------------- ##

ac_cv_build=x86_64-unknown-linux-gnu
ac_cv_env_C99_COMPATIBLE_RADIOSITY_set=
ac_cv_env_C99_COMPATIBLE_RADIOSITY_value=
ac_cv_env_CCC_set=
ac_cv_env_CCC_value=
ac_cv_env_CC_set=
ac_cv_env_CC_value=
ac_cv_env_CFLAGS_set=
ac_cv_env_CFLAGS_value=
ac_cv_env_COMPILED_BY_set=set
ac_cv_env_COMPILED_BY_value=LanuHum
ac_cv_env_CPPFLAGS_set=
ac_cv_env_CPPFLAGS_value=
ac_cv_env_CPP_set=
ac_cv_env_CPP_value=
ac_cv_env_CXXCPP_set=
ac_cv_env_CXXCPP_value=
ac_cv_env_CXXFLAGS_set=
ac_cv_env_CXXFLAGS_value=
ac_cv_env_CXX_set=
ac_cv_env_CXX_value=
ac_cv_env_LDFLAGS_set=
ac_cv_env_LDFLAGS_value=
ac_cv_env_LIBS_set=set
ac_cv_env_LIBS_value='-lboost_system -lboost_thread'
ac_cv_env_NON_REDISTRIBUTABLE_BUILD_set=
ac_cv_env_NON_REDISTRIBUTABLE_BUILD_value=
ac_cv_env_XMKMF_set=
ac_cv_env_XMKMF_value=
ac_cv_env_build_alias_set=
ac_cv_env_build_alias_value=
ac_cv_env_host_alias_set=
ac_cv_env_host_alias_value=
ac_cv_env_target_alias_set=
ac_cv_env_target_alias_value=
ac_cv_host=x86_64-unknown-linux-gnu
ac_cv_path_install='/usr/bin/install -c'
ac_cv_path_mkdir=/bin/mkdir
ac_cv_prog_AWK=gawk
ac_cv_prog_ac_ct_CC=gcc
ac_cv_prog_make_make_set=yes
am_cv_make_support_nested_variables=yes

## ----------------- ##
## Output variables. ##
## ----------------- ##

ACLOCAL='${SHELL} "/home/leonid/workspace/build/povray/unix/config"/missing
aclocal-1.15'
AMDEPBACKSLASH=''
AMDEP_FALSE=''
AMDEP_TRUE=''
AMTAR='$${TAR-tar}'
AM_BACKSLASH='\'
AM_DEFAULT_V='$(AM_DEFAULT_VERBOSITY)'
AM_DEFAULT_VERBOSITY='1'
AM_V='$(V)'
AUTOCONF='${SHELL} "/home/leonid/workspace/build/povray/unix/config"/missing
autoconf'
AUTOHEADER='${SHELL} "/home/leonid/workspace/build/povray/unix/config"/missing
autoheader'
AUTOMAKE='${SHELL} "/home/leonid/workspace/build/povray/unix/config"/missing
automake-1.15'
AWK='gawk'
BOOST_CPPFLAGS=''
BOOST_LDFLAGS=''
BOOST_THREAD_LIB=''
C99_COMPATIBLE_RADIOSITY=''
CC='gcc'
CCDEPMODE=''
CFLAGS=''
COMPILED_BY='LanuHum'
CPLUS_INCLUDE_PATH=''
CPP=''
CPPFLAGS=''
CXX=''
CXXCPP=''
CXXDEPMODE=''
CXXFLAGS=''
CYGPATH_W='echo'
C_INCLUDE_PATH=''
DEFS=''
DEPDIR=''
ECHO_C=''
ECHO_N='-n'
ECHO_T=''
EGREP=''
EXEEXT=''
GREP=''
INSTALL_DATA='${INSTALL} -m 644'
INSTALL_PROGRAM='${INSTALL}'
INSTALL_SCRIPT='${INSTALL}'
INSTALL_STRIP_PROGRAM='$(install_sh) -c -s'
LDFLAGS=''
LIBOBJS=''
LIBS='-lboost_system -lboost_thread'
LTLIBOBJS=''
MAINT='#'
MAINTAINER_MODE_FALSE=''
MAINTAINER_MODE_TRUE='#'
MAKEINFO='${SHELL} "/home/leonid/workspace/build/povray/unix/config"/missing
makeinfo'
MKDIR_P='/bin/mkdir -p'
NON_REDISTRIBUTABLE_BUILD=''
OBJEXT=''
PACKAGE='povray'
PACKAGE_BUGREPORT='uni### [at] povrayorg'
PACKAGE_NAME='POV-Ray'
PACKAGE_STRING='POV-Ray 3.7.0'
PACKAGE_TARNAME='povray'
PACKAGE_URL=''
PACKAGE_VERSION='3.7.0'
PATH_SEPARATOR=':'
PKGCONFIG=''
PTHREAD_CC=''
PTHREAD_CFLAGS=''
PTHREAD_LIBS=''
RANLIB=''
SDLCONFIG=''
SET_MAKE=''
SHELL='/bin/sh'
STRIP=''
VERSION='3.7.0'
VERSION_BASE='3.7'
XMKMF=''
X_CFLAGS=''
X_EXTRA_LIBS=''
X_LIBS=''
X_PRE_LIBS=''
ac_ct_CC='gcc'
ac_ct_CXX=''
acx_pthread_config=''
am__EXEEXT_FALSE=''
am__EXEEXT_TRUE=''
am__fastdepCC_FALSE=''
am__fastdepCC_TRUE=''
am__fastdepCXX_FALSE=''
am__fastdepCXX_TRUE=''
am__include=''
am__isrc=''
am__leading_dot='.'
am__nodep=''
am__quote=''
am__tar='$${TAR-tar} chof - "$$tardir"'
am__untar='$${TAR-tar} xf -'
bindir='${exec_prefix}/bin'
build='x86_64-unknown-linux-gnu'
build_alias=''
build_cpu='x86_64'
build_os='linux-gnu'
build_vendor='unknown'
datadir='${datarootdir}'
datarootdir='${prefix}/share'
docdir='${datarootdir}/doc/${PACKAGE_TARNAME}'
dvidir='${docdir}'
exec_prefix='NONE'
host='x86_64-unknown-linux-gnu'
host_alias=''
host_cpu='x86_64'
host_os='linux-gnu'
host_vendor='unknown'
htmldir='${docdir}'
includedir='${prefix}/include'
infodir='${datarootdir}/info'
install_sh='${SHELL} /home/leonid/workspace/build/povray/unix/config/install-sh'
libdir='${exec_prefix}/lib'
libexecdir='${exec_prefix}/libexec'
localedir='${datarootdir}/locale'
localstatedir='${prefix}/var'
mandir='${datarootdir}/man'
mkdir_p='$(MKDIR_P)'
oldincludedir='/usr/include'
pdfdir='${docdir}'
povgroup=''
povowner=''
prefix='NONE'
program_transform_name='s,x,x,'
psdir='${docdir}'
sbindir='${exec_prefix}/sbin'
sharedstatedir='${prefix}/com'
sysconfdir='${prefix}/etc'
target_alias=''

## ----------- ##
## confdefs.h. ##
## ----------- ##

/* confdefs.h */
#define PACKAGE_NAME "POV-Ray"
#define PACKAGE_TARNAME "povray"
#define PACKAGE_VERSION "3.7.0"
#define PACKAGE_STRING "POV-Ray 3.7.0"
#define PACKAGE_BUGREPORT "uni### [at] povrayorg"
#define PACKAGE_URL ""
#define VERSION_BASE "3.7"
#define DISTRIBUTION_MESSAGE_2 " LanuHum"
#define PACKAGE "povray"
#define VERSION "3.7.0"

configure: exit 77

Post a reply to this message

No problem:
../configure COMPILED_BY="LanuHum" --with-boost-libdir=/usr/lib64

:)

Post a reply to this message

Le 10/10/2016 à 17:02, LanuHum a écrit :
> No problem:
> ../configure COMPILED_BY="LanuHum" --with-boost-libdir=/usr/lib64
> 
> :)
> 
> 
> 
Nice :-)

Post a reply to this message