im currently studying the art and style of Shepard Fairey, aka OBEY
for now im looking at stuff he made and try to replicate some of the basic elements, like hatchings and guilloche borders
http://www.obeygiant.com/collectibles/p ... g-press-01
i have done something with guilloche borders before (by rotating tiled clones of a circle) and my computer became very slow
so im wondering, whats the best approach to make patterns that are processor friendly ?
for example, i read that clones are more processor friendly than objects
(i know about Display Modes and turning off layers)
Question 2:
today i tried to replicate diagonal hatchings
so i covered a rectangle twice the canvas size with a 2px wide rectangle of tiled clones
then grouped everything and rotated the group by 45°
positioned my hatching texture over the canvas and then clipped the whole thing with a canvas-sized rectangle
is that a good approach or is it better to use a pattern fill ?
or make the whole thing as a path and cut it with a boolean operation ?
building processor friendly textures
- Espermaschine
- Posts: 892
- Joined: Thu Jun 05, 2014 9:10 pm
Re: building processor friendly textures
I don't really know. But it certainly would be interesting to see some kind of comparison!
I have the impression that converting vector paths to patterns.....either sort of rasterizes them or actually does rasterize them. And I know that rasters are heavy on the file size, at least when they are imported as images. But I don't know exactly what happens when they are changed to patterns.
I have the impression that a large number of clones can bog down a (low RAM) system as well. But I don't know for sure.
I do know that except for filters (which are raster objects), Inkscape needs RAM, more than it needs processor. For filters, processors come into play more. I know that because of that setting in Inkscape Preferences > Filters > Number of Threads (processor cores). (And because I've read about it here and there.) It does speed up rendering of a filter-heavy file, if you have multiple cores, and set Inkscape to use them. I know that by experience. (0.91 will have even better support for that.)
That looks like a challenging image to reproduce.....but fun!
I have the impression that converting vector paths to patterns.....either sort of rasterizes them or actually does rasterize them. And I know that rasters are heavy on the file size, at least when they are imported as images. But I don't know exactly what happens when they are changed to patterns.
I have the impression that a large number of clones can bog down a (low RAM) system as well. But I don't know for sure.
I do know that except for filters (which are raster objects), Inkscape needs RAM, more than it needs processor. For filters, processors come into play more. I know that because of that setting in Inkscape Preferences > Filters > Number of Threads (processor cores). (And because I've read about it here and there.) It does speed up rendering of a filter-heavy file, if you have multiple cores, and set Inkscape to use them. I know that by experience. (0.91 will have even better support for that.)
That looks like a challenging image to reproduce.....but fun!
Basics - Help menu > Tutorials
Manual - Inkscape: Guide to a Vector Drawing Program
Inkscape Community - Inkscape FAQ - Gallery
Inkscape for Cutting Design
Manual - Inkscape: Guide to a Vector Drawing Program
Inkscape Community - Inkscape FAQ - Gallery
Inkscape for Cutting Design
Re: building processor friendly textures
My experience is that it's much slower to have a hatching line by line.
Clones may reduce the codes of your svg file.
On the other hand, editing the parent when there are a lot of clones, like in a hatching, can be slow.
Pattern fills are implemented somewhat similarly to clones as far as I see it, except for you can edit the parent tile only with the xml editor in a live way.
Problem with pattern fills is a rendering issue that produces a small gap in between tiles.
Corrected in the upcoming 0.91 hopefully, until that this can be the solution.
I would suggest to stick with the pattern fill, and see if those gaps fills up in the output format of choice.
Another note, if there are a lot of pattern fills used, it can easily crash with small files.
Clones may reduce the codes of your svg file.
On the other hand, editing the parent when there are a lot of clones, like in a hatching, can be slow.
Pattern fills are implemented somewhat similarly to clones as far as I see it, except for you can edit the parent tile only with the xml editor in a live way.
Problem with pattern fills is a rendering issue that produces a small gap in between tiles.
Corrected in the upcoming 0.91 hopefully, until that this can be the solution.
I would suggest to stick with the pattern fill, and see if those gaps fills up in the output format of choice.
Another note, if there are a lot of pattern fills used, it can easily crash with small files.
