sketchucation logo sketchucation
    • Login
    1. Home
    2. August
    3. Posts
    โ„น๏ธ Licensed Extensions | FredoBatch, ElevationProfile, FredoSketch, LayOps, MatSim and Pic2Shape will require license from Sept 1st More Info
    A
    Offline
    • Profile
    • Following 0
    • Followers 0
    • Topics 29
    • Posts 238
    • Groups 1

    Posts

    Recent Best Controversial
    • RE: [Plugin] Shape Bender Beta

      @judy nielsen said:

      ... Attached is a sample file.

      I have opened your file and at first I thought there is an extra edge at the top near edge of your rectangle group, outside the group. But it turns out that you have two identical groups on top of each other.

      Two components selected

      But that shouldn't matter. Either you have just one of those selected when you activate the tool or the tool should give you an error message.

      An error when two components are selected

      After activating the tool you get a cursor with a horizontal line and a prompt at the bottom of the window telling you to select the Guide Line. After you select the Guide Line, the cursor changes to have a bent line and the Start and End of the Guide Line are identified.

      The tool shows you the Start and End of the Guide Line

      Click the Target Curve and the tool computes for a little while and then shows you the mapping of it's proposed bend. Sometimes this is not right. The arrow keys let you change mapping modes.

      When you select the Target Curve, the tool (eventually) responds

      There are some important points to notice in this this mapping:

      • The number of segments that the Source Group is devided into is the number of segments of the Target Curve.
      • The distance between the Guide Line and the Source Group will be the same as the distance between the Target Curve and the Result Group.
      • The mapping from the Guide Line to the Source Group is done perpendicular to the Red axis.

      Press Enter to accept the Proposed Bend.

      When you accept the proposed result, it becomes part of your model

      You said you were trying to create multiple bends in tubing. (I presume the various Follow Me tools, the original SU version and the Ruby enhancements, are not working for you for some reason.) Here is what happens if the Guide Line is shorter than the Source Group:

      The Guide Lines can be shorter than the Source Group ...
      I think that's a very tubing-like bend.

      If the Guide Line is longer than the Source Group, you get this kind of thing:

      ... or the Guide Line can be longer.
      I have used this when I was wrapping text around a circle to allow a little space between words.

      This was all done in your model file. I didn't even remove the extra component.

      If this is not working for you, please let us know EXACTLY what is happening for you. Can you get the error message as in the second image above?

      I hope this helps,
      August

      posted in Plugins
      A
      August
    • RE: Red, Yellow or Blue?

      @olishea said:

      ... and i said you have to be kinky to vote labour, not an idiot!

      You're beginning to sound like an American Republican Spokesperson now. Your original statement is on the same page.

      (I have freinds who call themselves Republicans, so I have to make a careful distinction between those who hope the party can return to what it once was and those who are trying to lead it off the deep end.)

      posted in Corner Bar
      A
      August
    • RE: Need some font help

      @robmoors said:

      Okay once you know what it's called it's easy to fix.

      Hi Rob,

      Glad you found your answer. When I started reading the thread I was thinking "He needs to know that it's called a 'ligature'" and fortunately I kept reading and found out that you had found out.

      The reason it's in one font and not another is up to the font designers. If a designer takes the time and trouble to design a ligature, it will be there in the font, and if not, not. There are also fonts that have "swash" capitals in addition to normal capitals.

      The most commonly used ligatures are f-i, f-f, and f-f-i in Times and Times-like fonts. In the f-i and f-f ligature, the "ball" at the top of the 'f' merges with the dot on the 'i' and in the f-f forms the crossbars on the 'f's merge, so the f-f-i has two things going on.

      That Calibri c-k ligature is unusual and is more "swash" than most ligatures which are about readabily and compactness. In this case, the c-k does not improve readability nor does it take up less space, but it would go well with "swash" capitals. It certainly should not be there automatically in body type. Swash can be pretentious, but there are times when that is what you want.

      I hope this helps,
      August

      posted in Corner Bar
      A
      August
    • RE: I'm thinking Apple maybe like Murphy's dog!

      @mike lucey said:

      ... I think I would have to give the debate to Steve even if I do not totally agree with him.

      Thanks for the link to that fascinating discussion. As for who "won", it depends on which kind of "points" you are counting. Social Justice vs. Abstract Logic vs. Debating Style vs. ...

      I recently saw a televised debate between Michael Shermer, publisher of Skeptic Magazine, and Depak Chopra on the existence of God. I was very glad to see Chopra on the God side instead of a Bible Literalist. The debate took place at Cornell University and the audience was clearly sharply divided. Very interesting was the post-debate interviews with participants and audience. Pretty unanimously, both sides were very satisfied that they had won.

      posted in Corner Bar
      A
      August
    • RE: Red, Yellow or Blue?

      I just caught up on this whole thread and it's been an interesting discussion from the viewpoint of a liberal (small "l") Yank.

      First, it's been hard to keep track of the colo(u)rs. On this side of the pond, throughout the Bush years there were "Blue States" and "Red States" ever since the presidential election of 2000, when all the TV networks used the same colors: blue for Democrats, red for Republicans.

      That distinction of which states went which way, who was a Red State and who was a Blue State, was particularly important thanks to Bush/Cheney "Democratic Theory" as I heard it articulated by John Bolton (Bush's appointee to the U.N. who thought the U.N. should be abolished), "You are only responsible to the people who voted for you". When Bolton said that, even the interviewer dropped his jaw, but it was clear to me that was the way the Bush administration operated. That attitude made Which states were Red and which Blue an important distinction, so Blue for Conservative keeps glitching for me.

      Second, the party philosophies. Someone described the British Conservative Party as being like the American Republican Party with a bit of Socialism thrown in. That's been even harder to keep straight than the colors because to at least the vocal Republicans, "Socialism" is a an obsenity. One prominent Republican Congresswoman, Michelle Bachmann, even went so far as to say publicly about a year ago that there should be an investigation to determine who in Congress were anti-American Socialists. I saw the interview where she said it. I also saw her denial two days later that she ever said anything like that, and then saw her say something similar a couple of months later.

      So to me, describing a political philosophy as being like the American Republican Party with a bit of Socialism is as contradictory as describing a musical style as being like Bach harpsichord with a bit of heavy metal. It may be accurate, but it's hard to imagine without the experience.

      Just observations, with a bit of opinion, here in the Corner Bar.
      August

      posted in Corner Bar
      A
      August
    • RE: Better Way To Make A Ramp

      @unknownuser said:

      We go to the moon but we can't know why these tools are named "french curve"! ๐Ÿ’š
      That is strange bizarre ๐Ÿ˜ฎ

      The only Frenchman in the discussion is the one who has names like Parrot and Pistol for the different shapes. I think that answers the question. I suspect that in 19th Century architecture they were indispensable for designing French-styled embellishments.

      posted in SketchUp Discussions
      A
      August
    • RE: Better Way To Make A Ramp

      @unknownuser said:

      Or least the government faked it all on a sound stages --all with just slide rules, french curves and super-8 cameras. But they got it done! ๐Ÿ˜†

      Yep. It was all part of a centuries-old conspiracy to fool everyone into denying the evidence of their eyes and letting "authorities" convince them that the world is round.

      posted in SketchUp Discussions
      A
      August
    • Using view.line_width= ?

      I am trying to understand what view.line_width= does. The documentation is not much help. To me is says the method draws lines of the desired width, but does not tell how. The sample code is no help.


      %(#000000)[**View.line_width=**] [floatr:tdmbx52s]SketchUp 6.0+[/floatr:tdmbx52s]
      The line_width= method is used to set the line width to use for drawing. The value is a Double indicating the desired width in pixels.

      This method is usually invoked within the draw method of a tool.

      Arguments:
      width - The width in pixels.

      Returns:
      view - a View object

      Example:

      view.line_width = width


      What is not clear from the doc is what "use for drawing" means. I suspect it means the next time the view is refreshed, which could be at a mouse movement. But if it means when I am drawing, then it could apply to some lines and not others.

      Has anyone had a use for this method? What does it really do?

      Thanks,
      August

      posted in Plugins
      A
      August
    • RE: Better Way To Make A Ramp

      Pardon the bump on a digression that is over two weeks old, but I had to comment because I used to use those tools too. I have a set of ruling pens and compasses of different sizes and a small set of French curves.

      And I used to have a K&E log-log, duplex-vector slide rule. It had 20 scales, a magnifying slider, and a leather case with a belt-clip.

      @arjunmax09 said:

      ...why do we use french curves at all???
      Because we cannot do it freehand. Or we cannot afford someone with the skill to do it freehand.

      And because we did not have computers or paper-tape-driven plotters, or any of the other things that have been tried because French curves are so hard to use.

      If doing it the hard way is the only way and if it must be done, then you do it the hard way.

      The Apollo missions went to the Moon based on calculations done with slide-rules; they did not have calculators or computers. But they got it done.

      FWIW,
      August

      posted in SketchUp Discussions
      A
      August
    • RE: Camera Rays wanted

      @august said:

      Sorry for the sarcasm.

      I should have remembered a rule from one of my college professors, Gregory Bateson, "Never an untrue word spoken in jest." Can still allow sarcasm, just not hyperbole.

      posted in Plugins
      A
      August
    • RE: Camera Rays wanted

      @thomthom said:

      ... Now you can add your comments yourself to the API pages if you log in.

      Cool!

      I'll look for the link the next time I see something.

      @august said:

      ... (my hunch is most of it was generated by @Last and has never been reviewed or edited since) ...

      Sorry for the sarcasm.

      posted in Plugins
      A
      August
    • RE: [Plugin] Shape Bender Beta

      @judy nielsen said:

      [... I then selected the rectangle but can not go any further. ...

      Just to be redundant, just in case:

      Select the group containing the rectangle, then select the Shape Bender tool.

      Then select the Guide Line, then the Target Line.

      I hope this helps.

      posted in Plugins
      A
      August
    • RE: Camera Rays wanted

      @chris fullmer said:

      ... I think I might need to look that over a little closer. I think I am messing something up with the IP associated to that view. ...

      If you are, then I have to presume that it is simply exposing the bug.

      The fact that I can draw a normal rectangle after I have orbited to a new camera.eye position, but when I return to the previous camera.eye the bug returns, to my mind that cannot be your fault.

      At the very least, that is a serious side effect that is not documented. I have pored over the doc for InputPoint, camera, and view, and I have found lots of typos and incomplete examples (my hunch is most of it was generated by @Last and has never been reviewed or edited since) but I have not seen anything that implies a locked InputPoint or that such a lock or any other status is restored when the camera.eye returns to a previous position.

      Maybe somebody is trying some "optimization" to restore view parameters when using Previous View or Scenes and is accidentally restoring too much. That's a wild guess. I suppose that could be tested by seeing if there were some minimum number of other views to go to that would make the bug go away when you returned to the original view, maybe if you ensured that you didn't return using a Scene (which would be a logical state to restore to) but used manually saved and input camera parameters instead.

      That's too much work for me to chase a bug, unless I had a hope that the effort would result in the bug getting fixed, but right now I don't have a minimal code fragment that shows the bug, and I'm not going to try to find one. If you do, let me know and I might be inspired to put some energy into writing up a bug report to Google.

      @unknownuser said:

      (I have been excited about a few ruby projects lately, so I am spending some time on ruby again, it is fun!)

      Except when you spend hours and hours wrestling with a bug while presuming it's you not the implementation or the documentation.

      OTOH, when it works, it's very satisfying, and there's something about getting an aesthetic, visual result that touches something primal.

      Again, thanks for the help.
      August

      posted in Plugins
      A
      August
    • RE: Camera Rays wanted

      @chris fullmer said:

      August, are you saying the that the bug is still present in the most recent snippet I posted?

      Yes, the above image was generated using your newest snippet, unchanged.

      I load your snippet, saved as a separate .txt file, make a few clicks that generate the desired clines, and then when I select the rectangle tool, as described above, the first rectangle inputpoint seems locked to camera.eye and the second point will, in this drawing, only reference one of Sang's points.

      I can orbit, draw a normal rectangle, and when I return to the original view, using Previous View or my Scene, the first inputpoint is locked at camera.eye again and the second inputpoint will not reference anything except Sang.

      I am getting the lines I want, and I can work around that input point locking, but I do think this is a bug in SketchUp, probably in .add_cline, maybe in view.

      posted in Plugins
      A
      August
    • RE: Camera Rays wanted

      @august said:

      [... if you activate the Select tool, it will not select. If you activate the Line tool, it will not draw. ...

      This bug is still there. Just to make it stranger, it seems to go away if you orbit, but if you return to the exact viewpoint, using either Previous View or a Scene, it appears to be stuck again.

      For example, with the Rectangle Tool active, the first InputPoint appears to be stuck at the Camera Eye. The second InputPoint will not go just anywhere, it appears to have to inference an object, just like when drawing a CLine. If you orbit away with Rectangle active, you can see that the first point is already set. If you press Escape, you can draw a normal rectangle, but if you return to the exact Eye view, that point is pre-picked again.

      Similarly for the Line tool. The first point is already picked and the only allowable lines are the ones that terminate on a pre-existing point.

      Clearly a bug.


      CLine InputPoint Bug.PNG

      posted in Plugins
      A
      August
    • RE: Camera Rays wanted

      @chris fullmer said:

      ... But the part where you said that it still produces an infinite line instead of a ray, I think that is a known bug. I'll see if I can track down the info on that bug if you'd like.

      Thanks, but no need. It doesn't interfere with anything that I'm trying to do. I'm just curious.

      You have already been most helpful, and you've helped me get my feet wet in SketchUp Ruby again (after they'd dried out for nearly a year).

      And now that I've started wrestling with this, I've begun to appreciate your dislike/aversion for construction geometry. Modifying something that already exists is clearly much easier.

      Thanks again,
      August

      posted in Plugins
      A
      August
    • RE: Camera Rays wanted

      @chris fullmer said:

      ... I got tired of looking at it so I took a new approach. ...

      Thanks. I tried it; it works great. No bugs.

      However, like the earlier versions, it creates an infinite cline in both directions, not a true ray that starts at a point and goes infinitely in one direction. That's not a problem, just a curiosity. (If it's not "supposed" to be that way, it may be related to the bug -- just guessing.)

      Do you know why the cpoint at view.camera.eye is necessary? You don't appear to use the point. Is it a requirement for pickray to work? (Maybe the omission of a cpoint there is the source of the bug? More guessing.)

      Thanks again.

      posted in Plugins
      A
      August
    • RE: Camera Rays wanted

      @chris fullmer said:

      There is something wrong going on here and I'm not sure if its something in the script or an SU bug. ...

      Thanks for that confirmation.

      It's worse than you had so-far discovered.

      After the tool fails, if you activate the Select tool, it will not select. If you activate the Line tool, it will not draw. After a bunch of tool changes and attempts, I got function back, I presume because one tool or another did a better job of resetting things.

      It's a bug.

      I will try your new approach.

      I had tried my own "new approach" by taking linetool.rb and hacking out the two-point construction to get just one point. I also didn't try calculating a vector, I just drew the cline between view.camera.eye and @ip1 and gave it a name, newRay, then set newRay.end = nil.

      But the core construction method of my new version is still the same and it has the same problem as the old version. I'm convinced it's a bug.

      Thanks again,
      August

      posted in Plugins
      A
      August
    • RE: Camera Rays wanted

      This is driving me crazy and now I've spent nearly another full day on it. Arrgh!

      I can draw Camera Ray lines just fine. But not clines unless there is an object to reference.

      I can get one, single unreferenced cline. Once a cline fails to get an input point because of a lack of a reference object, I cannot get another valid @ip for a line, only for clines that have reference objects. Doesn't matter if I reload the file, I have to restart SU to clear this state.

      I thought I could draw the line first, and then use its endpoints to create the vector (that works) and the cline (that doesn't work).

      To demonstrate, I have two files. The only difference between them is that in the first one, some code is commented out: the single line of code that creates a cline from a point and a vector and some following messages to report on it.

      Both versions create a vector from the original line and that appears to work fine.

      Here's the version that creates plain old ordinary edge lines. I call it rayL.txt:

      
      class Clf_august_lines;
      
        def onMouseMove(flags, x, y, view);
          @ip = view.inputpoint(x,y);
          view.invalidate;
        end;
      
        def onLButtonUp(flags, x, y, view);
      
      line1 = Sketchup.active_model.active_entities\
      .add_line(view.camera.eye, @ip.position);
       if (line1)
         UI.messagebox "line1 SUCCESS\n
      view.camera.eye = " + view.camera.eye.to_s + "\n
      @ip.position = " + @ip.position.to_s else
       else
         UI.messagebox "line1 Failure\n
      view.camera.eye = " + view.camera.eye.to_s + "\n
      @ip.position = " + @ip.position.to_s
       end
      
      vector1 = line1.start.position\
      .vector_to(line1.end.position);
       if (vector1)
         UI.messagebox "vector 1 = " + vector1.to_s
       else
         UI.messagebox "vector1 Failure"
       end
      
      #cline1 = Sketchup.active_model.active_entities\
      #.add_cline(line1.start.position, vector1);
      # if (cline1)
      #   UI.messagebox "cline1 = " + cline1.to_s
      #   line1.erase!
      # else
      #   UI.messagebox "cline1 Failure"
      # end
      
        end;
      
        def draw(view);
          @ip.draw view;
        end;
      
      end;
      
      Sketchup.active_model.select_tool\
      (Clf_august_lines.new)
      
      

      And here's the version that creates a line, then uses that line's endpoints to create a vector, which works in both versions, and then creates a cline from one endpoint of the line and the vector. It is this cline which initiates the problem.

      I call this one rayLC.txt because it attempts to create a line and then a cline:

      
      class Clf_august_lines;
      
        def onMouseMove(flags, x, y, view);
          @ip = view.inputpoint(x,y);
          view.invalidate;
        end;
      
        def onLButtonUp(flags, x, y, view);
      
      line1 = Sketchup.active_model.active_entities\
      .add_line(view.camera.eye, @ip.position);
       if (line1)
         UI.messagebox "line1 SUCCESS\n
      view.camera.eye = " + view.camera.eye.to_s + "\n
      @ip.position = " + @ip.position.to_s
       else
         UI.messagebox "line1 Failure!\n
      view.camera.eye = " + view.camera.eye.to_s + "\n
      @ip.position = " + @ip.position.to_s
       end
      
      vector1 = line1.start.position\
      .vector_to(line1.end.position);
       if (vector1)
         UI.messagebox "vector 1 = " + vector1.to_s
       else
         UI.messagebox "vector1 Failure"
       end
      
      cline1 = Sketchup.active_model.active_entities\
      .add_cline(line1.start.position, vector1);
       if (cline1)
         UI.messagebox "cline1 = " + cline1.to_s
      #   line1.erase!
       else
         UI.messagebox "cline1 Failure"
       end
      
        end;
      
        def draw(view);
          @ip.draw view;
        end;
      
      end;
      
      Sketchup.active_model.select_tool\
      (Clf_august_lines.new)
      
      

      If I open a new SU drawing and load 'rayL.txt', it will draw lines whereever I click. But unless there is an object for them to reference, they stop at the bounding planes of the near quadrant.

      If I then either load 'rayLC.txt' or open a new SU file and load it, I can draw clines that reference existing objects, e.g., Sang, and there is no problem.

      But when I attempt to draw a cline that does not reference an existing object, I can create just that one, single cline and then all subsequent attmpts to create clines will fail because @ip.position is stuck at the camera.eye position or line1.start.position.

      Even if I load rayL.txt again to create just lines, they fail, referencing Sang, the origin, or whatever. After one cline, @ip.position is stuck on camera.eye.

      I have tried TIG's suggestion of inserting @ip = nil but everywhere I have tried it produces error messages.

      This doesn't seem like it should be this hard.

      I have been poring over the SketchUp Ruby doc about view and inputpoint etc. and unfortunatley it all seems written for those who already get it. It also says things like the inputpoint should "normally" be obtained using [ruby:11qtfq9b]pick[/ruby:11qtfq9b], but I've followed those examples and not even gotten a working start. At least this one based on Chris Fullmer's version works sometimes.

      It appears to be one of three things:

      • It really is this hard.
      • I'm overlooking something very basic.
      • There is a bug in creating clines from a point and a vector.

      Can someone help me figure out which it is, and/or possibly suggest a workaround?

      Thanks,
      August

      posted in Plugins
      A
      August
    • RE: Camera Rays wanted

      @august said:

      ...All my links to Ruby reference sources are stuck on my dead computer and I had not begun to use them enough to have them in my head. Can someone point me to where @ip is well described?

      Thanks TIG,

      There are definitely more examples of @ip and @xxxx in the Google-supplied examples. But they didn't help. Your previous suggestion about setting @ip=nil has not helped (so far), at least with the things that I've been wrestling with, and I think I may have a clue why.

      Major Ruby Thinking Glitch

      I think I've found a major conceptual glitch in my understanding SketchUp Ruby "under the hood" -- and maybe this will help others, at least newbies, too. The following outlines my Ruby learning process to get there. Later I'll try to post full examples for testing to demonstrate what I think is really going on and why the results have seemed to make no sense and the suggested fixes have not worked.

      I finally figured out that I was asking the wrong question. I don't need to understand " @ip" as much as I first need to understand " @".

      After some hours of digging (both of my Ruby books are missing somewhere in "the disaster that once was my home office" but I finally found a good online reference), I have learned that @ip is an instance variable.

      I had originally been trying to follow Chris' usage:

      @ip = view.inputpoint(x,y);

      That line is used in the working snippet that Chris posted earlier in this thread that defines the " clf_auguat_lines" class.

      I've been assuming that @ip would hold an inputpoint.

      The SketchUp Ruby API doc says that view.inputpoint(x,y) returns nil, but clearly nil is not assigned to the @ip variable or the script would not do anything.

      The other OO languages I'm most familiar with, FrameMaker FrameScript and Acrobat JavaScript, allow a method to return an instance of a class and that can be assigned to a variable. Their doc would have said "Returns point object" instead of "Returns nil".

      Also, somewhere along the way I got the mistaken idea that Ruby had typeless variables. I guess I assumed that because you don't declare variables. But Ruby has implicit declarations based on the first letter of the variable name and value assigments happen very differently depending on the type of variable being assigned.

      I have been assuming that @ip is an inputpoint object created by:

      @ip = view.inputpoint(x,y);

      From that assumption, I've been further assuming that @ip.position would return a Point3D object.

      But it appears that it doesn't, at least not exactly. I had been reading the code as if it would create the Point3D object as soon as @ip.position was executed, but instead it appears to hold off evaluating it until the last possible moment. It appears to not create a Point3D at all "if it doesn't have to".

      The code:

      eye = view.camera.eye;
      Sketchup.active_model.active_entities.add_line(eye,@ip.position);
      

      will, embedded in Chris' snippet, draws a line wherever you click. But the code:

      eye = view.camera.eye;
      vector = eye.vector_to(@ip.position);
      Sketchup.active_model.active_entities.add_cline(eye,vector);
      

      will only draw a cline if you click on a place that is a valid reference for a cline. Anywhere else, you get an error about a zero-length vector.

      That has been totally confusing me until the idea of postponed evaluation occurred to me.

      What it says to me is that SketcnUp Ruby is not creating a vector object by using " eye" as one Point3D and @ip.position as a second Point3D. It does not create the second Point3D right away (I'm guessing).

      Instead, the vector is not actually evaluated until the add_cline is being executed, and because it's add_cline and not add_line, if the @ip.position is not valid for a cline, you get an error about an invalid vector.

      I'm stretching here, so I'm hoping someone who knows this much better than I do can follow my logic and tell me if I'm on track or missing the point.

      Am I making sense? Is there a better way to make sense out of this?

      Thanks,
      August

      posted in Plugins
      A
      August
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 11
    • 12
    • 5 / 12