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

Tue Aug 27 11:27:43 CEST 2013

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
>

-- 
With best regards, Sergey Sharybin