Wercator 0.5: SVG or Gimp?
Moderator: Forum Moderators
Wercator 0.5: SVG or Gimp?
I'm reimplementing Wercator[*], and am to the point of deciding which rendering backend to create first. I'm considering either the Gimp (except as a "real" plugin, rather than the Gimp-Perl monstrosity of yesteryear) or directly creating an SVG file. SVG is of somewhat more interest to me, since it would allow a commandline-only Wercator, at the surface appears to be the proper format for map-like drawings, and I haven't worked with it before.
However, I'm unsure / insufficiently experienced with SVG to determine if the final product can approach the quality of that produced in the Gimp. I would appreciate the opinions on this matter of any artists who have significant SVG experience. I'm certain there are problems I don't foresee, but what comes to mind include:
Thanks,
-Quensul
[*] In brief, the old (<= 0.4) Wercator grew organically from what was intended to be a quick off-the-cuff project (hah!) into a 3K-line Perl behemoth. It rapidly became very difficult to maintain, as the underlying architecture, such as it was, was not cleanly designed nor modularized. This rewrite in C++ is intended to improve portability, increase modularity, ease maintenance, and split all non-rendering code into a set of libraries. Since all map logic is independent of the rendering logic (and a generic rendering library is being provided), it will be relatively easy to create new Wercator binaries/plugins for different rendering backends, as all that must be implemented is the rendering of static tiles and specified bezier curves into the backend in question. In time, I will likely implement both SVG and Gimp backends, but the second may take a while, hence my question.
However, I'm unsure / insufficiently experienced with SVG to determine if the final product can approach the quality of that produced in the Gimp. I would appreciate the opinions on this matter of any artists who have significant SVG experience. I'm certain there are problems I don't foresee, but what comes to mind include:
- -- How to get the "ink" to properly blend into the parchment (it's unclear if the SVG blur will be sufficient)
-- How to trace lines in different ways (e.g. the 'Pencil Sketch' brush in Gimp, dotted lines, etc.)
-- How feasible manipulating the parchment image will be (tearing, dirtying, adding blood drops, etc.).
Thanks,
-Quensul
[*] In brief, the old (<= 0.4) Wercator grew organically from what was intended to be a quick off-the-cuff project (hah!) into a 3K-line Perl behemoth. It rapidly became very difficult to maintain, as the underlying architecture, such as it was, was not cleanly designed nor modularized. This rewrite in C++ is intended to improve portability, increase modularity, ease maintenance, and split all non-rendering code into a set of libraries. Since all map logic is independent of the rendering logic (and a generic rendering library is being provided), it will be relatively easy to create new Wercator binaries/plugins for different rendering backends, as all that must be implemented is the rendering of static tiles and specified bezier curves into the backend in question. In time, I will likely implement both SVG and Gimp backends, but the second may take a while, hence my question.
Author of Wercator
My understanding is that the shading techniques SVGs use are rather primitive. Thus, SVG might not be a good choice.
PS: Is the new Wercator going to imitate Benji's style, Kestevarn's, or both?
PS: Is the new Wercator going to imitate Benji's style, Kestevarn's, or both?
For I am Turin Turambar - Master of Doom, by doom mastered. On permanent Wesbreak. Will not respond to private messages. Sorry!
And I hate stupid people.
The World of Orbivm
And I hate stupid people.
The World of Orbivm
-
- Posts: 65
- Joined: March 18th, 2005, 9:01 pm
- Location: Boston, MA
I don't have any experience in working programmatically with SVG, but I would suggest splitting Wercator into 2 parts. The first part would take a Wesnoth map and render an SVG image of all the map components. You could put different elements in different layers, like roads, coastlines, structures, mountains, etc. The second part would import the SVG into Gimp and do all the cosmetic stuff like blurring, etc. Since the components are in different layers, you could perform different effects on different components.
This way, someone could generate just the un-blurry SVG and perform their own custom transformations on it, such as adding color, before "inking" it onto the map.
P.S.: Wercator rocks!
This way, someone could generate just the un-blurry SVG and perform their own custom transformations on it, such as adding color, before "inking" it onto the map.
P.S.: Wercator rocks!
That's also my (rudimentary) understanding. However, Benji-style mapmaking doesn't require a great deal of shading, so it might be doable.turin wrote:My understanding is that the shading techniques SVGs use are rather primitive. Thus, SVG might not be a good choice.
Yes. This is mostly dependent on building different brush/tile sets. The other differences (colorizing areas, and so on) won't be that hard to add. Initially, I'll concentrate on Benji-style, since my artistic abilities aren't up to Kestenvarn's level, and I have an existing Gimp brush set (which I could user either as-is or trace over to generate SVG tiles). If an artist were willing to contribute a tileset (in any style), I'd be ecstatic. I would love to have Benji, Kestenvarn, and perhaps a 'rough' or 'Orc' tileset. Oh, and I built in support for arbitrary multitile artifacts from the ground up - think compasses, sea monsters, and really huge mountains, if someone will draw them.turin wrote:PS: Is the new Wercator going to imitate Benji's style, Kestenvarn's, or both?
Right - I should've mentioned that this was my fallback position. It's cludgy, in that we require multiple backends, and if this ends up being the only workable solution I'll likely just use the Gimp, since it does provide some SVG-ish support and any inclusion of the Gimp negates many of the advantages of SVG. What would likely happen is an SVG-generation binary for tiles and tracings, and a separate Gimp "prettifying-only" plugin.entropomorphic wrote:Do it in two steps - SVG, then Gimp.
Thanks!entropomorphic wrote:P.S.: Wercator rocks!
Edited to fix the spelling of Kestenvarn.
Author of Wercator
:bump: Since this is now in Art Development (thanks, frame!), and I've completed the initial implementation of all the renderer-agnostic code, I thought I'd ask one last time: do any of our esteemed artists (1) have experience with SVG, and (2) have an opinion on whether worthwhile "artistic" cartography can be satisfactorily executed using it?
I'm now leaning towards writing the Gimp backend first, as it seems like more complex effects (dirtying or crumpling the parchment and so on) would be very difficult in SVG, but I just don't know.
Opinions?
I'm now leaning towards writing the Gimp backend first, as it seems like more complex effects (dirtying or crumpling the parchment and so on) would be very difficult in SVG, but I just don't know.
Opinions?
Author of Wercator
-
- Retired Terrain Art Director
- Posts: 1113
- Joined: November 29th, 2003, 11:40 pm
- Location: Norway
I don't have much experience with SVG, but I would think going with Gimp would be best for complex effects.Quensul wrote::bump: Since this is now in Art Development (thanks, frame!), and I've completed the initial implementation of all the renderer-agnostic code, I thought I'd ask one last time: do any of our esteemed artists (1) have experience with SVG, and (2) have an opinion on whether worthwhile "artistic" cartography can be satisfactorily executed using it?
I'm now leaning towards writing the Gimp backend first, as it seems like more complex effects (dirtying or crumpling the parchment and so on) would be very difficult in SVG, but I just don't know.
Opinions?