Menu

Import SVG Paths -- workarounds/improvement

Scripting
John_S
2011-11-27
2013-06-05
1 2 > >> (Page 1 of 2)
  • John_S

    John_S - 2011-11-27

    I do not know why a SVG module that can't handle fairly simple paths from Inkscape exists in the first place.

    Okay. The entire reason to import a path is because you are trying for something the basic tools in .AoI don't do well with.

    Just sayin'

    In any event, I've tried coming up with some workarounds. Here's what I'm trying for…

    Simplify path didn't work. Straight SVG export didn't work. There aren't any strokes, but I tried Stroke-to-Path, and that didn't work. Tried a variety of values for the plugin settings for Scaling Factor and Points per Segment (low, high, default0  - that didn't help.

    Any other workarounds for attempting a successful import?  (Keeping in mind the explicit purpose of a module such as this is supposed to be import of complex paths. Therefore this negates the "it wasn't designed for.." arguement.)

    Yes. Some really complex paths will fail. Sure.

    Take a look at the shape. I don't care what the reason is, the hit-or-miss performance on relatively simple shapes should serve as a signal this is one module that needs an upgrade, a rethink, or both.

     
  • Nik Trevallyn-Jones

    Hi JS,

    I do not know why a SVG module that can't handle fairly simple paths from Inkscape exists in the first place.

    Because AOI is open-source, which encourages people to share with others the things that they initially developed for themselves.

    One of the AOI users needed to import some simple SVG; they wrote a script which worked for them, and then shared it with the rest of the AOI community in the hope it might be useful to others.
    They had neither the time nor the skill to write a complete SVG translator.

    Since it is open source, this script can also be enhanced by anyone else in the community; so in response to limitations reported by others, I rewrote much of it, including the parsing, and added support for a number of other forms of SVG.

    For example, I added support for groups of paths being recognised and imported as such..

    To help me do this work, users who were requesting support for other forms of SVG supplied example files for testing, explained the expected output, and gave feedback on the results from my modifications.

    This style of development has its pros and cons:
    pro: It is tightly focused on the actual uses being made by the users at the time;
    con: it usually does not result in an implementation of a complete feature set.

    I understand your frustration with this, and I am not saying that you, or anyone else, should just accept the current script's failings.
    I'm merely answering your question.
    The basic point is that the script was never designed to cover the complete SVG spec, nor even a significant part of it.
    It was simply released to others in the hope it might be useful to them.

    Some time ago, I started on a replacement SVG plugin.
    However, I had other features and plugins that were of higher priority, and there were few complaints about the script, so I stopped working on the plugin.

    You are certainly correct that a fresh implementation designed to support a particular amount of the SVG spec would provide better coverage of possible SVG files, and that is the approach I was taking with the plugin.
    I was basically researching various Java SVG libraries, and intended to build a plugin that used that library to import as much of the SVG feature set supported by that library into AOI.

    I can address the issues with what you are currently attempting in one of two ways:

    a) have you provide sample files; and modify the script to handle those files to produce the results you expect.
    b) restart development of the SVG plugin.

    Option a) will get you a working support of your SVG files in the shortest time, since it is focused on only that, and not in researching and understanding the entire SVG feature set.

    Option b) will take longer, since there will be a period of time in which I research and understand the SVG feature set; search for, find, and possibly test various SVG libraries; and then write the code to use such a library to import and export to/from AOI.

    In terms of relative importance, I will treat option a) as more important.
    This is not because I don't think it is important for AOI to have a more complete support for SVG; but because a) addresses the immediate and real needs of an immediate and real AOI user.

    Let me know how you would like to proceed.

    Whether you choose a) or b), or propose a different c), it would certainly help if I knew which features of SVG your intended files will be using.
    Either a list of SVG features, or one or more sample files would help a lot.

    It would be disappointing to go through all the analysis, coding and testing to produce a plugin that supported a significant amount of the SVG feature set, only to find that it did not support a particular feature that your files often, or even just sometimes used.

    Cheers!
    Nik

     
  • Peter Eastman

    Peter Eastman - 2011-11-27

    If you do decide to write a new SVG plugin, remember that SVG Salamander is now included with AoI.  Not that you have to use it, but it's there, and could probably serve your purpose pretty well.

    Peter

     
  • John_S

    John_S - 2011-11-27

    Forget option "a."  It does no good to have fifteen edge case quick fixes. I don't need this to work only on this file, only to be back to zero on the next edge case. Point of fact, my particular frustration on one file is meaningless lest it contribute a solution to problems many people have.

    Rather better to figure out, from the problems, a big picture solution that not only gets me through this immediate file, but the one after next.

    Better still, some test cases that establish a baseline to work from culled from existing projects. Also keep in mind this is nodes and a path - a cross section of the table legs.

     
  • Nik Trevallyn-Jones

    @Peter - thanks for the reminder. I had remembered that AOI now shipped with an SVG library, so I was going to research that first (both for the SVG import function, and the Vector Renderer).

    @js141

    Forget option "a."

    Ok, so in the absence of information on specific needs (the basis of option a), I have to consider what is generally possible, or likely to be useful, in terms of importing SVG into AOI.

    Firstly, just to be clear: SVG is a 2-dimensional format, and AOI is a 3-dimensional modeller.
    There is actually not much in common between the two, and there are many things in SVG that cannot be imported directly into AOI, since the 3rd dimension is not present in SVG.

    Therefore, when importing from SVG, I currently see that one of 2 things must happen:

    A) The 2D information in SVG is matched to 2D entities in AOI.
    Since the only 2D entity in AOI is a curve, this implies that the SVG information must be mappable to an AOI curve.
    (Hence the current script supporting only SVG paths.)

    B) The 2D information in SVG is mapped to 3D objects in AOI by inferring the 3rd dimensional information for every point that is imported.

    Looking at your table image above (which is really cool, btw), I wonder which of the above processes you are expecting to occur?

    If it is A), then I would really need to see an example file so I can determine what type of data is in the SVG; and how and even if that can be imported to a set of AOI 2D curves.

    If it is B), then we all need to discuss what other information would be needed to allow the importer algorithm to make the correct inferences.
    For example, vanishing points so the algorithm can interpolate the 3rd dimensional data.

    (Option B basically requires the same type of processing as the feature in Sketchup (a 3D tool) which allows a model to be inferred from a photograph (which is 2D data) - is this the sort of thing you have in mind?)

    The other question that needs to be answered regarding B) is to do with workflow:
    Why is a 2D tool being used to generate data that is then inferred to be 3D, rather than a 3D tool being used in the first place?

    Generating the original with missing data, only to try and infer it algorithmically later is both inaccurate and inefficient.

    You mention the "cross section" of a table leg.
    Is any information regarding the cross-section available in the SVG file to begin with, or does all of that need to be inferred from what is basically a set of shaded 2D polygons?

    In your particular case, are you trying to import SVG because you are receiving or sourcing SVG data from somewhere else, and need to generate a 3D model that represents that SVG?

    Or are you using Inkscape to create the SVG representation of your objects?
    If it is the second option, then why aren't you just modelling the objects in 3D in AOI, or some other 3D modelling tool?

    Better still, some test cases that establish a baseline to work from culled from existing projects.

    To be honest, there is currently very little information available to me regarding anyone's current projects that require import from SVG.

    From memory, there have been a small number of posts regarding some other path types in SVG, and those were quite some time ago.
    I will search the forums shortly to see what I can find.

    Hopefully the above is sufficient to start a useful discussion - and hopefully others who need or have needed import from SVG can provide additional information so we can get a clearer idea of what type of processing would be useful, in general, to the users.

    Cheers!
    Nik

     
  • Peter Eastman

    Peter Eastman - 2011-11-28

    Since the only 2D entity in AOI is a curve, this implies that the SVG information must be mappable to an AOI curve.

    That's not exactly true.  Curves, like meshes, are fundamentally 3D objects.  Their vertices can be arranged however you want in three dimensions.  Meshes, like curves, can lie entirely in a plane.  So a 2D shape could be imported either as a curve that happens to lie in a plane, or an open mesh that happens to lie in a plane.

    Peter

     
  • Nik Trevallyn-Jones

    Curves, like meshes, are fundamentally 3D objects.

    Ok, thanks for the correction Peter.
    My memory was a bit vague there. I did recall that I had to treat curves specially in the Vector Renderer, but now you've pointed it out, I recall the difference was actually to do with textures.

    And yes, I was aware that I could import an SVG polygon as a flat mesh - but I saw that as an instance of option B: placing every point of the mesh on a plane is one (simple) algorithm for inferring the 3rd dimension.
    And since I don't really want to write the code for creating a triangle mesh from a non-triangle SVG polygon, I would probably rely on the Polymesh plugin to handle the non-triangle polygons.

    Given JS141 said in the original post that the use of Inkscape was a way to create paths that AOI didn't do well, I am hopeful that option A would generally meet his or her needs.

    If so, then if I ensure that I can map to AOI all the types of paths (and probably polygons) supported by the SVG library of choice (Salamander being first cab off the rank), then I am hopeful that would be a good result for JS141 and others.

    Obviously, further input from JS141 and others would help solidify the plan. :o)

    Cheers!
    Nik

     
  • Peter Eastman

    Peter Eastman - 2011-11-29

    And since I don't really want to write the code for creating a triangle mesh from a non-triangle SVG polygon

    You can always just create a curve, then call convertToTriangleMesh() on it.  That will triangulate it for you.

    Peter

     
  • John_S

    John_S - 2011-11-29

    I am using Inkscape to create a path, imported into AoI, turned into a triangle mesh and extruded. Not a filled object, just the curve. 2D. Very much similar to what would be done in the curve editor of AoI, but more complex.

    Problem being variable curve vector handles at nodes - cusp, angle, curve, symmetric, asymmetric. Basically that is a major reason to go to a SVG editor instead of the onboard curve editor.

    I can turn out several dozen SVG files AoI can't handle. Not a problem. My problem being having those work, and the very next one I create fail. Mirror opposite of your problem of constraining a function set.

     
  • Harald G

    Harald G - 2011-11-29

    As long as AoI did not have an advanced curve editor it would be more than useful to have en excellent import option for SVG. And even with an advanced curve editor or tools that would be the case.

    I provided a link to the same SVG file that some(?) Blender users have used to verify the Blender SVG importer.
    While we're at it: I guess it´s written in Phyton - but can't that logic be used? It has to be simpler than in Blender since Peter and Nik mentioned the only possibility to be mapped to is the aoi curve.

    That would lead me to the "logo" and "island" discuaaion we#ve had with Marc "komatta". An logo with deepth is a breeze in "the other 3D tool" - and will take some time in AoI.

    js141 - usually I simply import those SVG to Blender - extrude it and export to obj - and import in AoI again - easier than
    doing all these tests in AoI. At least thinking in short term.

    I would love to see the workflow of Cheetah3d, where you simply drag and drop your PDF (with vectors) or your SVG into your modeling window, - but I also imagine this could be hard to do for the different OSses.

    I do hope that the SVG Salamander will help to improve that situation a lot (and hopefully we'll see the spline-, beziermeshes option in AoI 3!?).

    Harald

     
  • Nik Trevallyn-Jones

    JS141
    My problem being having those work, and the very next one I create fail. Mirror opposite of your problem of constraining a function set.

    Excellent feedback - thanks.

    So from this, it sounds like my proposal to use an existing SVG library to parse the SVG files, and attempt to map as much of its output as possible to AOI should be a good answer to your problem - yes?

    Cheers!
    Nik

     
  • Nik Trevallyn-Jones

    … ok,

    A quick prototype using the Salamander lib looks very promising.

    I'll try and get something testable in the next couple of days.
    (There will doubtless be various requests for enhancements thereafter … :o)

    Cheers!
    Nik

     
  • Harald G

    Harald G - 2011-11-29

    Nik - that reminds me on the days were a STL Im- and Export took ~ a day from question to release…!
    (Bravo)
    I would only join curves, that are meant to be joined in the SVG file (= paths?).
    But if the importer ask for "Join, Yes or No?", than maybe that is also fine.
    Maybe within a given tolerance. But that sounds complicated then, - but I wouldn't
    care to much for ease of use as long as we get a working  import or SVG paths.
    That would be a 2nd step, or?

    Greetings
    Harald

     
  • John_S

    John_S - 2011-11-29

    So from this, it sounds like my proposal to use an existing SVG library to parse the SVG files, and attempt to map as much of its output as possible to AOI should be a good answer to your problem - yes?

    Yes.

     
  • Nik Trevallyn-Jones

    … just an update:

    I have a working SVGTranslator plugin.

    It has a few issues yet, but the the initial few test files import with expected results.
    - I also have one test file which is producing results that need further investigation…

    I will post in a day or two, an hopefully ha e something that people can usefully test.

    Cheers!
    Nik

     
  • John_S

    John_S - 2011-12-01

    Sounds promising.

    Keep up the good work.

    Question about Work: What's more work intensive?

    …Supporting the SVG spec or rebuilding something akin to Inskape as an advanced curve editor?

    ….Building some kind of advanced terrain editor akin to the plant plugin, or supporting work done in Terragen?

    ….Answering questions about what amounts to a whole new application with each plugin, or supporting the previous learning curve of popular third party applications (also free) many users have learned already?

     
  • Peter Eastman

    Peter Eastman - 2011-12-01

    I just want to point out that Nik is awesome.  But you already knew that.

    Peter

     
  • Nik Trevallyn-Jones

    js141
    Question about Work: What's more work intensive?

    Assuming that you mean these questions to be rhetorical, I'll answer them in that light first :o)

    You point is well taken - applications, particularly Open-Source, prosper when they can leverage existing code.
    Eg, the HelpPlugin, etc…

    However, there are other factors in play, so I'll answer you individual questions more specifically:

    js141
    …Supporting the SVG spec or rebuilding something akin to Inskape as an advanced curve editor?

    Well - given that (apparently) good SVG parsers exist, then probably the former.
    However, if a complete SVG parser had to be written from scratch, and the existing curve-editing features of AOI can be leveraged, then possibly the latter.

    js141
    ….Building some kind of advanced terrain editor akin to the plant plugin, or supporting work done in Terragen?

    hmmm … more difficult.
    It depends on the complexity of importing Terragen data compared to the effort of writing something like the TaPD.
    Even if the effort was equal, I would agree with your implied point that the former would yield a better result.
    So, the issues would be:
       a) how well do the concepts in Terragen map to those in AOI?
       b) how complex is/are the Terragen output file formats?

    **Note that while there are numerous fairly standard ways of representing 3D data, there are no real standard ways to represent textures - particularly calculated textures.

    There is also the question of actual feature sets. Sometimes an alternative implementation is made because desired features aren't supported in the free alternatives.

    In addition, there is the question of free availability, and supported platforms.
    The AOI community overall benefits more from a custom editor like Tapd, if the primary alternative is either not free, or only supported on a single platform (eg Mac, linux, or Windows).

    So … is this a formal request for a Terragen importer??
    I've just looked, and the format looks fairly simple. Terragen also provide a free version, and I've found 2 free Java programs that create Terragen files, so…??

    js141
    ….Answering questions about what amounts to a whole new application with each plugin, or supporting the previous learning curve of popular third party applications (also free) many users have learned already?

    Well, this is a very good point.
    Although, if there are issues or quirks in the mapping between the foramt and AOI, then the support effort required for external formats can be larger than you might think.
    For example, the .OBJ importer is the cause of more support posts than you might expect, mainly because certain .OBJ concepts don't really map into AOI - or because certain apps create either unexpected, or flatly incorrect .OBJ files.

    But given all of the above, you are definitely correct that we, the AOI developers, should investigate external formats and technologies more than we sometimes do,

    Cheers!
    Nik

     
  • Nik Trevallyn-Jones

    I have a question:

    As part of creating an SVG importer, (and in response to comments by users such as Vidiot), it seems that some form of parametric (spline) curve support in AOI would be useful.
    That way we could import SVG directly into spline curves rather than converting them into AOI's approximated curves.

    That then raises the issue of spline-based 3D objects.
    At which point, I get confused as to which types of technology I should consider for support:
    - Splines, bezier curves, NURBS, B-bezier curves, and lots of other alternatives besides.

    I can find resources on the various underlying theory, and it would seem that NURBS would be the most powerful - but perhaps too great a development effort if an open-source Java NURBS library cannot be found.

    So question my questions:

    Q1: Would there be any use my writing and including a new form of AOI curve that supports quadratic and cubic parametric curves?

    Q2: given AOI already supports spline meshes, are there any other forms of parametric meshes that could be useful?

    Cheers!
    Nik

     
  • Harald G

    Harald G - 2011-12-02

    Nik,

    Q1 (I understand:"Would it make sense to think about a new type of curve and/or mesh object inside AoI?)
    Yes.
    Not only that we ask for years, as asking for something doens't make it more useful, but really that would be a killer feature
    in the area of PME (my view and maybe komattas view, I assume).
    AoI could be used for instant 3D logos and (who knows?) Truetype and other fonts would/could be supportet, too?

    I can imagine my 2d graphs für presentation not only in 3D but animated :D

    But:

    I have a working SVGTranslator plugin.

    how about letting js141 test it?
    All the other stuff sounds very much like christmas.

    Harald

     
  • Nik Trevallyn-Jones

    how about letting js141 test it?

    ok  :o).

    SVGTranslator is now in the repository.

    Because it currently depends on the svgSalamander jar, I have marked it as requiring AOI 2.9 and above.

    I can make it compatible with AOI 2.8, as well, but I would either have to download a econd copy of the svgSalamander jar - or risk overwriting the one shipped with AOI.

    **Notes
    1. There are probably bugs - I apologise, but this is the nature of things
    2. There is logic that allows the grouping of objects under null parent objects.
    Currently the controls are disabled, and the importer always groups associated objects under null parent objects.

    3. There are controls for whether the importer converts a closed or closed and filled path into a mesh.
    4. I have a file that shows problems (folds) in the mesh. If you have problems then please report them.
    - As a workaround disable both mesh options (closed and filled) and just import the path.

    @Peter: I am using curve.convertToTriangleMesh().
    You can see the issue here:

    AOI file of imported path:
    https://sourceforge.net/tracker/download.php?group_id=15063&atid=365063&file_id=429833&aid=3445423

    AOI file of imported mesh:
    https://sourceforge.net/tracker/download.php?group_id=15063&atid=365063&file_id=429834&aid=3445423

    I presume it is something I should be doing such as simplify mesh, etc. Any ideas or suggestions?

    Have fun folks!

    Cheers!
    Nik

     
  • John_S

    John_S - 2011-12-02

    Okay, it seems to work on a simplified test file not unlike the table cross section.

    This weekend I will assemble a set of test files and report on results.

     
  • John_S

    John_S - 2011-12-03

    You point is well taken - applications, particularly Open-Source, prosper when they can leverage existing code. Eg, the HelpPlugin, etc…

    Some of your points can be answered by a survey of what's out there first. So, for example, if there is no standard or agreed upon way to support textures; yet there is a moderately popular preexisting app established, might that not be a contributing factor in choosing a development direction - before the project starts.

    The goal is to not reinvent the wheel, saving time, effort and perhaps annoyance for everyone on any side of a development effort. While it may seem like some of these threads may be diverting - putting out fires as it were - there can be some advantages had as well.

    So … is this a formal request for a Terragen importer??

    As for the Terragen thing. I have been fairly successful blending rendered foreground objects into a background environment image. The results are hard to distinguish AoI generated content from the backdrop, so this is a mute point.

    If anything the difference creates a distance fog sort of effect which is just fine and saves rendering time even more. In this case a tutorial for, say, matching up meshes from the Heightfield plugin would be the better choice. Or, when/if updating heightfield considering this method?

    In other words, do into a redesign with the assumption of merging a height field into an existing heightfield as foreground. 

    This is not a request to change anything. I can - or at least have previously - imported Terragen meshes. The back of the mesh can be edited and front used when recreating a foreground so the terrain seems to match within AoI. Layering textures to develop the detail needed for a foreground does prove challenging, but doable.

     
  • Harald G

    Harald G - 2011-12-03

    This is not a one step thing, - but it's not hard to do and might give you an idea what this plugin could do.

    I opend the file from Nik above - there are issues with smoothing and (my guess) some issues with numbering of vertices.
    Set smoothing -> none. Triangulate and convert to PME.
    In PME choose one face on one "leaf" and press shift + x several times to choose all faces connected.
    Then choose "merge".
    You'll end up with one face consisting of hundreds of vertices. No problem.
    "Ticken mesh" or use the combined bevel -extrude tool. (You can do that one all three leafs simultaniously, when the option is set to "individual")

    I also "opened" one leaf to show nearly what splinemeshes could do with curves inside curves.

    I keep my thumbs pressed or fingers crossed (or both if it helps)

    Harald
    Happens to work

     
1 2 > >> (Page 1 of 2)

Log in to post a comment.