sketchucation logo sketchucation
    • Login
    ℹ️ GoFundMe | Our friend Gus Robatto needs some help in a challenging time Learn More

    Loading a second set of points to draw lines.

    Scheduled Pinned Locked Moved Developers' Forum
    4 Posts 4 Posters 198 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • B Offline
      badbrush
      last edited by

      Hello i'm new to ruby and this is my first script. I have been working on something that uses two different vector datas to draw different types of cantenary curve based on dialogue inputs. Its similar to remus script in a way.

      I have two problems at the moment.

      The first is getting the type two cantenary curve data [inputs are oc at def_create_offset_cantenary]to load from a drop down box instead of the default simple cantenary].

      The second is that i'm having dificulty setting the curve once it is created to use the beginging of the line as the origin when snapping it to horizontal planes. Code line =234 onwards

      Thanks for your time.


      the ruby script so far.


      Image

      1 Reply Last reply Reply Quote 0
      • TIGT Offline
        TIG Moderator
        last edited by

        See my PM...

        TIG

        1 Reply Last reply Reply Quote 0
        • C Offline
          Cleverbeans
          last edited by

          Well I can see the problem with your translation starting at line 234.

          
          pt=Geom;;Vector3d.new()
          tr=Geom;;Transformation.translation(pt)
          
          

          Firstly, the vector stored in pt is the zero vector, and that means that the tr transformation is the identity transformation, so when this transformation is applied you should expect nothing to change. From the sounds of it you're drawing the object at the origin, and simply want to translate it to the desired point. To do this you'll need the desired point to properly initialize the vector. Once you've identified the point you'd like to move your object to you can get the appropriate vector by using ORIGIN.vector_to(point) which returns the vector. From there you can create the translation transformation as you've done above.

          It's also unclear to me why you're grouping and exploding the curves so much. this may be introducing some of the problems you're having with the transformation. From the looks of it you're trying to work around the fact that the Curve entity does not have a transform method. It would be better to simply defer the creation of the curve until you need it, and work on the points directly. The note suggests you're concerned with interaction between various curves, but if you've got the points defined uniquely in the "co" variable in the create_offset_cantenary I'm not sure why this is an issue. Here is how you can transform the points in "co" simply.

          
          co.map!{|pt| pt.transform!(tr)}
          
          

          Finally, and most importantly, you have declared a gratuitous number of global variables. As a rule you should not introduce global variables unless you have absolutely no reasonable alternative. If you have multiple methods manipulating the same global variables you open yourself up to side-effects in your code which are notoriously difficult to debug. It is much better to use parameters, return values and local variables to control the scope and flow of your code instead of global variables. This way if a bug is introduced in your code you can easily isolate it to a particular method which can save you days of frustration. Your code will also be much more modular, and by extension reusable. That way on future projects you don't have to reinvent the wheel. If you absolutely have to introduce a global you should try and encapsulate it within an object instead so that you can localize its scope as much as you possibly can. If I was asked to debug your code in it's current condition, I would find it faster to gut it and start from scratch keeping only the constants used for the co and cs variables, the string literals, and the comments. On the plus side, your code would make for a great spaghetti dinner. 😉

          1 Reply Last reply Reply Quote 0
          • Dan RathbunD Offline
            Dan Rathbun
            last edited by

            Some links for you:

            Ruby Newbie's Guide to Getting Started

            Ruby Resources

            [info] Using Ruby Modules

            and Jim Foltz has an InputBox class wrapper that makes it easier to use the UI.inputbox method. Not sure where it's kept, but he'll see this post and let ya know.

            I'm not here much anymore.

            1 Reply Last reply Reply Quote 0
            • 1 / 1
            • First post
              Last post
            Buy SketchPlus
            Buy SUbD
            Buy WrapR
            Buy eBook
            Buy Modelur
            Buy Vertex Tools
            Buy SketchCuisine
            Buy FormFonts

            Advertisement