Thinking about it further and looking at your most recent image paste, seems more than just order too though no? The colors appear off as well, like it’s taking one path’s (either prior or next) display style for the current path.
Rounded rects don’t really work either, certainly not for a simple case I’m trying.
The doc suggests:
/*
* According to Basic Shapes — SVG 2
* rounded corner should be rendered to elliptical arc, but bezier curve does the job well enough
*/
however in the svg I’ve included below the ry is set and rx isn’t, yet it looks like without rx the bezier is simply ignored or is so minuscule that it’s impossible to see.
Adding a rx to be some non-zero number less than the width will add at least some rounding.
Yep, I confirm that. The same happens if there is rx but no ry.
The function SVGLoader.parseRectNode perhaps should set rx = ry and vice versa if the other value is 0? I don’t really know. What do you think people? @Mugen87?
I have in my local sandbox modified the svg loader to include the id and name, I manually inside inkscape set the ids as incrementing from index 0 to persist the display order, which has the rendering significantly improved when I read the shapes in. There are a variety of issues though.
Any translation or matrix operations in sub elements causes havok with threejs. This proves difficult to fix since inkscape will often simply adjust an elements positioning/parameters via translation/matrix operations (which makes sense) but threejs simply seems to only support one translation, which is applied to the ENTIRE object.
as mentioned earlier any sci-notification in the file the loader is unhappy with
I managed to manually manipulate or create by hand the vector images I want to use so I’m not dead in the water but rather than spending the last 3 days programming I have been manipulating and experimenting with the svg files to get them to display as I expect. It’s a long and painful process since I am NOT an artist. I looked into some preexisting SVG libraries out there but porting or mining the functionality out of them into threeJS would be pretty hard and well beyond my math skill level. ThreeJS implementation of SVG works but only for pretty simplistic cases and is only about 60% compatible with Inkscape.
I tried to keep it simple and include the translate options. for me this renders poorly and looks something like this. I’m using the same render / load code as the example.
very cool, because I’ve modified my own version of SVGLoader (to include id and name properties with the path/shape transformation) I can’t use your changes directly but I have merged your changes into mine. I’ll try and find some time to test them but your screenshot above suggests that it is much improved.
Thanks again for fixing this pretty big issue. I’ll reply to this thread if I find anything else odd. The order issue is still a big elephant in the room but I have a work around at least so I can continue.
Yep I have something like already, nothing terribly fancy. I also took out the meta data spam too, it clutters the log I find but I suppose it has some value, maybe a configuration option for the loader?
case 'metadata':
// ignore metadata, logging it is annoying
break;
case 'rdf:RDF':
// ignore RDF
break;
case 'cc:Work':
// ignore cc:work
break;
case 'dc:format':
// ignore dc
break;
case 'dc:type':
// ignore dc
break;
case 'dc:title':
// ignore
break;
case 'defs':
// ignore
break;
case 'sodipodi:namedview':
// ignore
break;