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.
Bob
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@...400...> 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.
- 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
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:
- 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.
bulia byak wrote:
Thanks! I tried stars.svgz again.
- 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
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).
- 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.
- 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?
- 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
On Tue, 28 Sep 2004 18:25:50 -0300, bulia byak <buliabyak@...400...> 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
participants (3)
-
Bob Jamison -
Bryce Harrington -
bulia byak