Hey, I pushed a new commit that removes that shadows in the components:
1 Like
I am a graphic designer with some user experience design experience. I admittedly have almost no experience in coding, however, I am so incredibly curious about whether or not I can add into VCV’s amazing creative community. I have found that many of the modules in VCV are a little (more than a little) visually confusing or busy. With all that said, I am just looking for where to start learning.
I have some questions and not a lot of answers.
Would the creation of .svg files be enough for module creators to implement? is it far more intensive (and code-driven) than that?
If it is code-intensive, are there any coders out there who might want to team up with graphic designers or is there simply a bigger push to create assets for coders to use for better design?
I was going to say the same thing. I did a mockup recently with no text labels, just really good tooltips. but it was bad, no one would have used it.
There’s no single answer for that. Some people do a lot of drawing in code, some people use 100% SVG. My guess is that a solid majority just use SVG, but that’s a total guess. @Vortico would have a much better guess.
1 Like
There’s a few things to know:
- Nanovg, VCV’s rendering engine, only implements a small subset of SVG. Many basic features break. You can’t import something straight out of Inkscape/Illustrator/etc. and have it work. You can’t even import complex shapes and have them work: often they break mysteriously and require edits. And the performance is very poor compared to how a web browser renders SVG. It’s the main reason so many modules have minimalist looks: nobody wants to bother with all those quirks.
- A lot of things are hardcoded. Some modules don’t even use SVG files at all and do all their rendering from code. How easy it will be to collab with a developer depends on their process.
- The placement of widgets (jacks, buttons, knobs, etc) is done in code. There is a helper script, but it’s only useful if you have a very formal development process, where everything is specified and designed before you start coding. Except for ports of real hardware, that’s never the case, of course. But if your coding process is exploratory, it also can make it easy to move around logical blocks until you’re happy with them. For example, for this module, I only define the position of elements of a node once, then place 16 copies of it, and I also have smaller variants of this module sharing code.
1 Like
All that is true. the placement code isn’t that big an issue, I don’t think. I place all my widgets in my prototype using a drawing tool. When I like it I read the x and y right out of the drawing too l and plug it straight into code. It doesn’t take much time.
1 Like
Is there a better thread or resource for learning about the limitations of Nanovg? What about for developers looking for design help?
Also thank you guys again!
nanovg doesn’t know what SVG is. Rack uses nanosvg to parse SVG files, but to render them, I wrote a nanosvg renderer using nanovg. My renderer has all features I need and I believe everyone else needs. If I’m wrong and you need more features, open a feature request. https://vcvrack.com/manual/Issues
1 Like
The Hanovg github page has some docs and some demos. It you search around here you will probably find more info.
When the topic comes up, it’s generally settled by saying that those tools enable aesthetics you don’t like, e.g., limited gradient support because you think they look bad, so it seems reasonable to assume those requests would never be considered.
What is limited about Rack’s gradient rendering? It supports linear and radial gradients. If you can describe what you need and why you need it in a feature request, it will be considered for a future version of Rack.
Can you defend this statement?
And this one
And this one.
In my experience, Rack’s SVG renderer is extremely fast and supports nearly every SVG panel design that one can make.
2 Likes
This is related to rendering in general, not SVG in particular, but I have learned by now that if I ever accidentally zoom a busy patch, I might as well relaunch the rack, or I end up with a very long redraw and broken panel graphics. My hardware is definitely not the cause (desktop PC with i7-4790 & Radeon RX 580).
Maybe nanovg has better performance metrics than I give it credit, but the subjective speed of drawing any busy patch on my machine makes me feel like I’m pushing the graphics engine too hard.
I had many shapes break on me for sure! The most common problem is for the renderer to fill in a part of a shape that should be hollow. Tweaking the control points manually around the problem area tends to solve those issues. I have no idea what causes the issue.
You don’t even want to know the hours of trial and error it took to get the graphics from Arcane to work, and they sure don’t look as clean as they could have looked, I had to make compromises.
Well, when files render in most SVG software but not in Rack.
I’m not a SVG expert so I don’t know exactly what features are supported or not, and which features which software actually use. I just understand that SVG has an absurdly large feature set and only a small subset is used in practice.
Inkscape allows exporting “Plain Svg” without its non-standard extensions, but it’s not always enough. Sometimes, taking parts of my graphics through an optimizer helped get them to render in Rack.
There’s always more than one way to draw things so when something doesn’t work, I don’t bother investigating and just try another way, and memorize which features tend to work well or not. I also test graphics in Rack very often so I avoid having to trash too much work if something won’t render as expected. It’s definitely not a fun workflow.
I’ve never heard of any of the problems, in performance and correctness, that you’re describing. Did you ever open bug reports for these specifying your hardware? I’m not good at mind-reading, so you have to help me out a bit if you want your problems fixed.
1 Like
I thought Rack did not support radial gradients? Whenever I tried that in the past they didn’t work and I had to fudge it using multiple linear gradients - is the support for radial new? Also I can’t think of a single panel design where radial gradients are used, but I know of a few others where radial ‘look’ has been fudged using linear.
Other than that I have never run into any problems whatsoever with Rack’s SVG rendering (other than having to export final SVGs from inkscape). Never a broken shape or anything like that - SVGs always render as expected in my experience.
Looks like there’s code for radial gradients in Rack, but it’s not finished. If you need them, open a feature request so we can discuss your requirements.
1 Like
will do - thanks 
So far the subtext of all the messaging on the topic has been that the limitations of the graphics engine are intentional, to foster a minimalist aesthetic, so I didn’t think it was worth reporting, I fully expected to be told the guidelines suggest using flat design and that my graphic style is out of the supported scope.
In that case I’ll try to generate a good example of a complex shape missing a hollow part and submit it on the issue tracker, it should be easy to reproduce.
Regarding performance after zooming, I’m specifically referring to this known issue: https://github.com/VCVRack/Rack/issues/1335
So are you meaning that most .svg will work just fine?
Also, Is there a list of do’s and don’ts for .svg files somewhere?
Thank you! 