sounds like this is fixed for now..
in the future, another possibility is to slightly extend the svg to png
generation to bit compare the png pixels, and if they are the same, just
touch the old instead of overwriting the new.
___
Bf-committers mailing l
Thanks Campbell, think this will do it for now! :)
On 27/08/2013 12:06, Campbell Barton wrote:
> Added convenience target so you can run "make icons" from blenders source dir.
>
> On Tue, Aug 27, 2013 at 7:32 PM, Constantin Rahn wrote:
>> Ah sure, you are right, there is no blender at buildtime t
Added convenience target so you can run "make icons" from blenders source dir.
On Tue, Aug 27, 2013 at 7:32 PM, Constantin Rahn wrote:
> Ah sure, you are right, there is no blender at buildtime that could
> convert the PNGs.
>
> Am 27.08.2013 11:27, schrieb Sergey Sharybin:
>> Supporting SVG as a
Ah sure, you are right, there is no blender at buildtime that could
convert the PNGs.
Am 27.08.2013 11:27, schrieb Sergey Sharybin:
> Supporting SVG as a textures is a complete different topic.
>
> Here we're discussing building process itself,meaning to the time SVG->PNG
> conversion is needed t
Supporting SVG as a textures is a complete different topic.
Here we're discussing building process itself,meaning to the time SVG->PNG
conversion is needed there's no blender built yet. Adding extra dependency
for this step i would consider a bad idea.
And i still not sure we need to be smart her
Some naive question:
Why do you use incscape or imagemagic and not blender itself?
In 2008 there was a nice plugin called "Vectex", with the functionality
of using native SVG as textures in "Blender Render". With this plugin
updated to latest blender version, it should be possible to rasterize
Its based on timestamps, I copied my source dir, then restored it
(which I *think* caused the PNG to be regenerated).
On Tue, Aug 27, 2013 at 3:20 AM, Antony Riakiotakis wrote:
> I thought this would be a non issue with cmake...
>
> As far as I know the cmake targets are only executed if the sour
I thought this would be a non issue with cmake...
As far as I know the cmake targets are only executed if the source
dependencies change, so regeneration target shouldn't be called unless the
svg files actually change.
___
Bf-committers mailing list
Bf-c
I solved the OS X problem, just didn't commit the fix yet, is now
committed in case this gets reenabled.
Also, svn/git does not show the file as changed if the binary file is
identical. But different inkscape versions or some date/time metadata
may generate different files. Probably it's difficul
Thanks Bastian,
Until recently we had to manually update all datatoc stuff (glsl,
fonts fonts etc,) and it _did_ get annoying so appretiate
improvements here even if there are some hiccups along the way.
Rasterizer in Blender may not be such a big project if we can use some
small SVG library t
Let's just punish those folks who updates svg but not re-generate png.
Issue solved! :)
On Mon, Aug 26, 2013 at 6:06 PM, Bastien Montagne wrote:
> Hi folks,
>
> I made that change because I found out prvicons.png was no more in sync
> with its svg "master" since a long time. I obviously agree th
Hi folks,
I made that change because I found out prvicons.png was no more in sync
with its svg "master" since a long time. I obviously agree that these
"false" changes to png are not nice (I did not expected them, thought
svn would stick to binary comparison to detect changes in binary files
:
Hi,
Don't think generating PNG if Inkscape found and using PNG from SVN
otherwise will work. We would still need to keep PNG up-to-date in svn, so
everyone is guaranteed to have up-to-date icons.
Making inkscape/imagemagick a dependency is not a good thing to do as well
-- blender compilation is
13 matches
Mail list logo
