Emperor Krulos

Repository of svg decals

83 posts in this topic

Welcome to the Minifig SVG Decal Repository

Quickstart:

Minifig SVG Decal Repository on GitHub

Download as Zip-file

Browse our homepage

7712876280_c41b04e893.jpg

We also have a flickr Group.

Where are the SVG files:

We keep the svg files on GitHub. Just download the zip if you don't want to bother with that. We're also currently working out the kinks in our web appearance, that will make browsing the repository easier.

I want to join:

Great. Introduce yourself in this thread. Obviously we do expect you to work with SVG files and to have a GitHub account.

Learning SVG is real easy and intuitive. GitHub is also really simple, I just suck at explaining. :hmpf: Let's hope that Nick or Vynsane write a simpler introduction.

FAQ:

What's this SVG?

SVG is an open fie format, that describes pictures as mathematical functions. As such they loose no detail through scaling. They are also easy to edit because unlike raster images (jpg, png and so on) I can still move a line around after I'm done.

Do you take requests?

Those of us that do take requests check the Decal Wish List every once in a while. Do not post requests in this thread!

Are you gonna answer all requests?

No. Just like everyone else answering requests, we do not feel obligated to answer each one.

How can I improve my chances of a request being answered?

  • Be polite. Aside from the obvious, it also means to obey the rules set forth in the opening post of the Decal Wish List.
  • Only post to request or answer a request. Everything else is considered noise.
  • Fun requests are more likely to be fulfilled than boring ones. Every decal creator defines fun differently.
  • Make it appealing. One way to achieve this is to make the request appear minimal in time consumption.
    • Be precise.
    • Add links to reference material.

The colors seem of when printing

Read this

I want to tell XX how awesome he is and that he rocks

Every decal creator loves to hear that. The most effective way to do this is also the one where the artist gets maximum attention. Look for his personal thread and tell him there. If you can't find one make one. Seriously a thread dedicated to a decal creator is the most flattering thing around.

Your writing sucks

I know. Send me a PM with corrections if it bothers you.


Original Post:

Dear fellow decal creators,

would anyone be interested in collaborating? Before I describe what I want to achieve, let me explain how I work.

I store all my svg sources in a local concurrent versioning system (git). This allows me to access historic versions of my files and I don't have to fear accidentally deleting something important. At least not if I have put it under version control. I also started to assemble a library of common elements, like muscles, belts, skirts and so forth. These can then be easily integrated in future works. Using svg gives me a small source file size and enables me to easily edit my work later.

Is anyone also working like this, or interested in doing so? Essentially I'd move my local store to github, thus opening my library for others to use and encourage others to submit new pieces as well.

I'm not proposing to leave brickshelf/flickr or eurobricks to present the final rasterized image. I'm suggesting to create a resource for those creating decals.

Long term goals

My hope is that over time the library would grow to a point where it is a standard resource. Maybe even collecting all hints, tips and tutorials in one place.

Is anyone of you decal creators interested in such an approach?

Edited by Emperor Krulos

Share this post


Link to post
Share on other sites

I think it is really a good idea. And I'm willing to participate.

Share this post


Link to post
Share on other sites

No objections. I once used github before for my software project. I thinks it is the most simple (and free) solution/ Plus there are a lot of tutorials on how to use github.

Such project will need a clear guidelines on keeping files organized (subfolders for different elements and themes). Writing and following such guidelines might be the hardest part.

Edited by NickAb

Share this post


Link to post
Share on other sites

Minifig SVG Decal Repository on GitHub

I created the repository and started pushing in my library.

No objections. I once used github before for my software project. I thinks it is the most simple (and free) solution/ Plus there are a lot of tutorials on how to use github.

Exactly why I proposed it.

Such project will need a clear guidelines on keeping files organized (subfolders for different elements and themes). Writing and following such guidelines might be the hardest part.

No kidding. Take a look at PHP-fig for a current example. Great ideas going on over there, but it looks like they're getting weighed down by meaningless bureaucratization.

I have a few ideas. I just didn't want to get ahead of myself. Questions I think we need to address include:

  • licencing
  • directory layout
  • svg layout (use of linked clones, layers,...)
  • all the usual organizational overhead like: manifesto, membership guidelines,...

Take a look at the repository and let me know what you think. If you tell me your github username I'll add you as collaborator.

Share this post


Link to post
Share on other sites

Regarding licensing I would suggest using one of Creative Commons licenses:

Also we should note that the attribution is not necessary but appreciated.

I'm in favor of Attribution-NonCommercial-ShareAlike. I also started to add wiki pages. I'm just writing down what I feel should be there for now. If you have any objections or suggestions let me know or just change it.

I saw your first commit. :wub: Just a question, have you looked at library/torsos? I feel torso-muscle should be there.

I tried opening one or two files and it kept saying its invalid it needs to be validated before opening.

I assume you tried opening the svg files in your browser? The files are valid. Trouble is github disabled direct viewing of svg images for security reasons. So you have to download them first before looking at them. About the validation. Is it possible you're using IE6 or IE7? They might be recognizing xml files and trying to validate them to pretty print them.

Share this post


Link to post
Share on other sites

I'm in favor of Attribution-NonCommercial-ShareAlike. I also started to add wiki pages. I'm just writing down what I feel should be there for now. If you have any objections or suggestions let me know or just change it.

I saw your first commit. :wub: Just a question, have you looked at library/torsos? I feel torso-muscle should be there.

I assume you tried opening the svg files in your browser? The files are valid. Trouble is github disabled direct viewing of svg images for security reasons. So you have to download them first before looking at them. About the validation. Is it possible you're using IE6 or IE7? They might be recognizing xml files and trying to validate them to pretty print them.

Ok let me rephrase i am a graphic designer. I downloaded the Files to my hard drive and i tried to open them in adobe illustrator. I get the error that they need to be validated. I have an account with github but i have never used it. How do you DL them? i right Clicked on the link and said save file as : BigBen.svg

Share this post


Link to post
Share on other sites

Ok let me rephrase i am a graphic designer. I downloaded the Files to my hard drive and i tried to open them in adobe illustrator. I get the error that they need to be validated. I have an account with github but i have never used it. How do you DL them? i right Clicked on the link and said save file as : BigBen.svg

Sorry. I didn't mean to insult you.

Right clicking won't work. If you click on a file it will open code view. Then you have to open raw view. That you can save.

It's probably easier to just clone the repository. Since you already have a github account I assume you also have git installed.

git clone https://github.com/jpgerdeman/minifig-svg-decals.git

Or you can just hit the download as zip button.

I just noticed that the big ben decal shouldn't be in there and still contains reference material. :blush: I'll fix it tomorrow evening.

Share this post


Link to post
Share on other sites

Here is my suggestion for starting directory layout

  • Civic - police, firemen, farmer, bank teller, etc.
  • Fantasy - lord of the rings, harry potter, etc.
  • Historic - ancient rome, pirates, western, world war, etc.
  • Sci-Fi - space pirates, space marines, mass effect, etc.
  • Superheroes
  • Other

I think it will be enough for start and as the library grows we can group decals in subdirectories.

Also it might be a helpful to add direct link for zip-archive of library to the first post.

Edited by NickAb

Share this post


Link to post
Share on other sites

:thumbup: Great suggestions.

Do you want to move the decals to the new folders, or shall I?

Also saw your sig. I'll edit mine accordingly. It could use a nice eye-catcher, though. :tongue:

Share this post


Link to post
Share on other sites

:thumbup: Great suggestions.

Do you want to move the decals to the new folders, or shall I?

Also saw your sig. I'll edit mine accordingly. It could use a nice eye-catcher, though. :tongue:

I've started to move files. But I don't know where to move Mortal Combat. It might fit to fantasy category, but maybe we should create Games category or something.

Share this post


Link to post
Share on other sites

I think we should take non-minifig decals out of the figure directory and put them into a separate folder "other" so it's

figures

folder

library

I'll make the change, once I have feedback from you.

Also I'm currently concentrating on making graphics for some of Lego's staples, like the forestman and the black falcons. They do get requested quite frequently.

Share this post


Link to post
Share on other sites

It might be a good idea. So we can have a place for tile decals etc. But some decals like shields might be better fit for figures library, especially if they are be placed in same folder as torso designs of same faction.

Also I have forestmen symbol and some shields designs, I'll add then later.

Edited by NickAb

Share this post


Link to post
Share on other sites

I just cloned the repo to my mac. Very cool stuff... Are you only interested in minifigures designs, or can I add templates/designs for other pieces? I've been thinking of creating a series of blank templates for stickers to be used on various tiles, slopes, wedges, etc... and would be willing to add them here. My GitHub account name is VynDesign.

Share this post


Link to post
Share on other sites

I believe it will be nice to have all sorts of decals. We just need a separate folders for different kinds of decals. It was discussed in few previous posts. I think Emperor Krulos is going to create some subfolders to organize stuff.

It is always great to have more contributors.

Edited by NickAb

Share this post


Link to post
Share on other sites

I believe it will be nice to have all sorts of decals.

Cool, just wanted to make sure because the repo name starts with 'minifig' :wink:

I think it would make sense to have a folder marked 'elements' on the same level as 'figures', instead of a folder marked 'other' inside 'figures'. Then inside 'elements' we can have separate folders for 'tiles', 'bricks', 'wedges', etc.

Share this post


Link to post
Share on other sites

Hey guys, I got your PMs. It sounds like an interesting project, I'd be happy to chip in. :sweet:

I'm not familiar with Github though, I'd need to register... then what? Join the group and start uploading SVG files?

Share this post


Link to post
Share on other sites

You'll need to register at github.com. THe easiest way to start with git is to use GUI application, like Github for Windows (Mac/Unix). After you download and install Github client you would be able to clone repository with a single click. After that you can add new items to the library locally, they will become available for others after committing and syncing with remote repository (store at github.com).

Here is the small review of GUI http://arstechnica.com/information-technology/2012/05/hands-on-github-for-windows-takes-the-pain-out-of-using-git/

Here is the basics of console git http://cworth.org/hgbook-git/tour/

Share this post


Link to post
Share on other sites

Ladies and Gentlemen I'd like to welcome our newest collaborator VynDesign/vynsane. :classic:

Welcome aboard.

Thanks, Emperor Krulos - for my inaugural push I added the Blacktron Emblem to library/logos/ :wink:

I'm thinking that the 'elements' directory could get pretty unruly if we don't come up with some scheme as to filenames or subfolders - for instance... 'big_ben.svg'. I don't know what size tile this should be, is it a 6x6 or 2x2? Obviously being vector graphics it's scalable to any square size, but perhaps that's the point - maybe it should be pre-sized to all existing square tile sizes, so you'd have a '2x2_big_ben.svg' and '6x6_big_ben.svg' (maybe even a 1x1? Probably overkill, given the intricate nature of the design). What about including either Bricklink part numbers or official LEGO element IDs in the filenames as well, or would that be too much? Aside from that, I might go so far as to say we should pre-allocate subfolders for each element, so under '/elements/tiles/' we could have folders for '1x1', '1x2', 1x3', etc.

Share this post


Link to post
Share on other sites

To add to NickAB's answer. Let me try to briefly explain what a cvs in general and GitHub in particular do. You didn't tell if you were new to GitHub or the whole versioning concept. If you already know, then please ignore this brief explanation. :classic:


The gist. Files are stored on the server and changes are reversible.

GitHub is a concurrent versioning system.

Concurrent versioning systems store a history of your documents. By keeping a history you don't have to be afraid to accidentally delete things. So if you have a file A and accidentally overwrite it with B you can still retrieve A by going back in history. The history is generated when sending your changes back to the server.

Most cvs, including GitHub, can merge the contents of non-binary files. This means if two people work on the same file, they don't overwrite each others changes. Instead both changes are joined into a new file if possible.

A few technical terms, that are used when talking about cvs.

Commit/Push - Accepting your changes and sending them back to the server.

Revision - The points in history. Created with every commit.

Repository - The place where all the files are kept.

Trunk/Master - The main repository.

Branch/Clone - A copy of trunk, where changes can be made prior to merging it into trunk, or where changes can be made that shall not end up in trunk.

Checkout/Pull - Copy the content of the repository to your computer.

GitHub is a hoster for git repositories. git is a new kind of cvs, which brought about new and old ways of handling repositories. The main change with git is that every checkout is actually a clone. So you can change files locally and commit them locally. Thus creating your own local history. When you're done you push all your changes back to master.

There are basically two ways to work in git. The proper git way. Everyone wishing to participate in a project clones the repository of that project changes it and then informs the owner of the project of the changes (a so called pull request). The owner then has the possibility to review your changes and accept or reject them. The not so proper way (AKA our current method) By granting people the status of collaborator we allow them to directly commit to master. Collaborators do not have to create a clone (which is very easy by the way) and do not have to post a pull request (also very easy). Making it even easier for everyone.


That's longer than I intended but not too long, I hope. :blush:

Thanks, Emperor Krulos - for my inaugural push I added the Blacktron Emblem to library/logos/ :wink:

I just figured out that Res-Q is part of Blackton. *oh2* Awesome.

I'm thinking that the 'elements' directory could get pretty unruly ... // ... maybe it should be pre-sized to all existing square tile sizes, so you'd have a '2x2_big_ben.svg' and '6x6_big_ben.svg'

Personally speaking I think scaling is an issue when printing. I don't think it's wise to have multiple of the same files with a minor deviation. If we do want to keep files like this, then we should automate the process so to minimize the work of the editor. We could for example post square tiles into one folder and execute an XSL-Script to generate the 2x2, 4x4, etc. versions. Still I think this is a printing matter, that should be addressed in the wiki. I'd like to hear more opinions on and arguments for it.

What about including either Bricklink part numbers or official LEGO element IDs in the filenames as well,...

That we should do for official TLG designs, like described in the wiki.

Talking about duplication and Scripts. I looked into linking SVG-files. This isn't handled very well or at all in current renderers. The idea was to add a reference to a logo - for example - so that we only have to add the logo once. Also changes to the logo would affect all decals using it. Sadly this is not really possible at the moment.

We could add an XSL script to handle a custom xml element. This could also lead to automatic generation of faction decals. Create one suit of armor and a script generates a decal for every faction from it.

What do you guys think?

Share this post


Link to post
Share on other sites
I just figured out that Res-Q is part of Blackton. *oh2* Awesome.

HA! I never noticed that before! (Res-Q was after my childhood LEGO time and before my AFoL return).

Personally speaking I think scaling is an issue when printing. I don't think it's wise to have multiple of the same files with a minor deviation. If we do want to keep files like this, then we should automate the process so to minimize the work of the editor. We could for example post square tiles into one folder and execute an XSL-Script to generate the 2x2, 4x4, etc. versions.

Fair points, but then how do you deal with unique shapes that don't really translate to different sizes? A sticker design for a 3x12 wedge:

42061pb21.jpg

is only applicable to that one piece, so scaling it up and down is unnecessary. From my understanding, when you go to print, the output size is determined by the DPI settings as applied to the original dimensions of the design. So a 10" x 10" design will output a 10" square at 300dpi on a 300dpi printer and a 10" square at 150dpi on a 150dpi printer. So from that point of view, scaling is more a design issue than a printing issue.

It was my original intent to create a series of ready-to-use template files for each element and then use those templates to create designs to apply to those elements, similar to the minifigure part templates that are already out there. So a 1x2 tile design, while it could be scaled up to a 2x4 tile (theoretically, I'm not sure if that's actually true) would be ready-to-print at 1x2 tile size.

If a script can be written to give us the flexibility to mix-and-match the way you're describing, then all the better - but it seems to me the effort to write such a complex script isn't worth it in light of how fast it is to duplicate an existing design at a different size using the 'scale' tool in Illustrator (and Inkscape, I'd presume).

Share this post


Link to post
Share on other sites

You use Illustrator? NickAb does too. There is a slight incompatibility with Inkscape concerning scale. Which is why we said we'd scale decals to Inkscape-like dimensions. I just added a page to the wiki, explaining it. Illustrator can be set up to use Inkscapes settings.

I'm sorry I'm a bit behind on the wiki.

@NickAb: If you found that setting, would you mind putting it in the wiki?

Fair points, but then how do you deal with unique shapes that don't really translate to different sizes? A sticker design for a 3x12 wedge:

I never meant not to have decals properly sized. :tongue: If a decal is made for a certain size the name should reflect it of course. I just think that saving the same file under different names is a bit unnecessary.

This might not even be the case. Imagine a decal for 2x2 tile with fine lines. We want to rescale it to 1x1. A simple rescale will possibly make those fine lines impossible to print because a 0.4pt suddenly is 0.1pt. So we'd actually have to do more than a simple rescale. We'd probably have to partially redesign it anyway. Similar to how computer icons have to be designed for different resolutions.

It was my original intent to create a series of ready-to-use template files for each element and then use those templates to create designs to apply to those elements, similar to the minifigure part templates that are already out there.

Please do.

If a script can be written to give us the flexibility to mix-and-match the way you're describing, then all the better - but it seems to me the effort to write such a complex script isn't worth it in light of how fast it is to duplicate an existing design at a different size using the 'scale' tool in Illustrator (and Inkscape, I'd presume).

For this to work the svg markup needs identifiers. So it's writing the script and preparing the files. Of course this is a huge short term investment, but it will pay of in the long term.

We currently have 14 logos in the library and there are even more. Create a small shield, a long shield, an armor, a jester, a king, a chainmail, a padded surcoat, a horse barding, flags, a royal guard, a varsity shirt and maybe even a spacesuit (that's 12) for every faction and you just made 168 decals. Now if this was a one time effort it might not be that much. But I think we'd want to create those for every new faction, maybe even for ones we make up. Also if someone improves say on the black falcon logo, we'd have to change every single use by hand. That seems more costly than writing a script.

Like I said, the source decals would have to be prepared so the script knows where to insert the logo. Something like a named rectangular region for example. Aside from learning how to set that up properly it also implies the limit of such a system. A dragon can fill out a shield better than a rectangle can, but the rectangle limits the size of the dragon. That might be a real bummer. Also one might want different colors on their decals. A blue and white jester versus a red and white one. So we'd either have to tell the script what colors to use or use all colors for all factions.

It's starting to sound less useful than I at first thought. :sceptic:

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.