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 <cr...@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 <ideasma...@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 >>>> <montagn...@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<ideasma...@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@blender.org >>>>>>> http://lists.blender.org/mailman/listinfo/bf-committers >>>>>>> >>>>> _______________________________________________ >>>>> Bf-committers mailing list >>>>> Bf-committers@blender.org >>>>> http://lists.blender.org/mailman/listinfo/bf-committers >>>> >>>> -- >>>> - Campbell >>>> _______________________________________________ >>>> Bf-committers mailing list >>>> Bf-committers@blender.org >>>> http://lists.blender.org/mailman/listinfo/bf-committers >>> _______________________________________________ >>> Bf-committers mailing list >>> Bf-committers@blender.org >>> http://lists.blender.org/mailman/listinfo/bf-committers >>> >> _______________________________________________ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> > > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers