(2026-01-20, 22:07)Travis Cobbs Wrote: I think that the only way that SVG could reasonably be supported by LDraw programs would be via a 3rd-party library that renders the SVG to an in-memory bitmap image that could then be used as the texture. Creating custom SVG parsers in LDraw programs seems like the wrong solution.
Although I'm not informed on the technical details, I can recognize that support for direct parsing of SVG textures may not be the right approach, especially if LDraw code is supported by texmap. An in-memory bitmap is closest to what I imagined, but if LDraw geometry can be projected as a texture then perhaps it's more of a translation issue. It may be enough to be able to import an SVG file and convert it to LDraw using an existing tool, which could act as a plugin to a modeling program (similar to the many tools incorporated with LDPE).
The potential pitfall is losing the scalability especially of curved geometry, which must necessarily be down-sampled when converting from SVG to LDraw. The solution I'd really like to see would be expanding the LDraw format to somehow represent curved lines and surfaces (beyond simply using curved primitives). But that's another topic…
Quote:I for one feel that supporting SVG for textures would be a bad idea, but I won't completely rule out the possibility of support in LDView if people push for it.
What do you feel are the drawbacks of supporting SVG?
Quote:Note: I created SvgToDat 7 years ago, but as per its README: "Only works with a subset of SVG geometric primitives."
Was it 7, or 17?
There are three tools I'm aware of: yours, T. Boschi's svg2dat, and Lasse's svg2ldraw.
(2026-01-20, 22:34)Orion Pobursky Wrote: I'll note that SVG textures will only be supported by the Library if LDView supports them. If we choose to allow a "Subset of SVG geometric primitives", then that subset will need to be very sharply defined so that the Library can validate the files.
I'll also note that the PHP SVG capabilies rely on ImageMagick which in turn relies on librsvg which, by thier own documentation, does not aim to "implement every single SVG feature that is in the spec".
This is a good point. SVG does an awful lot of stuff that isn't relevant to our purposes (and it probably doesn't do some things that are, such as materials), so full parsing ability would certainly be overkill. This would likely mean very specific restrictions on allowable SVG content, which would likely mean more pre-processing in Inkscape or wherever, both to clean the file to allowable specs and perhaps also to re-map certain things like colors and materials to LDraw-usable form.
This is important because, to me, the greatest benefit to supporting SVG would be to reduce the workflow for authors and hopefully expand opportunities for contributors, especially with patterned parts.
Right now it's fairly time-consuming to go from a reference image to LDraw code, but once you have that, you're basically finished (unless it's a curved pattern, but being able to texmap LDraw code would alleviate that).
With SVG the situation is reversed: it's quite simple to go from reference image to SVG, but then a fair amount of work remains to translate that to LDraw code. So it's that final step where I see an opportunity to increase participation, whether by way of conversion/translation, or actual rendering support.