Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Linetype scale trouble

Using Linetype Batting to indicate building insulation, I vary Linetype scale to adjust the width across the sqiggles, to suit the width (insulation thickness) to be filled. Thus for 200mm thick insulation, I set Linetype scale to 0.1; for 50mm thick I set it to 0.25. This works fine in Modelspace, and up to now also comes out the correct width (insulation thickness) in Paperspace Viewports.

Now all of a sudden, insulation that is correctly showing as 200mm thick in Modelspace, is displaying wrongly as 100mm in a 1:50 scale Paperspace Viewport, correctly at 200mm in a 1:100 scale Viewport, and so on - in other words its display in Viewports stays same on-screen thickness, instead of getting thinner and thicker when the rest of the Viewport changes scale.

See attached - look at Paperspace tab 41, compare with Modelspace.

Some setting? They all looks the same as in other dwg files where it works fine.

dwg
dwg
319B.dwg
268K
319B.dwg 268.2K

Comments

  • edited March 6

    Tom, it's not only the batting that's different in paperspace than in modelspace. All the linetypes appear to have a 0.5 factor applied to their linetype scale in paperspace. A batting line is half as thick in paperspace, and the dashes in a dashed line are half as long in paperspace. That is, there are twice as many dashes in a given line entity.

    I don't understand everything that's going on in this file, but I found that the following procedure produced the result I think you're looking for:
    1. In modelspace, set MSLTSCALE = 0.
    2. Regen (but don't panic; they'll come back).
    3. Set LTSCALE = 100.
    4. In each layout: set PSLTSCALE = 0 and then regen.

    I normally work with LTSCALE = 1. But to do that you'd have to change the Linetype scale property of all your dashed lines, multiplying each one by 100. For example, 200mm wide batting would need a Linetype scale property of 10.

    I don't understand that, by the way, that 10 works for the batting, and that's what makes me say I don't know everything that's going on in this file. In any of my files, if I wanted batting 200 units wide, I would give it a Linetype scale property of 200.

    But I also don't understand why using LTSCALE rather than CANNOSCALE as the thing that multiplies all Linetype scales by 100 fixed the Pspace/Mspace discrepancy. All that annotative stuff is a mystery to me.

    I always keep MSLTSCALE off in each file, and PSLTSCALE off in each layout. I set those variables in my template file. And I never use anything that has "anno" in its name.

    dwg
    dwg
    319B edited.dwg
    286K
  • Thank you Anthony - I feel I'm back on dry ground! Well, in the shallows, because I also can't get my head around thge interplay of these scales, let alone Annotative.

    Not sure about "A batting line is half as thick in paperspace, and the dashes in a dashed line are half as long in paperspace" - having set things up as you say, I don't see any 'half' effect in paperspace vs modelspace.

    And about "I don't understand that, by the way, that 10 works for the batting .... In any of my files, if I wanted batting 200 units wide, I would give it a Linetype scale property of 200." - I think of it as PSLT sets the half-amplitude i.e 'height' above midline, which makes sense to a programmer's mind.

    Thanks again.

  • edited March 20

    The half effect was what I saw in the file that you posted. I assumed you wanted to get rid of that, and have the drawing look the same in modelspace and paperspace.

    I don't know what psltscale is for. Default is ON, so there must be some purpose, but that's beyond my ken. The only thing I do in Bricscad is 2D drawing in modelspace, using paperspace to get the drawings on a virtual sheet of paper and to scale. In that world, life is much simpler if psltscale is off. I adjust linetype scaling so it looks right in modelspace, and it always looks the same in a viewport, as long as I don't complicate it with those "anno" things.

  • @Anthony Apostolaros said:
    The half effect was what I saw in the file as you posted it.

    I see - but you kindly solved that for me by the 1-4 steps you suggested.

  • Hello Tom,

    your drawing is working completely 'as designed', and also as expected by most users - linetypes should always come out exactly the same on printed paper, regardless of the scale the drawing uses.
    Your batting insulation is a rather special case, since its size is related to the model instead to the layout, as 'normal' linetypes are.
    I agree that the annotational scaling system that Autodesk devised is a nightmare for both users and programmers, but following Anthony's advice to disable all automatic linetype scaling does not look like a viable solution to me either - at least not if you frequently work in different scales.

    We discussed this before (here), and the solution I proposed then has evolved a bit in the meantime - it now lets you apply a real-world scale to any linetype, and there are additional commands to select entities that have such scaling applied. Try loading the attached partial menu, if you want to check this out (unzip RealWorldLinetypeScaling.zip to wherever you like, and load the .mnu or .cui via menuload). I also edited your drawing a bit, and added some comments that might make things a little clearer. The attached linetype definition file contains the batting linetype scaled to a height of 10mm, which should make scaling more intuitive.

    But bear in mind that this is largely untested code, so backup your data often if you use it.

    zip
    zip
    RealWorldLinetypeScaling.zip
    13K
    dwg
    dwg
    319B.dwg
    276K
  • edited March 21

    .... your drawing is working completely 'as designed', and also as expected by most users - linetypes should always come out exactly the same on printed paper, regardless of the scale the drawing uses.
    Your batting insulation is a rather special case, since its size is related to the model instead to the layout, as 'normal' linetypes are. .....

    Knut, I agree with you that most users don't work the way I do. When I get drawings from other people, they always have Psltscale on. And they always have either no dashes in modelspace, or poor dash spacing either in modelspace or in paperspace, or both.

    Perhaps some of those people don't want to see dashes in modelspace. But clearly some do, and I think the latter are just not aware that their dashes look different in paperspace than in modelspace. Tom, for example, didn't know that his linetypes all looked different in paperspace, until one of them was a batting line whose linetype scaling couldn't be ignored. And, despite our discussion of it, you apparently still don't know that the other linetypes in his file also look different in paperspace (as shown in the attached screenshots) -- unless you really do think that's "as designed."

    319B MS,PS screenshots.png
    822 x 713 - 13K
  • Hello Anthony,
    everything regarding units and scaling is indeed so profoundly messed up in .dwg that it hurts my brain. Decades ago, I wrote simple code for my needs, that automated things so far that I could mostly forget about these issues in my daily work. The advent of 'annotational' scaling made the situation much more complex, and I therefore ignored it for quite a while, but in the end I invested considerable effort to reach the same level of 'not having to think about it anymore' while taking advantage of its benefits - the result is the script that I have posted.

    I thought it might be of use for others, but I forgot about one thing: Scaling in .dwg does not only suffer from an incomplete units and an overly complex scaling system, but also from the lack of reasonable defaults. The linetype definitions (found in default.lin / iso.lin) should not need scaling when printed, but unfortunately, they do, even if you work at 1:1 scale. Look for example at the 'Dashed' linetype: Its dashes are defined as half an inch / 12.7mm long, which is about ten times the length that I usually want in print. This has to be kept unchanged for compatibility reasons, so the solution that I adopted was to create my own linetype definitions - see attached file.

    My script assumes that linetypes should print out exactly as they are defined, which is true for the ones I created, but wrong for the ones that ship with BricsCAD - so it will not solve the problem for other users, unless they adjust completely to my assumptions.

    But anyway, attached is a little demonstration of what the script actually does, taking Tom's drawing as an example.

  • Hello Anthony,
    everything regarding units and scaling is indeed so profoundly messed up in .dwg that it hurts my brain. Decades ago, I wrote simple code for my needs, that automated things so far that I could mostly forget about these issues in my daily work. The advent of 'annotational' scaling made the situation much more complex, and I therefore ignored it for quite a while, but in the end I invested considerable effort to reach the same level of 'not having to think about it anymore' while taking advantage of its benefits - the result is the script that I have posted.

    I thought it might be of use for others, but I forgot about one thing: Scaling in .dwg does not only suffer from an incomplete units and an overly complex scaling system, but also from the lack of reasonable defaults. The linetype definitions (found in default.lin / iso.lin) should not need scaling when printed, but unfortunately, they do, even if you work at 1:1 scale. Look for example at the 'Dashed' linetype: Its dashes are defined as half an inch / 12.7mm long, which is about ten times the length that I usually want in print. This has to be kept unchanged for compatibility reasons, so the solution that I adopted was to create my own linetype definitions - see attached file.

    My script assumes that linetypes should print out exactly as they are defined, which is true for the ones I created, but wrong for the ones that ship with BricsCAD - so it will not solve the problem for other users, unless they adjust completely to my assumptions.

    But anyway, attached is a little demonstration of what the script actually does, taking Tom's drawing as an example.

    zip
    zip
    example.lin.zip
    648B
    mp4
    mp4
    rwlts.mp4
    711K
  • @Knut Hohenberg said:
    Hello Anthony, ....

    Knut, it's great that you solved whatever problem you were having with linetype scale. Or think you solved, I should say, since I didn't really understand your description of the problem or of the solution, and since you still seem unaware of the linetype scale discrepancy in Tom's file. For all I know, you might have a similar discrepancy in your own drawing files without being aware of it. The important thing is that you feel you've solved it, and I'm happy for you.

    But I don't know why you're telling me about it. I don't have a problem with linetype scaling. I did have a problem back when the Psltscale variable was first introduced. I couldn't reliably get dashed lines to look the same in paperspace as in modelspace, no matter how I adjusted the various settings. It was frustrating, especially as all software other than Autocad had been switching over to WYSIWYG interface. But then I discovered that simply turning Psltscale off solved it. That's worked flawlessly ever since, in thousands of drawings at every standard scale and various custom scales.

    No doubt you're doing something more high-tech and so you need a more complex system. But for what I do, and for what I saw in Tom's file, the WYSIWYG method is adequate.

  • Anthony,
    how do you achieve having two differently scaled viewports with uniformly scaled linetypes on one layout without PSLTSCALE?
    I always thought this was impossible...

  • ... how do you achieve having two differently scaled viewports with uniformly scaled linetypes on one layout without PSLTSCALE? ...

    In the same way that two viewports at different scales appear to have the same text size or the same arrow size on dimensions and leaders. In modelspace, those things are actually different for the two drawings shown in those two viewports. They're pre-determined for the intended scale of each drawing so that they appear to be the same in paperspace. The linetype scale of some entities has to be adjusted from what's typical for a particular drawing scale -- things like batting, or very long or very short dashed lines. I adjust the latter by eye.

    I don't use any multipliers (Ltscale, Psltscale, Msltscale, anno-whatever), so text height, dimscale, and linetype scale are all determined solely by entity properties. I make a drawing look right in modelspace, while I'm drawing, and it always looks the same in the viewport. A line entity with 5 dashes in modelspace still has 5 dashes in the viewport.

  • Yes, but if your line shows in a plan viewport with a scale of 1:100 and a detail viewport with a scale of 1:10 on the same layout, the dashes will be ten times longer in detail than in plan, which is not always wanted.

  • edited March 24

    That's what I was thinking of when I said you're no doubt doing something more high-tech. Eventually everyone will work that way, not drawing but instead creating a 3D model complete with every board, bolt, and pipe, and having the necessary drawings generated from that. And then drawings being phased out entirely in favor of just giving the virtual model to the construction crew, to zoom in on whatever they're working on at the moment to see the detail.

    Twenty years ago, when I started modelling all my projects in Sketchup3D, I predicted that the transition would be complete within 20 years. It is for some people, but not for me. I'm still working exactly the same way I was back then. That includes plan details at twice the scale of the general plan that they share geometry with, but not ten times. And I handle it by dedicated layers for the two different scales, and Layerstates and VP Freeze.

  • Hello Anthony,
    I absolutely did not want to suggest that you should change your established workflow. I had a hard time deciding for myself if I should adjust mine to these new features, and if I had correctly anticipated the amount of work required to get to grips with it, I would probably have stuck to my old habits (which resembled your approach). But as to the screenshot that you posted (sorry that I leaped over it): It simply shows the difference between a scale of 1:100 (as set in modelspace) and a scale of 1:50 (as set in the paperspace viewport). The linetypes are obviously half the size in 1:50 compared to 1:100 (related to the model), but they will have exactly the same size in the printed output (regarding dash length, or batting thickness). This is what linteype scaling was made for (well before 'annotative' scaling was introduced), and this is what I referred to when I said everything in this drawing worked 'as designed'.

  • edited March 25

    Yes, I can see that if Tom had wanted to print that wall section at two different scales, Psltscale=On would automatically change the linetype scale in the two viewports so that the printed length of each dash would be the same at one scale as at the other. A given line that has 5 dashes in the smaller-scale version of the wall section would be twice as long and have 10 dashes in a version that's at twice that scale, so that each dash is the same length in the two print-outs.

    I've never heard of anyone printing the same wall section at two different scales, and I can't imagine ever doing it myself, but the hallmark of the Autocad system is to make it easy to do things I can't imagine doing and difficult to do the things I want to do. Most commands can eventually do what I want if I supply enough option letters, but without option letters they often do something whose usefulness I can't fathom. So I use custom versions of nearly every command. That's completely different in VectorWorks and Sketchup and PhotoShop, by the way. The default modes of their tools are the ones I normally want to use, and their commands tend to be exactly what I need.

    The only time I print the same geometry at two different scales is when I use a larger-scale excerpt of a plan as a plan detail, in order to fit more notes and dimensions in a particular area. Usually the only actual dashed lines involved are grid lines. There are batting lines of course, but I wouldn't want their linetype scale adjusted.* If I wanted, I could give the grid lines the same dash length in the plan detail as in the general plan, either by putting the grid lines on two different layers and using Layerstates/VP Freeze, or by giving them Bylayer linetype and using VP Linetype settings. But I usually don't do that. I like the way it looks when the grid lines in the detail have dashes that are twice as long. It makes it clear that the plan detail is just a blow-up of the general plan.

    *If I remember correctly, VectorWorks has two types of linetype and hatch pattern -- those whose scaling relates to paper, and those whose scaling relates to real-world geometry. In VectorWorks I never had to think about scale at all, or adjust any settings with cryptic names.

Sign In or Register to comment.
Origami
Origami is the Japanese word for paper folding. ORI means to fold and KAMI means paper and involves the creation of paper forms usually entirely by folding.

Powered by VanillaForums, Designed by Steam