Re: VB Circle Method Seems to be Seriously Flawed
From: Gerald Hernandez (Cablewizard_at_spam_remove@Yahoo.com)
Date: 01/30/05
- Next message: Gerald Hernandez: "Re: VB Circle Method Seems to be Seriously Flawed"
- Previous message: mike: "Re: VB6 and Shell"
- In reply to: Randy Gardner: "Re: VB Circle Method Seems to be Seriously Flawed"
- Next in thread: Randy Gardner: "Re: VB Circle Method Seems to be Seriously Flawed"
- Reply: Randy Gardner: "Re: VB Circle Method Seems to be Seriously Flawed"
- Messages sorted by: [ date ] [ thread ]
Date: Sun, 30 Jan 2005 13:16:41 -0700
Couple questions:
When you say my code was off, did you have the line:
fullHeight = fullWidth * outerAspect
commented out? This line will give you the results you got before to compare
with the
fullHeight = fullWidth * innerAspect
which should give you correct results.
On my computer, it doesn't appear to ever be off by more than 1 pixel.
Your comments do help clarify. Let me add some further notes:
There is no problem with the circle command, it is working as designed, and
it is not the source of the display issue.
The Single vs Double debate is a little superflous in the context. If you
are doing the math yourself, then use Doubles of course. (I don't know how
complex your program is, maybe dealing with tensors, radial vectors, etc.
Maybe not.) In the end when you go to graphically represent the results,
whether Double or Singles, they will be cast to Integers. While the picture
box emulates a floating point coordinate system, in the end it comes down to
Integer Pixels. The best display accuracy you can hope for is +- 1 Pixel.
Like I said earlier, professional CADD programs do many things to ensure a
good visual experience, some simple, some insanely complex. But even the
best CADD programs can have visual discepancies at the higher zoom factors.
Gerald
"Randy Gardner" <RandyGardner@discussions.microsoft.com> wrote in message
news:C0EE3536-587E-40CF-8C8E-7DFBAA9CED56@microsoft.com...
> Gerald:
>
> "Almost" perfect is my result too, but, PERFECT is what I need for visual
> feed back
> and drag editing for the following reason.
>
> I'm testing Dave Youngbloods code now, but, as I recall yours was only off
> when the center was on the -X axis at R! = 50.
>
> I plan to derive the cam data that the program uses from the dragging of
> points
> which are placed in tables that the program uses to model..
> The user can do text based editing in the tables which is better for very
> small changes once you're close to the final design. Mending the tables
to
> correct
> drag errors is not apealing.
>
> There is only one layer in the graphics display. The cams do interact in
> modeling and all are displayed at the same time in the picture box at the
> same resolution.
>
> Does that clarify?
>
> Thanks,
>
> Randy
>
>
> "Gerald Hernandez" wrote:
>
> > Randy,
> >
> > I'm still curious about the issue you have been having.
> > On my machine, the changes I made gave me almost perfect results no
matter
> > what size, aspect ratio, or magnification I tried.
> > Your original concept was sound, you just needed some tweaking.
> > Yes, making a square picture box should solve the problem, because
aspect
> > ratio would be a moot point. However, keep in mind the same issue might
> > apply if you do try to apply an aspect adjustment, still due to the
> > difference between inside and outside dimensions.
> >
> > For your cam design, do you have underlying objects to deal with the
> > geometry? Or are you basing the design on the visual representation. As
you
> > probably know, the underlying objects can be very accurate, and should
use
> > Doubles, and perform all the necessary math themselvs. The visual
> > representation is problematic. I have a Geometry Objects framework I use
for
> > various forms of analysis and CADD interop. But I haven't gotten around
to
> > the visual presentation. I usually just feed the output to Microstation,
> > sometimes AutoCad or other platforms for display. If you keep this
thread
> > alive, I'll give it a little more thought and see if any ideas come up.
> >
> > But once again, I'm not sure why your original concept isn't working. It
> > seems to be working fine for me.
> >
> > Gerald
> >
> >
> > "Randy Gardner" <RandyGardner@discussions.microsoft.com> wrote in
message
> > news:CA2E9DBE-432A-4983-AB12-3FEBC8D3A265@microsoft.com...
> > > Gerald:
> > >
> > > Thank for your suggestions.
> > >
> > > Your code is clearly easier to read and you have expanded my
> > understanding.
> > >
> > > I am in no way a veteran programmer and I have a lot learn.
> > >
> > > I would like to thank you and everyone who contributed!!!!!!!!!
> > >
> > > I tried your code and it performed very similar to mine.
> > > I think the best solution is the finding of Randy B's and that is to
make
> > it
> > > square.
> > > I'm going to test that method.
> > >
> > > As I mentioned I wrote "draw modeling software " for a coumpound bow
> > > originally
> > > in DOS, VB1. I wrote it as a tool for myself to do bow research since
I
> > did
> > > not have the facility, machine tools, to do the trial an error design
> > method
> > > that the industry uses.
> > >
> > > I now have interest from one company to buy the software if I can make
it
> > > more
> > > user friendly and current with technology. Besides moving the
appliction
> > to
> > > VB6
> > > I need CAD style editing of the cam design. That is where I am at
today.
> > >
> > > My DOS program was strickly text based editing. In addtion to that I
need
> > > drag
> > > and drop editing. Since the cams design are a series of contiguous
arcs
> > the
> > > user
> > > needs to be able to modify starts, ends and radius to modify the
design.
> > >
> > > I discovered this problem with the circle method when I was modifing
the
> > > radius.
> > > Changing the radius requires a calculations for a new center X,Y.
When I
> > > calculated the new center and redraw the arc it did not connect with
the
> > > adjacent arcs when the radius was long, the arc was approaching a
line.
> > That
> > > evolved in to the testing of the circle method when I could not find a
> > > problem with my new
> > > center code! Well that is where I'm at today.
> > >
> > > I think the circle method should work regardless of the shape of the
> > picture
> > > box and I believe there is enough evidence to report the problem to
> > Microsoft
> > > and hopefully get a fix. We will see!
> > >
> > > I may check to see how C's circle method works!
> > >
> > > Always open to suggestions! (randygardner@chartermi.net)
> > >
> > > Thanks again.
> > >
> > > Randy G.
> > >
> > >
> > >
> > > "Gerald Hernandez" wrote:
> > >
> > > > > </SNIP>
> > > > > There are a number of things you could do to deal with these
issues.
> > But
> > > > > there is no 1 "right" way. I don't know what your requirements are
and
> > > > > therefore cannot offer any suggestions. But hopefully I helped
more
> > > > clearly
> > > > > define the problem.
> > > > > <SNIP/>
> > > >
> > > > Ok, I couldn't really leave it there.
> > > > To prove my point, I made a couple minor changes to your Form Load
code.
> > > > Added some variables so you can step through and compare, plus makes
it
> > more
> > > > readable IMHO.
> > > > The primary difference is that I get the inner dimensions of the
picture
> > box
> > > > instead of the outer dimensions.
> > > > Then base the calculations on that ratio. Give this a try and let us
> > know
> > > > your results :-)
> > > >
> > > > Private Sub Form_Load()
> > > > '
> > > > Dim innerHeight As Single
> > > > Dim innerWidth As Single
> > > > Dim innerAspect As Single
> > > > Dim outerAspect As Single
> > > >
> > > > Dim fullWidth As Single
> > > > Dim fullHeight As Single
> > > >
> > > > Form1.WindowState = 2
> > > > Picture1.BackColor = vbWhite
> > > > Picture1.AutoRedraw = vbTrue
> > > >
> > > > With Picture1
> > > > innerHeight = .ScaleY(.ScaleHeight, .ScaleMode, vbHimetric)
> > > > innerWidth = .ScaleX(.ScaleWidth, .ScaleMode, vbHimetric)
> > > > innerAspect = innerHeight / innerWidth
> > > > '^ compare values v
> > > > outerAspect = .Height / .Width 'Outside dims, the way it was
> > > > End With
> > > >
> > > > fullWidth = 5! 'Whatever you like
> > > > fullHeight = fullWidth * innerAspect
> > > > 'fullHeight = fullWidth * outerAspect 'The way it was
> > > >
> > > > ' Set Coordinate (0,0) in the center of the picture box.
> > > > '
> > > > Picture1.Scale (-fullWidth / 2, fullHeight / 2)- _
> > > > (fullWidth / 2, -fullHeight / 2)
> > > > '
> > > > ' Draw Axis at (o,o)
> > > > '
> > > > Picture1.Line (-1, 0)-(1, 0), vbBlack
> > > > Picture1.Line (0, 1)-(0, -1), vbBlack
> > > > '
> > > > End Sub
> > > >
> > > >
> > > >
> > > >
> >
> >
> >
- Next message: Gerald Hernandez: "Re: VB Circle Method Seems to be Seriously Flawed"
- Previous message: mike: "Re: VB6 and Shell"
- In reply to: Randy Gardner: "Re: VB Circle Method Seems to be Seriously Flawed"
- Next in thread: Randy Gardner: "Re: VB Circle Method Seems to be Seriously Flawed"
- Reply: Randy Gardner: "Re: VB Circle Method Seems to be Seriously Flawed"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|