Loading ...
Sorry, an error occurred while loading the content.

REQUEST: SVG / XML guru......

Expand Messages
  • yohoodi
    Hello All.... just to say that as a result of recent developments for the ebook... primarily vector based heightmaps.. I ve got the feeling that the toolkit
    Message 1 of 13 , Sep 13, 2011
    • 0 Attachment
      Hello All....

      just to say that as a result of recent developments for the ebook... primarily vector based heightmaps.. I've got the feeling that the toolkit mught be able to 'read' or 'construct' a toolpath based on the XML data of an .SVG heightmap...

      There are facts that support the concept...

      If you employ the kerkythea render app then you'll know that it uses an export plugin for gmax that writes the scene to XML.. so theres no doubt that the vertex and face data within a 3D surface CAN be stored and reconstructed within the XML format...

      It says in the InkScape 'Advanced' tutorial that the real power of inkscape is that the XML structure of the SVG file can be freely edited and so forth... logic therefore dictates that the colour values within the 'image' are stored in a 'discreet' manner.. it should be possible to read these values and process or translate them to vertex locations in 3D space... connect them up and you've got a path shape... I think...

      I think it can go both ways.. and kerkythea definitely proves one aspect of that... as well as some work I've done with very well known high end relief generation software. The software in question can load a 3D mesh surface.. and then derive a shaded heightmap.. based on the existing 3D data... XML / SVG is the obvious interchange for this..

      Anyway.. that's the theory.. there are so many applications for this if it works...

      SVG import into gmax.... relief toolpathing.. mapped across non-uniform non-planar geometry.. ... reading in BOTH the path shape AND the height data for intaglio or V-Carving straight from the SVG... these popped out straight away... but there are many other twists you could put on this...

      If there's anyone who has a grip of SVG and XML formats and their interpretation / manipulation as data, I think it could potentially be of serious impact to the way toolpaths can be built 'automatically'.. to be honest... I think a lot of people are toolpathing on the basis of SVG heightmap / XML manipulation already..

      TTFN

      Danny
    • yohoodi
      ... Hi again... that was quickkkk... I stupidly forgot to say I ve got something simple in mind that we should be able to work on to test / develop this...
      Message 2 of 13 , Sep 13, 2011
      • 0 Attachment
        --- In CNC_Toolkit@yahoogroups.com, "yohoodi" <yohoodi@...> wrote:
        >
        >

        Hi again...

        that was quickkkk...

        I stupidly forgot to say I've got something simple in mind that we should be able to work on to 'test' / develop this... so it's not just chit chat...

        To go any further I need someone who could take my files and see the correlation between an SVG generated heightmap.... the 3D surface it produces and the same surface as XML.. generated by kerkythea.

        We then need to discover how the values from the SVG might be directly 'inserted' into the same type of structure/format that we see in the XML output from kerkythea...

        Hope this helps

        Danny


        >
        > Hello All....
        >
        > just to say that as a result of recent developments for the ebook... primarily vector based heightmaps.. I've got the feeling that the toolkit mught be able to 'read' or 'construct' a toolpath based on the XML data of an .SVG heightmap...
        >
        > There are facts that support the concept...
        >
        > If you employ the kerkythea render app then you'll know that it uses an export plugin for gmax that writes the scene to XML.. so theres no doubt that the vertex and face data within a 3D surface CAN be stored and reconstructed within the XML format...
        >
        > It says in the InkScape 'Advanced' tutorial that the real power of inkscape is that the XML structure of the SVG file can be freely edited and so forth... logic therefore dictates that the colour values within the 'image' are stored in a 'discreet' manner.. it should be possible to read these values and process or translate them to vertex locations in 3D space... connect them up and you've got a path shape... I think...
        >
        > I think it can go both ways.. and kerkythea definitely proves one aspect of that... as well as some work I've done with very well known high end relief generation software. The software in question can load a 3D mesh surface.. and then derive a shaded heightmap.. based on the existing 3D data... XML / SVG is the obvious interchange for this..
        >
        > Anyway.. that's the theory.. there are so many applications for this if it works...
        >
        > SVG import into gmax.... relief toolpathing.. mapped across non-uniform non-planar geometry.. ... reading in BOTH the path shape AND the height data for intaglio or V-Carving straight from the SVG... these popped out straight away... but there are many other twists you could put on this...
        >
        > If there's anyone who has a grip of SVG and XML formats and their interpretation / manipulation as data, I think it could potentially be of serious impact to the way toolpaths can be built 'automatically'.. to be honest... I think a lot of people are toolpathing on the basis of SVG heightmap / XML manipulation already..
        >
        > TTFN
        >
        > Danny
        >
      • dprice@mhsw.com
        Danny, If you are still looking for somebody I might be able to help. I am an experienced software engineer, but I am new to CNC and the tools you are using.
        Message 3 of 13 , Sep 14, 2011
        • 0 Attachment
          Danny,

          If you are still looking for somebody I might be able to help. I am an
          experienced software engineer, but I am new to CNC and the tools you are
          using. I am familiar with XML, but SVG is new to me. I have made it
          through about half of the CNC_Toolkit tutorial and that is my only
          exposure to GMAX.

          I know that is a lot of disclaimers, but if nobody else has stepped
          forward and if this is not time critical I would be willing to give it a
          go.

          -Dave P.

          >
          >
          > --- In CNC_Toolkit@yahoogroups.com, "yohoodi" <yohoodi@...> wrote:
          >>
          >>
          >
          > Hi again...
          >
          > that was quickkkk...
          >
          > I stupidly forgot to say I've got something simple in mind that we should
          > be able to work on to 'test' / develop this... so it's not just chit
          > chat...
          >
          > To go any further I need someone who could take my files and see the
          > correlation between an SVG generated heightmap.... the 3D surface it
          > produces and the same surface as XML.. generated by kerkythea.
          >
          > We then need to discover how the values from the SVG might be directly
          > 'inserted' into the same type of structure/format that we see in the XML
          > output from kerkythea...
          >
          > Hope this helps
          >
          > Danny
          >
          >
          >>
          >> Hello All....
          >>
          >> just to say that as a result of recent developments for the ebook...
          >> primarily vector based heightmaps.. I've got the feeling that the
          >> toolkit mught be able to 'read' or 'construct' a toolpath based on the
          >> XML data of an .SVG heightmap...
          >>
          >> There are facts that support the concept...
          >>
          >> If you employ the kerkythea render app then you'll know that it uses an
          >> export plugin for gmax that writes the scene to XML.. so theres no doubt
          >> that the vertex and face data within a 3D surface CAN be stored and
          >> reconstructed within the XML format...
          >>
          >> It says in the InkScape 'Advanced' tutorial that the real power of
          >> inkscape is that the XML structure of the SVG file can be freely edited
          >> and so forth... logic therefore dictates that the colour values within
          >> the 'image' are stored in a 'discreet' manner.. it should be possible to
          >> read these values and process or translate them to vertex locations in
          >> 3D space... connect them up and you've got a path shape... I think...
          >>
          >> I think it can go both ways.. and kerkythea definitely proves one aspect
          >> of that... as well as some work I've done with very well known high end
          >> relief generation software. The software in question can load a 3D mesh
          >> surface.. and then derive a shaded heightmap.. based on the existing 3D
          >> data... XML / SVG is the obvious interchange for this..
          >>
          >> Anyway.. that's the theory.. there are so many applications for this if
          >> it works...
          >>
          >> SVG import into gmax.... relief toolpathing.. mapped across non-uniform
          >> non-planar geometry.. ... reading in BOTH the path shape AND the height
          >> data for intaglio or V-Carving straight from the SVG... these popped out
          >> straight away... but there are many other twists you could put on
          >> this...
          >>
          >> If there's anyone who has a grip of SVG and XML formats and their
          >> interpretation / manipulation as data, I think it could potentially be
          >> of serious impact to the way toolpaths can be built 'automatically'.. to
          >> be honest... I think a lot of people are toolpathing on the basis of SVG
          >> heightmap / XML manipulation already..
          >>
          >> TTFN
          >>
          >> Danny
          >>
          >
          >
          >
        • yohoodi
          Hi there, Thanks very much for your response... No it s not time critical.. Initially it s more to have someone with a knowledge of XML take a look at some
          Message 4 of 13 , Sep 15, 2011
          • 0 Attachment
            Hi there,

            Thanks very much for your response...

            No it's not time critical.. Initially it's more to have someone with a knowledge of XML take a look at some inkscape files..If you could do this (at your convenience) it would be extremely useful towards establishing if this is even possible.

            Initially we would need to establish just how inkscape is storing solid fill and gradient data using XML.. Is it there to be read in the first place ?... kind of thing.

            If you could take a look at a really simple .SVG example to begin with. (you can probably generate it yourself). Draw something like a square.. use the 'fill and stroke' options to apply a solid colour.. any colour... then examine the file as XML (shft-ctrl-X.. I think) and see what it reveals to the educated eye. how is path shape, node distribution stored.. what is the data that defines the fill. is it based on the path boundary's ?... If you can establish any of these facts then we'll know if it's worth going any further.

            I have also raised this today with Var, the author of the GCodetools Inkscape extension... he grasped the principle of what I meant.. but I'm not sure he saw the application.. however he WAS very helpful with something else....

            One of the potential applications for this is FREE vector based V-Carving.. I raised this with Var... He told me there's an 'engraving' process within the existing gcodetools extension that generates V-Carving toolpaths..

            According to Var, gcodetools 'engraving' process calculates a centerline path for the shape.. just like centerline vectorisation... and then it derives pass depth based on user specified tool data and the shape. It varies Z height when the shape thins or thickens.. and it cuts sharp corners...

            He sent me this link to some images.. and says they could do with more photos and feedback in relation to this part of gcodetools

            http://cnc-club.ru/forum/download/fi...=631&mode=view

            obviously I am planning on doing just that...

            I still DO think it's worth chasing the possibility of a direct XML based import of .SVG gradient height data. We can apply this in gmax in many ways.. but the inkscape guys aren't really that interested in / aware of gmax possibilities...

            Again, can't thank you enough for the willingness to take a peep at this..

            Best Regards

            Danny

            --- In CNC_Toolkit@yahoogroups.com, dprice@... wrote:
            >
            > Danny,
            >
            > If you are still looking for somebody I might be able to help. I am an
            > experienced software engineer, but I am new to CNC and the tools you are
            > using. I am familiar with XML, but SVG is new to me. I have made it
            > through about half of the CNC_Toolkit tutorial and that is my only
            > exposure to GMAX.
            >
            > I know that is a lot of disclaimers, but if nobody else has stepped
            > forward and if this is not time critical I would be willing to give it a
            > go.
            >
            > -Dave P.
            >
            > >
            > >
            > > --- In CNC_Toolkit@yahoogroups.com, "yohoodi" <yohoodi@> wrote:
            > >>
            > >>
            > >
            > > Hi again...
            > >
            > > that was quickkkk...
            > >
            > > I stupidly forgot to say I've got something simple in mind that we should
            > > be able to work on to 'test' / develop this... so it's not just chit
            > > chat...
            > >
            > > To go any further I need someone who could take my files and see the
            > > correlation between an SVG generated heightmap.... the 3D surface it
            > > produces and the same surface as XML.. generated by kerkythea.
            > >
            > > We then need to discover how the values from the SVG might be directly
            > > 'inserted' into the same type of structure/format that we see in the XML
            > > output from kerkythea...
            > >
            > > Hope this helps
            > >
            > > Danny
            > >
            > >
            > >>
            > >> Hello All....
            > >>
            > >> just to say that as a result of recent developments for the ebook...
            > >> primarily vector based heightmaps.. I've got the feeling that the
            > >> toolkit mught be able to 'read' or 'construct' a toolpath based on the
            > >> XML data of an .SVG heightmap...
            > >>
            > >> There are facts that support the concept...
            > >>
            > >> If you employ the kerkythea render app then you'll know that it uses an
            > >> export plugin for gmax that writes the scene to XML.. so theres no doubt
            > >> that the vertex and face data within a 3D surface CAN be stored and
            > >> reconstructed within the XML format...
            > >>
            > >> It says in the InkScape 'Advanced' tutorial that the real power of
            > >> inkscape is that the XML structure of the SVG file can be freely edited
            > >> and so forth... logic therefore dictates that the colour values within
            > >> the 'image' are stored in a 'discreet' manner.. it should be possible to
            > >> read these values and process or translate them to vertex locations in
            > >> 3D space... connect them up and you've got a path shape... I think...
            > >>
            > >> I think it can go both ways.. and kerkythea definitely proves one aspect
            > >> of that... as well as some work I've done with very well known high end
            > >> relief generation software. The software in question can load a 3D mesh
            > >> surface.. and then derive a shaded heightmap.. based on the existing 3D
            > >> data... XML / SVG is the obvious interchange for this..
            > >>
            > >> Anyway.. that's the theory.. there are so many applications for this if
            > >> it works...
            > >>
            > >> SVG import into gmax.... relief toolpathing.. mapped across non-uniform
            > >> non-planar geometry.. ... reading in BOTH the path shape AND the height
            > >> data for intaglio or V-Carving straight from the SVG... these popped out
            > >> straight away... but there are many other twists you could put on
            > >> this...
            > >>
            > >> If there's anyone who has a grip of SVG and XML formats and their
            > >> interpretation / manipulation as data, I think it could potentially be
            > >> of serious impact to the way toolpaths can be built 'automatically'.. to
            > >> be honest... I think a lot of people are toolpathing on the basis of SVG
            > >> heightmap / XML manipulation already..
            > >>
            > >> TTFN
            > >>
            > >> Danny
            > >>
            > >
            > >
            > >
            >
          • rainnea
            This looks like it has a lot of potential ! Rab http://www.cnc-toolkit.com
            Message 5 of 13 , Sep 16, 2011
            • 0 Attachment
              This looks like it has a lot of potential !
              Rab
              http://www.cnc-toolkit.com

              --- In CNC_Toolkit@yahoogroups.com, "yohoodi" <yohoodi@...> wrote:
              > Hi there,
              >
              > Thanks very much for your response...
              >
              > No it's not time critical.. Initially it's more to have someone with a knowledge of XML take a look at some inkscape files..If you could do this (at your convenience) it would be extremely useful towards establishing if this is even possible.
              >
              > Initially we would need to establish just how inkscape is storing solid fill and gradient data using XML.. Is it there to be read in the first place ?... kind of thing.
              >
              > If you could take a look at a really simple .SVG example to begin with. (you can probably generate it yourself). Draw something like a square.. use the 'fill and stroke' options to apply a solid colour.. any colour... then examine the file as XML (shft-ctrl-X.. I think) and see what it reveals to the educated eye. how is path shape, node distribution stored.. what is the data that defines the fill. is it based on the path boundary's ?... If you can establish any of these facts then we'll know if it's worth going any further.
              >
              > I have also raised this today with Var, the author of the GCodetools Inkscape extension... he grasped the principle of what I meant.. but I'm not sure he saw the application.. however he WAS very helpful with something else....
              >
              > One of the potential applications for this is FREE vector based V-Carving.. I raised this with Var... He told me there's an 'engraving' process within the existing gcodetools extension that generates V-Carving toolpaths..
              >
              > According to Var, gcodetools 'engraving' process calculates a centerline path for the shape.. just like centerline vectorisation... and then it derives pass depth based on user specified tool data and the shape. It varies Z height when the shape thins or thickens.. and it cuts sharp corners...
              >
              > He sent me this link to some images.. and says they could do with more photos and feedback in relation to this part of gcodetools
              >
              > http://cnc-club.ru/forum/download/fi...=631&mode=view
              >
              > obviously I am planning on doing just that...
              >
              > I still DO think it's worth chasing the possibility of a direct XML based import of .SVG gradient height data. We can apply this in gmax in many ways.. but the inkscape guys aren't really that interested in / aware of gmax possibilities...
              >
              > Again, can't thank you enough for the willingness to take a peep at this..
              >
              > Best Regards
              >
              > Danny
              >
            • dprice@mhsw.com
              Danny, Yes, both Inkscape and the SVG files it creates are accessible and modifiable in fairly straightforward ways. 1. Inkscape is an open source project
              Message 6 of 13 , Sep 16, 2011
              • 0 Attachment
                Danny,

                Yes, both Inkscape and the SVG files it creates are accessible and
                modifiable in fairly straightforward ways.

                1. Inkscape is an open source project which means that the source code for
                Inkscape itself is available for modification and they encourage
                contributions from outside people to help develop the tool. Plug-ins and
                add-ons (like GCodeTools) are welcome and encouraged.

                2. Inkscape conforms (mostly) to the W3C standard for CVS files. Yes the
                data is there and it is accessible and viewable for people as well as
                programs.

                Each object type (rectangle, circle, polyline, etc.) has a defined set of
                parameters set by the W3C (World Wide Web Consortium). The definitions
                that explain how the data is stored are available at the W3C website.
                Their tutorial is a great place to start as they explain the parameters
                available for each object that is supported by SVG and you can play with
                each object interactively by changing the XML and viewing the results
                immediately in a browser window.

                Here is a link:
                http://www.w3schools.com/svg/default.asp

                Bottom line - yes the data is available and could be modified.

                I haven't downloaded any source, but I have looked at the XML and verified
                my comments above.

                Here is a method you can use to see the XML / source data for your SVG
                files in a nice and easy-to-read format:

                1. Open your SVG file in a web browser - I have tried this with MS
                Internet Explorer and Google Chrome (NOTE must be IE 9.0 or later):
                a) Open your browser, then drag and drop the SVG file into it
                i) In IE the source will be shown immediately
                ii) In Google Chrome the images will be shown, but if you right-click
                and select "View page source" you will see the XML Source.

                b) Scroll down to the area that begins with "<g inkscape:label=..."
                This is where the object definitions and data begin.

                The W3C tutorial website provides a guide for interpreting the data.

                Does this help?

                -Dave P.
                >
                >
                >
                >
                >
                > Hi there,
                >
                > Thanks very much for your response...
                >
                > No it's not time critical.. Initially it's more to have someone with a
                > knowledge of XML take a look at some inkscape files..If you could do this
                > (at your convenience) it would be extremely useful towards establishing if
                > this is even possible.
                >
                > Initially we would need to establish just how inkscape is storing solid
                > fill and gradient data using XML.. Is it there to be read in the first
                > place ?... kind of thing.
                >
                > If you could take a look at a really simple .SVG example to begin with.
                > (you can probably generate it yourself). Draw something like a square..
                > use the 'fill and stroke' options to apply a solid colour.. any colour...
                > then examine the file as XML (shft-ctrl-X.. I think) and see what it
                > reveals to the educated eye. how is path shape, node distribution
                > stored.. what is the data that defines the fill. is it based on the path
                > boundary's ?... If you can establish any of these facts then we'll know if
                > it's worth going any further.
                >
                > I have also raised this today with Var, the author of the GCodetools
                > Inkscape extension... he grasped the principle of what I meant.. but I'm
                > not sure he saw the application.. however he WAS very helpful with
                > something else....
                >
                > One of the potential applications for this is FREE vector based
                > V-Carving.. I raised this with Var... He told me there's an 'engraving'
                > process within the existing gcodetools extension that generates V-Carving
                > toolpaths..
                >
                > According to Var, gcodetools 'engraving' process calculates a centerline
                > path for the shape.. just like centerline vectorisation... and then it
                > derives pass depth based on user specified tool data and the shape. It
                > varies Z height when the shape thins or thickens.. and it cuts sharp
                > corners...
                >
                > He sent me this link to some images.. and says they could do with more
                > photos and feedback in relation to this part of gcodetools
                >
                > http://cnc-club.ru/forum/download/fi...=631&mode=view
                >
                > obviously I am planning on doing just that...
                >
                > I still DO think it's worth chasing the possibility of a direct XML based
                > import of .SVG gradient height data. We can apply this in gmax in many
                > ways.. but the inkscape guys aren't really that interested in / aware of
                > gmax possibilities...
                >
                > Again, can't thank you enough for the willingness to take a peep at this..
                >
                > Best Regards
                >
                > Danny
                >
                > --- In CNC_Toolkit@yahoogroups.com, dprice@... wrote:
                >>
                >> Danny,
                >>
                >> If you are still looking for somebody I might be able to help. I am an
                >> experienced software engineer, but I am new to CNC and the tools you are
                >> using. I am familiar with XML, but SVG is new to me. I have made it
                >> through about half of the CNC_Toolkit tutorial and that is my only
                >> exposure to GMAX.
                >>
                >> I know that is a lot of disclaimers, but if nobody else has stepped
                >> forward and if this is not time critical I would be willing to give it a
                >> go.
                >>
                >> -Dave P.
                >>
                >> >
                >> >
                >> > --- In CNC_Toolkit@yahoogroups.com, "yohoodi" <yohoodi@> wrote:
                >> >>
                >> >>
                >> >
                >> > Hi again...
                >> >
                >> > that was quickkkk...
                >> >
                >> > I stupidly forgot to say I've got something simple in mind that we
                >> should
                >> > be able to work on to 'test' / develop this... so it's not just chit
                >> > chat...
                >> >
                >> > To go any further I need someone who could take my files and see the
                >> > correlation between an SVG generated heightmap.... the 3D surface it
                >> > produces and the same surface as XML.. generated by kerkythea.
                >> >
                >> > We then need to discover how the values from the SVG might be directly
                >> > 'inserted' into the same type of structure/format that we see in the
                >> XML
                >> > output from kerkythea...
                >> >
                >> > Hope this helps
                >> >
                >> > Danny
                >> >
                >> >
                >> >>
                >> >> Hello All....
                >> >>
                >> >> just to say that as a result of recent developments for the ebook...
                >> >> primarily vector based heightmaps.. I've got the feeling that the
                >> >> toolkit mught be able to 'read' or 'construct' a toolpath based on
                >> the
                >> >> XML data of an .SVG heightmap...
                >> >>
                >> >> There are facts that support the concept...
                >> >>
                >> >> If you employ the kerkythea render app then you'll know that it uses
                >> an
                >> >> export plugin for gmax that writes the scene to XML.. so theres no
                >> doubt
                >> >> that the vertex and face data within a 3D surface CAN be stored and
                >> >> reconstructed within the XML format...
                >> >>
                >> >> It says in the InkScape 'Advanced' tutorial that the real power of
                >> >> inkscape is that the XML structure of the SVG file can be freely
                >> edited
                >> >> and so forth... logic therefore dictates that the colour values
                >> within
                >> >> the 'image' are stored in a 'discreet' manner.. it should be possible
                >> to
                >> >> read these values and process or translate them to vertex locations
                >> in
                >> >> 3D space... connect them up and you've got a path shape... I think...
                >> >>
                >> >> I think it can go both ways.. and kerkythea definitely proves one
                >> aspect
                >> >> of that... as well as some work I've done with very well known high
                >> end
                >> >> relief generation software. The software in question can load a 3D
                >> mesh
                >> >> surface.. and then derive a shaded heightmap.. based on the existing
                >> 3D
                >> >> data... XML / SVG is the obvious interchange for this..
                >> >>
                >> >> Anyway.. that's the theory.. there are so many applications for this
                >> if
                >> >> it works...
                >> >>
                >> >> SVG import into gmax.... relief toolpathing.. mapped across
                >> non-uniform
                >> >> non-planar geometry.. ... reading in BOTH the path shape AND the
                >> height
                >> >> data for intaglio or V-Carving straight from the SVG... these popped
                >> out
                >> >> straight away... but there are many other twists you could put on
                >> >> this...
                >> >>
                >> >> If there's anyone who has a grip of SVG and XML formats and their
                >> >> interpretation / manipulation as data, I think it could potentially
                >> be
                >> >> of serious impact to the way toolpaths can be built 'automatically'..
                >> to
                >> >> be honest... I think a lot of people are toolpathing on the basis of
                >> SVG
                >> >> heightmap / XML manipulation already..
                >> >>
                >> >> TTFN
                >> >>
                >> >> Danny
                >> >>
                >> >
                >> >
                >> >
                >>
                >
                >
                >
              • yohoodi
                Hi Rab, Dave, All Dave: Many thanks for your time and highly useful info. This does help a lot. I m not big on programming or anything like that.. but I can
                Message 7 of 13 , Sep 17, 2011
                • 0 Attachment
                  Hi Rab, Dave, All

                  Dave: Many thanks for your time and highly useful info. This does help a lot. I'm not big on programming or anything like that.. but I can hand code html / css fairly well.. and I've been told that XML isn't that far away...

                  Rab: I'm glad you think this has some legs too.. and I've had a bit more of a think since we spoke... and I do believe it's there for the having.. already...

                  The GCodetoolks guys ARE getting 3D data out... I've seen it.. Their engraving process does it.... and ...they LOFT in inkscape... using inkshape vector paths .. they dont make a surface.. but they derive the interpolated shape / node locations.. and gcode it in 3D .. so it's there... just not aimed at getting an area path from a heightmap..

                  The shape thing is where were need to go I think... and shape interpolation... It's like this... for V-Carving.. this is the heightmap process in words.. it's really easy.

                  Make Text.. use a letter the letter M is a good one.. as its the basis of the em unit.. and this matters a lot with text layout..

                  So make your M. Use inkscape offset shape functions to make a smaller version.. 'inset' or 'linked offset' are the chaps.. until it approaches the form of a centerline vector. This is your 'low' shape for V-Carving methods.

                  Colour the original M with a light shade.. representing the high part of the path... colour the offset 'centerline' version a dark colour.. representing the lowest part of your cut.

                  select both paths and apply the interpolate functions... the high path can be made to adopt the shape and colour of the low path.. in a user specified number of steps....

                  Read the node XY locations /colour values.. translate the colour values to a Z axis height.. scan across all paths, all nodes, start at the original 'M' and work towards the 'centerline'.. knock the figures out to gcode...

                  I think I know how this is applied to relief now... just had to think about it...

                  It's all about drawing a line through colours.... getting boundary shapes and colours / gradients.. and interpolating them towards or away from each other.... The intepolation value is the stepover amount... pass depth = maximum difference between start path and endpath value i.e the number of passes through the 'gradient, starting from the top value until you reach the bottom..

                  All the data is there by reading the path vertex locations.. and their discreet colour value.... you just have to have enough paths to make a gradient....

                  we've GOT to be able to make gmax read this.... It CAN write XML .. so it WILL read it... I will be looking into this further with Var... he doesn't know it yet but I think he already has what we need.. and it is opensource... and I'm going to run my relief toolpathing idea past him....

                  Might be some fun to come... and before I update the ebook.. would love to have this in place... wouldn't you :D

                  Danny
                • rainnea
                  Hi Danny, Could you upload an example svg file and I ll see how readable it is, do you know of a link for the file format documentation ? Rab
                  Message 8 of 13 , Sep 18, 2011
                  • 0 Attachment
                    Hi Danny,
                    Could you upload an example svg file and I'll see how readable it is, do you know of a link for the file format documentation ?
                    Rab

                    --- In CNC_Toolkit@yahoogroups.com, "yohoodi" <yohoodi@...> wrote:
                    >
                    >
                    >
                    > Hi Rab, Dave, All
                    >
                    > Dave: Many thanks for your time and highly useful info. This does help a lot. I'm not big on programming or anything like that.. but I can hand code html / css fairly well.. and I've been told that XML isn't that far away...
                    >
                    > Rab: I'm glad you think this has some legs too.. and I've had a bit more of a think since we spoke... and I do believe it's there for the having.. already...
                    >
                    > The GCodetoolks guys ARE getting 3D data out... I've seen it.. Their engraving process does it.... and ...they LOFT in inkscape... using inkshape vector paths .. they dont make a surface.. but they derive the interpolated shape / node locations.. and gcode it in 3D .. so it's there... just not aimed at getting an area path from a heightmap..
                    >
                    > The shape thing is where were need to go I think... and shape interpolation... It's like this... for V-Carving.. this is the heightmap process in words.. it's really easy.
                    >
                    > Make Text.. use a letter the letter M is a good one.. as its the basis of the em unit.. and this matters a lot with text layout..
                    >
                    > So make your M. Use inkscape offset shape functions to make a smaller version.. 'inset' or 'linked offset' are the chaps.. until it approaches the form of a centerline vector. This is your 'low' shape for V-Carving methods.
                    >
                    > Colour the original M with a light shade.. representing the high part of the path... colour the offset 'centerline' version a dark colour.. representing the lowest part of your cut.
                    >
                    > select both paths and apply the interpolate functions... the high path can be made to adopt the shape and colour of the low path.. in a user specified number of steps....
                    >
                    > Read the node XY locations /colour values.. translate the colour values to a Z axis height.. scan across all paths, all nodes, start at the original 'M' and work towards the 'centerline'.. knock the figures out to gcode...
                    >
                    > I think I know how this is applied to relief now... just had to think about it...
                    >
                    > It's all about drawing a line through colours.... getting boundary shapes and colours / gradients.. and interpolating them towards or away from each other.... The intepolation value is the stepover amount... pass depth = maximum difference between start path and endpath value i.e the number of passes through the 'gradient, starting from the top value until you reach the bottom..
                    >
                    > All the data is there by reading the path vertex locations.. and their discreet colour value.... you just have to have enough paths to make a gradient....
                    >
                    > we've GOT to be able to make gmax read this.... It CAN write XML .. so it WILL read it... I will be looking into this further with Var... he doesn't know it yet but I think he already has what we need.. and it is opensource... and I'm going to run my relief toolpathing idea past him....
                    >
                    > Might be some fun to come... and before I update the ebook.. would love to have this in place... wouldn't you :D
                    >
                    > Danny
                    >
                  • yohoodi
                    Hi Rab... All, just to say that this is on the way... It s the M example. I have the .SVG, exported.PNG and gmax scenefile.. to get the generated surface..
                    Message 9 of 13 , Sep 18, 2011
                    • 0 Attachment
                      Hi Rab... All,

                      just to say that this is on the way...

                      It's the 'M' example.

                      I have the .SVG, exported.PNG and gmax scenefile.. to get the generated surface.. and I'm just waiting for the kerkythea export plugin to complete... has been going a while.. but it's a faily dense object.. just a plane.. with subdivision and no modifiers... thought it best to keep the 'element' in any export to a minimum...

                      I'm running the kerkythea thing mainly to see the 'flavour' of XML that it puts out.. and that hopefully gmax would understand.

                      re the .SVG format.. I have mooched about a bit on this as time has allowed... the most informative thing was the SVG Wiki.. this gives a breakdown of the elements in the .SVG 'structure' and the 'names' and so forth that relate to them...

                      http://en.wikipedia.org/wiki/Scalable_Vector_Graphics

                      Some info below re: paths in inkscape.. i.e node properties and such. I did forget to mention in the 'M' thing... you have to check for the 'starting node' to get interpolation to work appropriately... it's VERY much like spline morphing in gmax... If the 'start nodes' aren't aligned then you get strange results.. or can do...

                      http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Extensions-ModifyPath.html


                      Tell you what I did think of re: the thing I mailed you about... the function I needed to get the 'Stock' spline... I think wrapper might do it.. if it creates an exact duplicate.. which I think it does.. and it could conform the spline created from the array to a 'stock' representation.. then that might be the missing piece.. I just haven't had time to try it manually... but I thought you would probably know straightaway..

                      Will upload the .XML 'package' as soon as the export completes.. most interested to see what you make of it...

                      Regards

                      Danny


                      --- In CNC_Toolkit@yahoogroups.com, "rainnea" <yahoo@...> wrote:
                      >
                      > Hi Danny,
                      > Could you upload an example svg file and I'll see how readable it is, do you know of a link for the file format documentation ?
                      > Rab
                      >
                      > --- In CNC_Toolkit@yahoogroups.com, "yohoodi" <yohoodi@> wrote:
                      > >
                      > >
                      > >
                      > > Hi Rab, Dave, All
                      > >
                      > > Dave: Many thanks for your time and highly useful info. This does help a lot. I'm not big on programming or anything like that.. but I can hand code html / css fairly well.. and I've been told that XML isn't that far away...
                      > >
                      > > Rab: I'm glad you think this has some legs too.. and I've had a bit more of a think since we spoke... and I do believe it's there for the having.. already...
                      > >
                      > > The GCodetoolks guys ARE getting 3D data out... I've seen it.. Their engraving process does it.... and ...they LOFT in inkscape... using inkshape vector paths .. they dont make a surface.. but they derive the interpolated shape / node locations.. and gcode it in 3D .. so it's there... just not aimed at getting an area path from a heightmap..
                      > >
                      > > The shape thing is where were need to go I think... and shape interpolation... It's like this... for V-Carving.. this is the heightmap process in words.. it's really easy.
                      > >
                      > > Make Text.. use a letter the letter M is a good one.. as its the basis of the em unit.. and this matters a lot with text layout..
                      > >
                      > > So make your M. Use inkscape offset shape functions to make a smaller version.. 'inset' or 'linked offset' are the chaps.. until it approaches the form of a centerline vector. This is your 'low' shape for V-Carving methods.
                      > >
                      > > Colour the original M with a light shade.. representing the high part of the path... colour the offset 'centerline' version a dark colour.. representing the lowest part of your cut.
                      > >
                      > > select both paths and apply the interpolate functions... the high path can be made to adopt the shape and colour of the low path.. in a user specified number of steps....
                      > >
                      > > Read the node XY locations /colour values.. translate the colour values to a Z axis height.. scan across all paths, all nodes, start at the original 'M' and work towards the 'centerline'.. knock the figures out to gcode...
                      > >
                      > > I think I know how this is applied to relief now... just had to think about it...
                      > >
                      > > It's all about drawing a line through colours.... getting boundary shapes and colours / gradients.. and interpolating them towards or away from each other.... The intepolation value is the stepover amount... pass depth = maximum difference between start path and endpath value i.e the number of passes through the 'gradient, starting from the top value until you reach the bottom..
                      > >
                      > > All the data is there by reading the path vertex locations.. and their discreet colour value.... you just have to have enough paths to make a gradient....
                      > >
                      > > we've GOT to be able to make gmax read this.... It CAN write XML .. so it WILL read it... I will be looking into this further with Var... he doesn't know it yet but I think he already has what we need.. and it is opensource... and I'm going to run my relief toolpathing idea past him....
                      > >
                      > > Might be some fun to come... and before I update the ebook.. would love to have this in place... wouldn't you :D
                      > >
                      > > Danny
                      > >
                      >
                    • yohoodi
                      Hi Rab.. All just to say that the SVG / XML files are up.. they re in my folder here.. and I ve cleaned the folder out.. so there s only that file there... The
                      Message 10 of 13 , Sep 19, 2011
                      • 0 Attachment
                        Hi Rab.. All

                        just to say that the SVG / XML files are up.. they're in my folder here.. and I've cleaned the folder out.. so there's only that file there...

                        The .SVG file has 2 layers in it.. so for inspection purposes you might want to make 2 files out of this...

                        I left the original shapes or paths as inkscape calls them on the first layer.. I thought it might make it easier to see the data relating to the main 'M' shape in isolation...

                        the filled centre shape is a 'linked offset' duplication.. I had to reset the 'Start node' ... you can identify the 'start node' in inkscape by clicking the path shape to select it (with the path tool)... then press the 'TAB' key on your keyboard.. the 'start node' will be selected.. repeat presses will cycle through the nodes.. if you lose track.. just deselect / reslect the path and hit tab again.

                        The second layer has the interpolated paths.. it's not a gradient.. just lots of paths.. 50 I think.. I don't think you would need to 'scan' all 50 to get a toolpath... you could start at the first.. then grab the next shape based on the setpover distance.. i.e. what path is X distance away from the first.. and then iterate until you hit the end...

                        The PNG is a bitmap version of the gradient for gmax displacement showing the form... I havent attempted to apply any smoothing.. I wanted you to be able to see the 'actual' displacement from the basic .PNG unmodified.. as this is what would be represented in paths extracted directly.. (again I think)

                        The XML export is of a sphere object.. my high density plane looked like it had made the gmk2.0 plugin hang.. It's a render plugin.. so there has to be a camera in the scene.. you can ignore this...

                        gmk2.0 is part of the kerkythea install as I remember... watching the export to the listener.. it looks like it grabs a point list of the object.. and then writes the points in XML form.. all the other content in the export relates to render settings.. (I think)

                        I hope some of this helps... and I'll be taking a look at it myself also... bit busy today.. but will slot it in at some point...

                        All the best

                        TTFN

                        Danny
                      • yohoodi
                        Hello Rab, .. all.. well there is some news on this.. and there isn t kind of thing... I ve bee running tests with the Inkscape gcodetools plugin... the
                        Message 11 of 13 , Sep 26, 2011
                        • 0 Attachment
                          Hello Rab, .. all..

                          well there is some news on this.. and there isn't kind of thing...

                          I've bee running tests with the Inkscape gcodetools plugin... the thinking being if they can do it so can we... based on their method.. but we have to know what the existing approach is..

                          they are using inkscape path ID to specify a shape to read.. and then they process it's node XY to gcode...

                          for the V-carving thing they are doing something interesting.. they extract Z height based on a defined tool shape + radius.. applying some kind of maths (beyond me) on it.. the formula is pretty much displayed in the 'engraving' panel when you specify a 'Cone' toolshape.. and the file that inkscape generates shows how the tool is 'moved' to generate sharp corners.. I think you could do the exact same thing in gmax.. just by repeating the maths..

                          I can send the completed workfile if this might be helpful.. and of course the corresponding gcode..

                          In respect of the heightmap thing.. I've tried to help Var and the gcodetools guys see that if they were just to add extraction of Z height based on node colour value to their process, then inkscape could become a vector-based 3D relief modeller / toolpather... in it's own right. And that it would also be helpful for us to be able to exploit the data in 4 and 5 axis work... they may become interested..

                          I'm going to stick at making sense of their code output in relation to the .SVG that made it... the code output is helpful.. because the code segments generated by each shape are commented.. with the path name they were derived from... so it should help find it in the XML...

                          also have been sent some useful links to XML translators and other stuff by people interested in this.. some of them have been quite useful.. especially the XML to text and html stuff... can pass these on if anyone wants them.

                          Will stick at it.... and will be adding the gcode tools V-carving thing to the ebook... it's pretty easy.. and for the likes of text you only need to extract a couple of shapes from the text, to turn into paths.. it helps with this.. and the rest is pretty much processing...

                          TTFN

                          Danny
                        • yohoodi
                          Forgot to mention something.... I ve been testing some software created by a cnc4free,org sponsor called Andrej... It s machine control software for USB
                          Message 12 of 13 , Sep 26, 2011
                          • 0 Attachment
                            Forgot to mention something....

                            I've been testing some software created by a cnc4free,org sponsor called Andrej... It's machine control software for USB hardware he sells... but.. it comes with some great added extras.. has no problems simulating toolkit code.

                            You don't need ANY hardware installed to run the software.. and it has the best backplotter i've used to date.. the backplotter is configurable.. for your nominated rotary axes... can autorun, scrollbar.. or step through nc programs with arrow keys.. can pan/tilt and zoom the view WITHOUT interruption of the backplot.. can adjust the running speed...and FAST too... can shell to edit code.. can cut, copy and paste code...

                            it also does image to gcode, dxf to gcode / gcode to dxf and loads of other import/export options.. It provides cut time estimation and stuff like cut extents and other useful info... this is all unrestricted, fully functional.. and FREE

                            you do need to do a little setup of the options to get it running just as you want it.. but this isn't difficult.. once you know where to look for settings etc.. and I put some suggestions up in the updates thread at cnc4free...

                            This has replaced NCplot in the cnc4free.org essentials... You really DO need to get this as a backplotter if nothing else...

                            TTFN.... Again

                            Danny
                          • yohoodi
                            Hello All.. another busy day today but...some futher info on this .... and maybe a way to get a bit further... I had a reply from Var.. the gcodetools guy...
                            Message 13 of 13 , Sep 27, 2011
                            • 0 Attachment
                              Hello All..

                              another busy day today but...some futher info on this .... and maybe a way to get a bit further...

                              I had a reply from Var.. the gcodetools guy... he doesn't seem too keen to explore this.. but... in his reply to me he said...

                              "There's a feature in Path to Gcode function that can take a color as a cutting depth. In fact you can define the depth as a math function from several arguments. So you can try to use it. But it's like a small feature and I do not think that it could be really useful."

                              I'm going to see if I can identify the 'colour-to-height' and maths functions he's referring to.. anything maths based could be useful anyway.. inside gmax.. and if theres an existing colour to height function for .SVG this seems to me to be the best place to start re: reading XML colour as height with gmax...

                              TTFN

                              Danny
                            Your message has been successfully submitted and would be delivered to recipients shortly.