LDraw.org Discussion Forums

Full Version: Thinking about doing a LDCad 1.7 version
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
(2020-04-24, 0:16)N. W. Perry Wrote: [ -> ]Which, I assume, would mean storing that string in a meta tag, or maybe as shadow content?
No I meant like
0.637276437432e-22
but 3 digits is considered 'normal' behaviour.

(2020-04-24, 0:16)N. W. Perry Wrote: [ -> ]That's an option indeed. But since I use submodels for organizational reasons, I think for my purposes that's more important than this precision issue. I think as long as I place everything correctly before exiting the file, I'll know that the saved values are as clean and precise as they should be, which will be good enough for me. (I just have to avoid the urge to check the relative positions again after re-opening the file!)  Tongue
you could also try increasing the
modelFileDecCnt
setting in main.cfg
(2020-04-24, 2:33)Roland Melkert Wrote: [ -> ]No I meant like
0.637276437432e-22
but 3 digits is considered 'normal' behaviour.

you could also try increasing the
modelFileDecCnt
setting in main.cfg

Undecided…interesting. I think I'm at a good place for now, but will definitely keep this option in mind. Does the decimal count persist once it's saved in a file, or would LDCad overwrite the coded values if I opened and re-saved a file with different precision?
(2020-04-24, 17:04)N. W. Perry Wrote: [ -> ]I think I'm at a good place for now
Probably best you don't want to fall in the rabbit hole known as the wonderful world of floating point precision Smile


(2020-04-24, 17:04)N. W. Perry Wrote: [ -> ]Does the decimal count persist once it's saved in a file, or would LDCad overwrite the coded values if I opened and re-saved a file with different precision?

The option only affects writing of files, reading will always use up to 19 decimal points.

The 19 comes from the maximum power of 10 in a 64 bit integer which is used to store the number after the dot before it's converted to double.
(2020-04-24, 19:26)Roland Melkert Wrote: [ -> ]Probably best you don't want to fall in the rabbit hole known as the wonderful world of floating point precision Smile

Yeah…my fear is that I switch to 5 decimal places, and now I'm haunted by rounding errors that are .00001 instead of just .001!  Big Grin

Quote:The option only affects writing of files, reading will always use up to 19 decimal points.

The 19 comes from the maximum power of 10 in a 64 bit integer which is used to store the number after the dot before it's converted to double.

So, if I were to switch from say, 3 to 5 places, and I save a new file…then later I decide to go back to 3 places and re-save that file, it would round all the values down? (I suppose I could just try and see what happens.)
(2020-04-24, 23:29)N. W. Perry Wrote: [ -> ]Yeah…my fear is that I switch to 5 decimal places, and now I'm haunted by rounding errors that are .00001 instead of just .001!  Big Grin


So, if I were to switch from say, 3 to 5 places, and I save a new file…then later I decide to go back to 3 places and re-save that file, it would round all the values down? (I suppose I could just try and see what happens.)

Only lines that where mutated during the editing of the file as LDCad preservers all lines it didn't change.
Hmm…what about a basic right triangle calculator? This is by far the most common calculation I make, to find the rotation angle of one part against a stationary surface. I don't know if it makes sense to add as part of the Selection Info tool, or perhaps as a macro. (This would probably be a perfect starter project if I ever decide to try some scripting!)

It would work like this—first you select three points:
  • The point ( A ) on a rotated part/assembly that will collide with the stationary surface
  • The rotation center ( B )
  • A point ( C ) orthogonal to the rotation center along the stationary surface
[attachment=5183]

Point C gives us the X-value of point A after it's rotated; we need to find its Y-value (in this case). Because we know two sides of a right triangle, we can find the third side length, and move point C by that amount in the Y-direction.

[attachment=5184]

Now that A-B and B-C are the same length, we can get the rotation angle to translate A to C.

[attachment=5185]

Of course the second part of this already exists; it's just a matter of solving the right triangle to get the second coordinate for the rotated point.
You could, probably, do this now with a script. If I didn’t already have like 5 project plates spinning, I’d finally learn how to script in LDCad and eliminate the need for my spreadsheets.
(2020-05-05, 19:27)Orion Pobursky Wrote: [ -> ]You could, probably, do this now with a script. If I didn’t already have like 5 project plates spinning, I’d finally learn how to script in LDCad and eliminate the need for my spreadsheets.

Yep, I think so too. Like I said, the perfect starter project if I find myself with no other plates spinning.  Smile
(2020-05-05, 19:44)N. W. Perry Wrote: [ -> ]Yep, I think so too. Like I said, the perfect starter project if I find myself with no other plates spinning.  Smile
It's a fairly simple one if you assume it's on the abs yz plane

Code:
function onRun()

  local sel=ldc.selection()
  if sel:getRefCount()<3 then
    return
  end

  local a=sel:getRef(1):getPos()
  local b=sel:getRef(2):getPos()
  local c=sel:getRef(3):getPos()

  a:setX(0)
  b:setX(0)
  c:setX(0)
  c:setY(b:getY())

  local ab=a:getLength(b)
  local bc=b:getLength(c)

  local bb1=ldc.vector(1,0,0):getSignedAngle(a-b, c-b)
  local bb2=math.deg(math.acos(bc/ab))

  local angle=-(bb1-bb2)
  ldc.setClipboardText(angle)

  ldc.dialog.runMessage(angle)
end

function register()

  local macro=ldc.macro('My macro')
  macro:setEvent('run', 'onRun')
end

register()

Could use some more cleanups and dummy proof checks though

It gave me the idea to add access to the relative grid in 1.7, so thanks for that
I realized if you assume all selection points are on a plane, you can drop the setX/setY lines and calculate the plane normal instead of using a static x vector

Code:
function onRun()

  local sel=ldc.selection()
  if sel:getRefCount()<3 then
    return
  end

  local a=sel:getRef(1):getPos()
  local b=sel:getRef(2):getPos()
  local c=sel:getRef(3):getPos()

  local ba=a-b
  local bc=c-b

  local n=bc:getCross(ba)
  n:normalize()

  local bb1=n:getSignedAngle(ba, bc)
  local bb2=math.deg(math.acos(bc:getLength()/ba:getLength()))

  local angle=-(bb1-bb2)
  ldc.setClipboardText(angle)

  ldc.dialog.runMessage(angle)
end

neg y makes it somewhat confusing but i think this should work in any orientation, not tested though.
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15