Click to See Complete Forum and Search --> : Help in graphics programming needed


eriveraa
June 25th, 2007, 05:34 PM
Hi:

I am Eduardo, writing from Peru (Lima) and the author of program Secciones ( http://sourceforge.net/projects/secciones/) developed with .NET 2 and CSharp and i realize that you have experience with graphics management, viewpoints, viewports, etc. and I was wondering if you can help me improve my little program Secciones.

If you have a look on my program, you will see that the graphics are poor and i need to improve them (now i am using ZedGraph). I would like to have a graphics interface like Autocad or any CAD Tools (maybe not so advanced), with the following features:

* Allow me to see the Polygons and 2d figures defined by (x,y) points in their real form (Scale on X = Scale on Y).
* Zooming functions (In / Out / Rectangular area)
* Panning
* Grids with points
* Able to have "sensible" areas, like the tag <MAP> of html.
* Obviously FREE or Open Source !!!

Is there any way to do this? Can you help on that, giving some directions or related information? Better ideas??

pd. Sorry for my bad english.

Thanks in advance.
Regards

Saludos,

Eduardo
eriveraa@gmail.com

JVene
June 28th, 2007, 12:22 PM
This is actually not that tough to do, though speed requirements come into play.

AutoCAD has their own graphics subsystem they call HEIDI, which, if memory serves, basically replaces GDI in that it draws the primitives, gives them control over bezier's and curves in ways GDI didn't serve, etc.

AutoCAD had to work well (that is draw fast) on machines as old as the P2, the original Pentium and (in the DOS AutoCAD days) the old 486, about the time that one of their primary customer bases (architects) began to depend on CAD industry wide.

In machines this side of a 1Ghz P3, and AGP or faster interfaces, the drawing speed may be less of an issue than it was then. Still, in a typical architectural drawing (for which AutoCAD is quite common), there can be tens or hundreds of thousands of line segments in the drawing database. Obviously less for someone designing houses than those doing shopping malls or high rise buildings.

Your volume and speed expectations may dictate what you would have to do to accomplish your goal, but if your volume is less ambitious than 10K line segments on the display, you may do well enough with GDI.

You may have some tell you to use the mapping modes, and depending on your requirements that may do. What I prefer, because it's simpler to make mouse/measurement/scale/display coordination work as expected (IMO), is to simply make a display pipeline that invokes a zoom and pan variable.

AutoCAD's line segments are stored as high precision values, not integers. I think they use their own numeric type now, not doubles (but perhaps it's just doubles). Your coordinates might be large integers, and this may have a minor impact on results, but....

Somewhere I have posts on a thread that discusses this - try a search.

Basically, zoom is a multiplication factor. Zoom at 1, you're seeing 1:1. Zoom at 0.5, everything is shown "half size" - that is, all coordinates are passed through a "x * zoom" calculation, and are made half their original size, the displayed that way. Adjust the zoom variable and repaint. You have zoom....

Pan is just a vector. Pan is a 2D point, probably initialized to 0,0. Pan set to 0,0 means the drawing isn't moved. Pan set to 10, 10 means that every X and Y is run through "display_x = X - pan.x; display_y = Y - pan.y", or something like that. Hardly anything to it.

It's your judgment as to the units for which the pan variable is expressed. That is, if the pan is in display units, it's applied after the zoom calculation, and that means that panning is simple to figure based on mouse motion (they'll be the same). However, you often want pan to be in 'world' units (the units of your drawing/graphics). This means that the pan vector is applied BEFORE you apply the zoom, and you must convert the mouse motion into a world coordinate by reversing zoom (if multiply X by zoom, then you divide mouseX by zoom to reverse it).

Really, that's the basics of all of it. The rest is just minor finesse, until you get into performance and drawing primitives outside the domain of GDI.