| |
In lugnet.cad, Bernd Broich wrote:
> Niels Karsdorp <nkp.nkp@hetnet.nl> schrieb im Newsbeitrag
> news:HGBE24.1IJM@lugnet.com...
> > Sorry, i don't know who pneaster is, but he did put a hold
> > on some primitives for differences in values. • It's me...
> >
> > I would like to know how these values are to be calculated
> > (and who calculated the correct values, me or pneaster)
I have had a few emails with the Parts Tracker admin's lately to discuss the
creation of primitives. I was INCORRECTLY using the rounding method that rounded
only the final results. Like this; round( r* sin( Angle ), 4).
The agreed upon method is r* round( sin( Angle ),4).
I am still not fully sure about another final rounding.
in example; round( r* round( sin( Angle ), 4), 4)
This is the current method I am using.
> >
> > I calculated the first value with the formula:
> > 7 * SIN( PI / 8), where PI = 3.14159265358979
> > (Excel can't handle more digits for PI)
> > Which results into 2.67878402655563, rounded to 2,6788
> >
> > If I use Windows Calculator with
> > PI=3.1415926535897932384626433832795
> > the result is
> > 2.6787840265556284020992198882128
> > rounded as 2.6788
> >
> > How does pneaster get the result 2.6789 ????
Niels,
ok, your "8" comes from 180/22.5 = 8
(this is to get from degrees to radians)
Angle = 22.5 = 360/16 (This is 1/16 of a normal primitive segment)
and so... 7 * round( sin( PI / 180 * 22.5),4) = 2.6789
sin (PI/180*22.5)=0.382683432
round(0.382683432, 4)= 0.3827
7* 0.3827 = 2.6789
> I've the same problem on my parts.
> The parts is (maybe) checked by inlining the edge.dat and then
> multiplied this with the radius (for example in MLCAD).
Yes, This is the desired end result. For making resized primitives match up to
large sized primitives.
>
> This comes to the result of the review. The points of the edge
> with radius 1 is approximate by 4 digits, but this leads to an
> error when you multiply this with R to get a new circle with
> this radius.
I'm not following you here. Give me an example.
>
> So the question is how to calculate new (round) primitives?
>
> a) With the correct points new calculated as you write above?
> or b) With the R=1 points multiplied with the new Radius?
>
> CU Bernd
Here is a reason for doing this this way.
How many times have you actually calculated the true points and made a new
primitve Only to find out that when another rescaled primitive will not match up
and render correctly. This is the reason why the method I have shown above must
be used.
Anyone else care to comment too?
Paul Easter
http://www.geocities.com/pneaster/lcad_util.htm
|
|
| |
Paul Easter <pneaster@knoxy.nospm.net> schrieb im
Newsbeitrag news:HGBwv1.22HB@lugnet.com...
> > This comes to the result of the review. The points of
> > the edge with radius 1 is approximate by 4 digits, but
> > this leads to an error when you multiply this with R to
> > get a new circle with this radius.
>
> I'm not following you here. Give me an example.
For example sin(22.5°)= 0.3827 for R=1 (in edge.dat)
15*sin(22.5°)= 5.7403 for correct point
15* (0.3827) = 5.7405 for stretching the edge.dat
A difference of 0.0002 LDU.
> >
> > So the question is how to calculate new (round)
> > primitives?
> >
> > a) With the correct points new calculated as you
> > write above? or b) With the R=1 points multiplied with
> > the new Radius?
>
>
> Here is a reason for doing this this way.
> How many times have you actually calculated the true
> points and made a new primitve Only to find out that when
> another rescaled primitive will not match up and render
> correctly. This is the reason why the method I have shown
> above must be used.
OK, this is an acceptable and plausible reason. So thanks,
for the information. In future I'll made primitives with
the "stretching"-method.
CU Bernd
|
|
| |
In lugnet.cad, Paul Easter wrote:
> The agreed upon method is r* round( sin( Angle ),4).
>
> I am still not fully sure about another final rounding.
> in example; round( r* round( sin( Angle ), 4), 4)
> This is the current method I am using.
> Here is a reason for doing this this way.
> How many times have you actually calculated the true points and made a new
> primitve Only to find out that when another rescaled primitive will not match up
> and render correctly. This is the reason why the method I have shown above must
> be used.
Thanx for the explanation, it's clear to me now.
I'll update my primitive generator and reupload the
primitives I have put on the PT
Niels
|
|
| |
In lugnet.cad, Niels Karsdorp wrote:
> In lugnet.cad, Paul Easter wrote:
>
> > The agreed upon method is r* round( sin( Angle ),4).
> >
> > I am still not fully sure about another final rounding.
> > in example; round( r* round( sin( Angle ), 4), 4)
> > This is the current method I am using.
>
>
> > Here is a reason for doing this this way.
> > How many times have you actually calculated the true points and made a new
> > primitve Only to find out that when another rescaled primitive will not match up
> > and render correctly. This is the reason why the method I have shown above must
> > be used.
>
> Thanx for the explanation, it's clear to me now.
> I'll update my primitive generator and reupload the
> primitives I have put on the PT
>
> Niels
Sounds good. Make sure your generator is using spaces and not tabs. I have not
checked to see how the original Ldraw responds to tabs as number seperators.
Paul
|
|
| |
In lugnet.cad, Paul Easter wrote:
> In lugnet.cad, Niels Karsdorp wrote:
> > Thanx for the explanation, it's clear to me now.
> > I'll update my primitive generator and reupload the
> > primitives I have put on the PT
> >
> > Niels
> Sounds good. Make sure your generator is using spaces and not tabs. I have not
> checked to see how the original Ldraw responds to tabs as number seperators.
My generator (just an excel sheet with some visual basic code) uses spaces as
seperators. I hope it's not a problem that values as 1 are written as 1.0000
I also fixed the generation of type 5 lines. (It generated one too less for
partial cones, now the correct amount).
The generator can create any cone or ring between 1-16 and 4-4 (not high-res).
http://home.hetnet.nl/~niels-karsdorp/ldraw/utils.htm
Niels
|
|
| |
In lugnet.cad, Niels Karsdorp wrote:
<some portions snipped>
> My generator (just an excel sheet with some visual basic code) uses spaces as
> seperators.
Ok, Yes, I started out with a spreadsheet that made 1-4 segments.
> I hope it's not a problem that values as 1 are written as 1.0000
I have made it a habit of eliminating all the extra zeros out of part files that
I can. They do not do anything but take up space.
I believe the rounding function removes all trailing zeros.
Here is a routine written in VB for a spreadsheet that you can use if you want it. It's called rlz(....) It will remove leading zeros, even the ones after a minus sign.
Dim AA As Integer
Dim BB As Integer
Dim CC As Integer
Dim TextIn As String
' Remove Leading Zero's function
Public Function RLZ(InPutText As Variant) As String
TextIn = Trim(InPutText)
If Len(TextIn) > 0 Then
'TextIn = Trim(TextIn)
'If Len(TextIn) > 0 Then
If Left(TextIn, 1) <> "0" Then
AA = InStr(1, TextIn, " 0.")
Do While AA > 0
TextIn = Left(TextIn, AA - 1) & " ." & Right(TextIn,
Len(TextIn) - (AA + 2))
AA = InStr(1, TextIn, " 0.")
Loop
AA = InStr(1, TextIn, "-0.")
Do While AA > 0
TextIn = Left(TextIn, AA - 1) & "-." & Right(TextIn,
Len(TextIn) - (AA + 2))
AA = InStr(1, TextIn, "-0.")
Loop
End If
'End If
End If
RLZ = TextIn
End Function
Yeah, it could be cleaner, but it works.
>
> I also fixed the generation of type 5 lines. (It generated one too less for
> partial cones, now the correct amount).
That is a common item that is missed.
>
> The generator can create any cone or ring between 1-16 and 4-4 (not high-res). • I see. I made seperate sheets for hi-res as well.
>
> http://home.hetnet.nl/~niels-karsdorp/ldraw/utils.htm
>
> Niels
Hey, thanks for the link to your website. I have been there before. Downloaded
several of your items.
I really like the rings and cones program. We need to figure out how to get it
to determine torus files. I have a spread sheet that "kinda" tells you how to
pick one. Email me and I will send it to you. If enough people want to see it,
reply to this message and I will put it on my web site.
Paul
|
|
| |
In lugnet.cad, Paul Easter wrote:
> In lugnet.cad, Bernd Broich wrote:
> > Niels Karsdorp <nkp.nkp@hetnet.nl> schrieb im Newsbeitrag
> > news:HGBE24.1IJM@lugnet.com...
> > > Sorry, i don't know who pneaster is, but he did put a hold
> > > on some primitives for differences in values. It's me...
> > >
> > > I would like to know how these values are to be calculated
> > > (and who calculated the correct values, me or pneaster)
> I have had a few emails with the Parts Tracker admin's lately to discuss the
> creation of primitives. I was INCORRECTLY using the rounding method that rounded
> only the final results. Like this; round( r* sin( Angle ), 4).
>
> The agreed upon method is r* round( sin( Angle ),4).
I assume that this apply also to parts? Or not, because parts (partsize) won't
be multiplicated as is with primitives.
I created the 9V curve 2867.dat with the 'incorrectly' rounding method witch is
pending in the parts tracker for certification.
Now i changed my VBA calculation utility too, to the agreed method and should
now recalculate all my calculations for the 9v train track point :-( or can i
still go on with the 'incorrectly' method?
>
> I am still not fully sure about another final rounding.
> in example; round( r* round( sin( Angle ), 4), 4)
> This is the current method I am using.
<SNIP>
Anyone else care to comment too?
Regards,
Ludo
|
|
| |
In lugnet.cad, Paul Easter wrote:
> I have not
> checked to see how the original Ldraw responds to tabs as number seperators.
Just for the record, LDRAW.EXE and LEDIT.EXE both allow tabs as
separaters. But they also allow line breaks as number separaters. :O
Steve
|
|
| |
In lugnet.cad, ludo soete wrote:
> I assume that this apply also to parts? Or not, because parts (partsize) won't
> be multiplicated as is with primitives.
> I created the 9V curve 2867.dat with the 'incorrectly' rounding method witch is
> pending in the parts tracker for certification.
I think for parts, you can use either method -- because, as the part
author, you are responsible for making all the vertices match up.
The point with this discussion, is to support using primitives in parts
by creating the primitives in a way that will work cleanly with
'stretched' primitives.
How you get your vertices for polygons and lines in parts isn't as big
an issue.
> > I am still not fully sure about another final rounding.
> > in example; round( r* round( sin( Angle ), 4), 4)
> > This is the current method I am using.
>
>
> <SNIP>
>
> Anyone else care to comment too?
I'd go with the double-round method, but I'm not sure that it will ever
make a difference. That is, I think that:
round( r* round( sin( Angle ), 4), 4)
will always equal
r* round( sin( Angle ), 4)
Assuming r is an integer.
Steve
--
No FTX was harmed in the making of this message
|
|
|
