Inkscape

On Tue, 21 Sep 2004, Bob Jamison wrote:
> I am not sure if this has been agreed upon, but we
> are going to use static linking for all of our C++ dependencies,
> right?  In other words, for all of the libs:
> 
> libsigc++
> gtkmm
> glibmm
> gc(cpp)
> 
> They are ./configured with --enable-static --disable-shared, so that
> subsequent 'pkg-config --libs' calls will return the info needed
> for static linking?
> 
> We need to remove C++ dependencies from the shoulders of our
> users, -especially- since different C++ compilers and different versions
> of the same compiler usually do not mix.
> 
> A way to check such dependencies would be:
> 'ldd inkscape'
> 
> The C++ libs should not be listed.

Afaik, for the linux distros, there has been no such decision to
statically link the C++ libs.  Possibly they should, but it would
require further discussion.

For the 0.40 release we discussed waiting on release until gtkmm 2.4, et
al became more widely available.  We had distributed with the gtkmm 2.2
last time around, with few problems other than the expected one of some
users not having that package already installed.

For libgc, we've really not discussed how to handle that very much, but
given that the packages I've seen in the wild have not been compiled
with the C++ flag, I think it'd be an excellent candidate to statically
link in, especially since unlike gtkmm it's unlikely to be shared by
very many other apps on the user's machine.

Anyway, if there's further concerns, this'd be a good point to get them
worked out.

Bryce

My first attempt:

Open share/examples/stars.svgz, save as pov. The result is 158151 bytes.

Renaming it to isshapes.pov. Running povray on istest.pov. (A rather
cumbersome procedure.) Povray (version 3.5) segfaults :(

What I do see however before the segfault is only two stars, both
metallic color. Why not make them the color of the corresponding
objects?

bulia byak wrote:

>My first attempt:
>
>Open share/examples/stars.svgz, save as pov. The result is 158151 bytes.
>
>Renaming it to isshapes.pov. Running povray on istest.pov. (A rather
>cumbersome procedure.) Povray (version 3.5) segfaults :(
>  
>
I had a problem with 3.6 segfaulting.  Some inappropriate thing they are
doing with C++ I think.   You might look at the file.  Does it make sense?
I tried to make it clean and readable.

>What I do see however before the segfault is only two stars, both
>metallic color. Why not make them the color of the corresponding
>objects?
>
>  
>
Yes, that was just a first try. 

I was thinking about colors last night.  How would I get the
colors from an SPShape?



Bob

> I had a problem with 3.6 segfaulting.  Some inappropriate thing they are
> doing with C++ I think.   You might look at the file.  Does it make sense?
> I tried to make it clean and readable.

The file looks fine. I'm not asking you to fix povray, of course :)
I'm just surprised that it's so easy to crash...

> I was thinking about colors last night.  How would I get the
> colors from an SPShape?

SPStyle *style = SP_OBJECT_STYLE(shape);
if (style && (style->fill.type == SP_PAINT_TYPE_COLOR)) { 
  SPColor *color = style->fill.value.color;
  // see color.h for how to parse SPColor
}

(untested)

bulia byak wrote:

>SPStyle *style = SP_OBJECT_STYLE(shape);
>if (style && (style->fill.type == SP_PAINT_TYPE_COLOR)) { 
>  SPColor *color = style->fill.value.color;
>  // see color.h for how to parse SPColor
>}
>
>(untested)
>
>  
>

Thanks, I will give that a try.


(By the way, I will likely be out of the office tomorrow.
It looks like what is left of Ivan will hit here tomorrow,
giving me a good excuse to stay home.)



Bob

I got color export working!  Here is an example, with
our beloved logo again:

http://troi.hous.es3.titan.com/~rjamison/inkscape/files/ispov.png

I don't have the shading correct (note the 'jaggies' where black
and white pieces join), but it is a nice start.

I committed this fix, and updated istest.pov to handle it.


I noticed that Inkscape gradients look like hell in POV,
but we can just delete them.


Bob



bulia byak wrote:

>
>SPStyle *style = SP_OBJECT_STYLE(shape);
>if (style && (style->fill.type == SP_PAINT_TYPE_COLOR)) { 
>  SPColor *color = style->fill.value.color;
>  // see color.h for how to parse SPColor
>}
>
>(untested)
>
>  
>

Thanks! I tried stars.svgz again. 

1. You seem to disregard the item's transform when exporting it. This
only works for paths with "optimize transforms" mode. You need to
multiply each point of the path by sp_item_i2d_affine(item) so that it
works for shapes with transform=.

2. After I worked around 1. by converting all stars to paths and
moving them a bit so as to optimize their transforms, I got something
which at least looks like the original in terms of the shapes and
their relative positions. The good news is that povray does not crash
on it, at first. It still crashes nearer the end of the render with:

Possible Rendering Error: Maximum trace level reached! If your scene
contains black spots
read more about the max_trace_level setting in the documentation!

line 2:  8174 Segmentation fault      pv istest.pov

3. It may be due to lighting, but most of the stars are pure white,
some are yellow and some are black. This does not look like the
original colors. At least part of the reason is that you disregard the
transparency of the shapes, but there are red and green stars there
which I don't see in the pov render.

On Thu, 23 Sep 2004 21:39:01 -0300, bulia byak <buliabyak@...> wrote:
> only works for paths with "optimize transforms" mode. You need to
> multiply each point of the path by sp_item_i2d_affine(item) 

Or maybe you can assign the same transform in to the povray object?
Does the language support matrix transforms?

bulia byak wrote:

>Possible Rendering Error: Maximum trace level reached! If your scene
>contains black spots
>read more about the max_trace_level setting in the documentation!
>
>line 2:  8174 Segmentation fault      pv istest.pov
>
>  
>

I think that 'black spots' are where surfaces are coincident & parallel.

>3. It may be due to lighting, but most of the stars are pure white,
>some are yellow and some are black. This does not look like the
>original colors.
>
Keep in mind that only a part of the light is ambient in that scene.
The rest is reflected or is specular.  So some things will be lighter,
others darker.  If you adjust the finish to turn ambient up and the
others down, the colors will match the original, but it will
look bad & unreal.

>At least part of the reason is that you disregard the
>transparency of the shapes, but there are red and green stars there
>which I don't see in the pov render.
>
>
>  
>
I don't think we will ever have perfect conversion.  I mostly
just wanted to get the shapes into POV so I could model them
on Inkscape.

I did notice that gradients are -terrible- during conversion.  For
example, try /clipart/orav.svg   and  /clipart/tux.svg  .


I will look at the transform.   What I would like to do is end up
with all objects on the page with the same coordinate system.
That should make it easier for the user to compare what he sees
on the Inkscape screen to what he sees in the PovRay image.


Bob

bulia byak wrote:

>Thanks! I tried stars.svgz again. 
>
>1. You seem to disregard the item's transform when exporting it. This
>only works for paths with "optimize transforms" mode. You need to
>multiply each point of the path by sp_item_i2d_affine(item) so that it
>works for shapes with transform=.
>  
>
Ok, I am now doing just that, and the stray objects in the povray scene
are all together now.

Example:
http://troi.hous.es3.titan.com/~rjamison/inkscape/files/povtux.png

Previously, the white in the middle had been shifted to the upper-right.


Here is the transform that I am using,  is this proper?   :

double x1 = NR_MATRIX_DF_TRANSFORM_X(tf, bp->x1, bp->y1);
double y1 = NR_MATRIX_DF_TRANSFORM_Y(tf, bp->x1, bp->y1);




Bob

Oops!  I was totally wrong here, and you were absolutely correct.
I was outputting the colors like  < 128, 128, 128 > . I forgot
that PovRay colors are  0.0-1.0 instead of 0.255.
It should have been like <0.5, 0.5, 0.5> .

So all of the colors were super-saturated.  Here are examples

Before:
http://troi.hous.es3.titan.com/~rjamison/inkscape/files/ispov.png

After:
http://troi.hous.es3.titan.com/~rjamison/inkscape/files/ispov2.png


Now here is a BIG difference :

Before:
http://troi.hous.es3.titan.com/~rjamison/inkscape/files/povtux.png
After:
http://troi.hous.es3.titan.com/~rjamison/inkscape/files/povtux2.png



Fixed.



Bob



Bob Jamison wrote:

> bulia byak wrote:
>
>> 3. It may be due to lighting, but most of the stars are pure white,
>> some are yellow and some are black. This does not look like the
>> original colors.
>>
> Keep in mind that only a part of the light is ambient in that scene.
> The rest is reflected or is specular.  So some things will be lighter,
> others darker.  If you adjust the finish to turn ambient up and the
> others down, the colors will match the original, but it will
> look bad & unreal.
>

> Here is the transform that I am using,  is this proper?   :
> 
> double x1 = NR_MATRIX_DF_TRANSFORM_X(tf, bp->x1, bp->y1);
> double y1 = NR_MATRIX_DF_TRANSFORM_Y(tf, bp->x1, bp->y1);

Yes, if tf is the correct matrix. Now the perferred way of writing this is:

NR::Point transformed = NR::Point(bp->x1, bp->y1) * NR::Matrix(tf);

and then use transformed[NR::X] and transformed[NR::Y].

Tried stars.pov again. Povray still crashes :( Oh well. But at least
the scene looks much better now (until it crashes, that is).

1. I think the z-order step in AllShapesZ should be a configurable
parameter, rather than hard-coded.

2. Supporting transparency seems to be easy in povray (clear,
fade_color, fade_power etc). Why not add it?

3. Bug: create new empty document, draw a star. Save as pov. Povray
renders the result empty. Now add an ellipse and save again. Now both
star and ellipse are visible.

bulia byak wrote:

>Tried stars.pov again. Povray still crashes :( Oh well. But at least
>the scene looks much better now (until it crashes, that is).
>
>1. I think the z-order step in AllShapesZ should be a configurable
>parameter, rather than hard-coded.
>  
>
I agree.  If you notice istest.pov,  the finish{} attribute can be 
defined before
#including.  I will try to do z-order the same way.

It looks like #declare's are defined as the file is read.  However, they can
be redefined within the file while it is being read.  I do not think that
they can be changed later, like in a Makefile.

>2. Supporting transparency seems to be easy in povray (clear,
>fade_color, fade_power etc). Why not add it?
>  
>
Heh.  I don't know.  Is transparency a style attribute that is easy to get?

>3. Bug: create new empty document, draw a star. Save as pov. Povray
>renders the result empty. Now add an ellipse and save again. Now both
>star and ellipse are visible.
>
>  
>
II have no idea.  I'll look at this one.



Bob

> Heh.  I don't know.  Is transparency a style attribute that is easy to get?

Even easier than color. It's SP_SCALE24_TO_FLOAT(style->opacity.value)
which will give you the 0..1 range.

On Tue, 28 Sep 2004 18:25:50 -0300, bulia byak <buliabyak@...> wrote:
> > Heh.  I don't know.  Is transparency a style attribute that is easy to get?
> 
> Even easier than color. It's SP_SCALE24_TO_FLOAT(style->opacity.value)
> which will give you the 0..1 range.

Err, you also need to multiply it by the fill-opacity:

SP_SCALE24_TO_FLOAT(style->opacity.value) *
SP_SCALE24_TO_FLOAT(style->fill_opacity.value)

bulia byak wrote:

>
>SP_SCALE24_TO_FLOAT(style->opacity.value) *
>SP_SCALE24_TO_FLOAT(style->fill_opacity.value)
>
>  
>
Ok, I got the transparency working.  I picked
'filter transparency' (like colored glass) instead
of 'transmit transparency' (like looking through cloth),
since it looks more like what SVG looks like.

Also made the Z-spacing adjustable by #declaring
AllShapes_Z_Increment before the file is #included.



Bob