[Bf-committers] Generating icons overwriting files in SVN.

Tue Aug 27 11:32:49 CEST 2013

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 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 here. IMO, when someone updates
> SVG he SHOULD update PNG as well. Also, it might worth defining owner of
> icons,who will update the files (as opposite to current "everyone might
> just edit the icons and update them").
>
> IMO, that'd be nice practice anyway and no need to try writing any AI in
> cmake :)
>
>
> On Tue, Aug 27, 2013 at 3:02 PM, Constantin Rahn <crahn at vrchannel.de> wrote:
>
>> 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
>> the SVGs for buttons in blender itself.
>> In worst case use a little scene with a plane and an ortho camera and
>> render the buttons.
>>
>> http://code.google.com/p/vectex/
>>
>> http://www.blendernation.com/2008/03/02/vectex-svg-vector-texture-plugin-for-blender/
>>
>> http://blenderartists.org/forum/showthread.php?117889-Vectex-SVG-vector-texture-plugin-for-Blender
>>
>> Beside that would it be a nice feature to bring SVG support for textures
>> back to blender.
>>
>> Or do I miss something here?
>>
>> Happy blending,
>> Conz
>>
>> Am 26.08.2013 18:37, schrieb Brecht Van Lommel:
>>> 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 difficult to ensure you
>>> get identical files.
>>>
>>> If you wanted to solve this, you could do something like embed an md5
>>> hash of the svg in the png file. Then if the hash is different
>>> overwrite the png, else just "touch" the file so the modified date is
>>> newer.
>>>
>>> Brecht.
>>>
>>> On Mon, Aug 26, 2013 at 2:15 PM, Campbell Barton <ideasman42 at gmail.com>
>> wrote:
>>>> 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 that isnt pulling in many deps (or use some other
>>>> more compact vector format that SVG can be converted into might be
>>>> better).
>>>>
>>>> Just to note on 2 issues.
>>>>
>>>> I uninstalled inkscape to avoid blender useing it and now I get this
>>>> message when building...
>>>>
>>>> """
>>>> No rule to make target `/usr/bin/inkscape', needed by
>>>> `/src/blender/release/datafiles/blender_icons16.png'.  Stop.
>>>> """
>>>>
>>>> Brecht also mentioned he had some error on OSX that X11 had not been
>>>> started (inkscape must use X11 even when run in the command line).
>>>>
>>>> ImageMagick's SVG conversions from SVG look exact the same as
>>>> inkscapes from my test so if this is added back at some point we could
>>>> use that instead.
>>>>
>>>> On Mon, Aug 26, 2013 at 10:06 PM, Bastien Montagne
>>>> <montagne29 at wanadoo.fr> 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 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
>>>>> :/ ). Additionally, it’s a bit a pita when sharing patches that add an
>>>>> icon, reviewer also has to update png from svg...
>>>>>
>>>>> I’ll revert (or rather, comment) that change for now, but imho we
>> really
>>>>> need to find some way to avoid that kind of disparity, human are far
>> too
>>>>> much unreliable when it comes to such tasks!
>>>>>
>>>>> I like Sergey's solution (rasterize svg in Blender), but this is quite
>> a
>>>>> big project I fear. :/
>>>>>
>>>>> On 26/08/2013 12:35, Sergey Sharybin wrote:
>>>>>> 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 already really complicated. So i would
>> rather
>>>>>> avoid this.
>>>>>>
>>>>>> So from suggested alternatives i would prefer reverting that part of
>>>>>> changes which generates PNG out of SVG at buildtime. We don't change
>> icons
>>>>>> so much often anyway.
>>>>>>
>>>>>> As a long-term solution, think it's better to make SVG a native
>> format for
>>>>>> icons. Meaning, blender will rasterize SVG itself. Would make any
>> icons
>>>>>> size look just as crisp as it could be :)
>>>>>>
>>>>>>
>>>>>> On Mon, Aug 26, 2013 at 4:09 PM, Campbell Barton<ideasman42 at gmail.com
>>> wrote:
>>>>>>> Recently Bastian committed changes so changes to the SVG icons
>>>>>>> automatically generates new PNG's.
>>>>>>>
>>>>>>> In general this is nice functionality to have, but it has some
>> problems.
>>>>>>> The updated file thats generated overwrites the PNG in svn,
>>>>>>> with changes to file modifiy times (moving files or dirs about),
>>>>>>> its possible the PNG will get regenerated by building, even if the
>> SVG
>>>>>>> wasnt modified.
>>>>>>>
>>>>>>> So before committing you have to revert the change if it wasnt
>> intentional,
>>>>>>> then manually touch the PNG so CMake isn't going to try generate the
>>>>>>> image again.
>>>>>>>
>>>>>>>
>>>>>>> Normally I check files before committing but sometimes I just commit
>>>>>>> if I know I only edited a few files.
>>>>>>> but generating overwriting files in svn means you can't be sure other
>>>>>>> files aren't chagned too.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Suggest 2 options...
>>>>>>>
>>>>>>> 1) Store _all_ generated files out of source,
>>>>>>>      (this was the case already before icon changes)
>>>>>>> Note: since we currently don't have inkscape as a build dependency we
>>>>>>> cant remove the PNG's from SVN,
>>>>>>>      but we could generate the file to the external dir, if inkscape
>>>>>>> isn't found, just copy it from the one in svn.
>>>>>>>      This way we get the benefit of icon generation without
>> accidentally
>>>>>>> overwriting icons in svn.
>>>>>>>
>>>>>>> 2) revert icon generation as part of the build process for now.
>>>>>>>
>>>>>>> A third option could be to remove PNG's from SVN and make
>>>>>>> inkscape/imagemagick a build dependency,
>>>>>>> but think this makes building more trouble and dont really think its
>>>>>>> such a good thing to do.
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> - Campbell
>>>>>>> _______________________________________________
>>>>>>> Bf-committers mailing list
>>>>>>> Bf-committers at blender.org
>>>>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>>>>>
>>>>> _______________________________________________
>>>>> Bf-committers mailing list
>>>>> Bf-committers at blender.org
>>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>>
>>>> --
>>>> - Campbell
>>>> _______________________________________________
>>>> Bf-committers mailing list
>>>> Bf-committers at blender.org
>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>
>