Free polygon software for linux

Wx::Polygon can draw and manipulate polygons for wxPerl.

ABSTRACT

This module provides functions for manipulating polygons in wxPerl.

new( POLYGON = (Wx::Point,...) | ELLIPSE => (x_offset,y_offset,width,heigth) ) --> Wx::Polygon>

Instantiates a new Wx::Polygon with an array of Wx::Points for a given POLYGON or an ellipse with given parameters.
add_point(x,y,recalc=1) --> void

Adds a point to the polygon. If scale and rotation have been used, rescales and rerotates the polygon after adding the point. If recalc is set to 0, this will not be done, which is better when a lot of points need added.

recalc() --> void

Rescales and rerotates the polygon. This method should be used when a lot of points need to be added. Recalculation can than be done after adding the points.

set_color(r,g,b) --> void

Sets the fill color to wxSOLID with the given r, g and b values.

mid() --> (midx:integer,midy:integer)

Calculates the middle of the polygon (not point z) and returns a list with x and y position.

in(x,y) --> boolean

Calculates if (x,y) falls within the edges of the polygon. Returns true if so. Uses algorithm of Randolph Franklin, http://astronomy.swin.edu.au/~pbourke/geometry/insidepoly.

draw( dc:Wx::DC ) --> void

Draws the polygon at given offsets and with given colour(s) to the current DC.

copy() --> Wx::Polygon

Returns a copy of the object.

scale(scale-factor) --> void

Scales the polygon with scale-factor.

rotate(degrees) --> void

Rotates the polygon by degrees degrees (0-360).

offset(x,y) --> void

Sets the offset for drawing. This can be used to transpose the polygon.

XPilotNG is the mother of all 2D team based space games.
XPilot NG is a multiplayer spacewar game based on the mother of all computer games: XPilot - one of the highest rated games on the linux game tome.
Xpilot is a 2D game which can be played in many modes, each man for himself, team games with carry the flag mode, a racing mode, or all out warfare with complex items such as nukes, ecm, heat seeking and smart missiles, armor, tractor beams, afterburners, warping and many more. Items are collected as powerups. Mouse or keyboard can be used to control the ship. most popular currently is team based games which involved alot of quick thinking and strategy.
XPilot NG improves XPilot in several areas. The most important improvement is the support for a new polygon based map format. The new map format allows the use of arbitrary polygons to define walls and other map constructs. Old block style maps are also supported: the server converts them to polygons automatically to take advantage of the improved wall collision detection code. Legacy XPilot clients are also supported even on new polygon maps. The server can approximate wall polygons using blocks although the approximation is not always very accurate (for obvious reasons).
XPilot NG improves the XPilot code base by removing lots of old hacks and generally cleaning up things to make further improvements easier. This clean up has made it possible for the XPilot NG development team to create a new SDL/OpenGL based client that shares much of the code and functionality of the original X client. The SDL/OpenGL client is quite usable and is tested to work on Linux, Windows and MacOS X platforms. Also, last but not least, it looks quite pretty.
Enhancements:
- SDL client: Fixed some memory leaks, e.g. one for HUD messages.
- SDL client: Texture bug fixes, should fix the bug in 4.7.1 where the ship is painted as a white box on some machines.
- Server: Put back the old behaviour that dropped mines are immune to gravity. Explanation is that they are "anchored" to the map the same way as the walls are.
- Server: New option ballCollisionDetaches (default false): Does a ball get freed by a collision with a player?
- Replays: A fix so that big old recordings dont slow down to a crawl.
- Replays: Possibility to jump forward in a recording by pressing number keys: the number pressed tells how many minutes to forward.
- Several other improvements

PloneWorldKit project is an out-of-the-box GIS for the Web.
PloneWorldKit is a mapping solution for ZOPE Plone.
It is built around the worldkit engine and makes annotating fairly easy.
worldKit is an easy to use and flexible mapping application for the Web (a lightweight GIS). Its a SWF-based app, configured by XML, and with data fed by RSS.
Main features:
- Ubiquitous use in the Flash Player and with RSS feeds.
- Highly configurable look and feel. Can use images for marking annotations.
- Integrates with weblogging tools, and any software producing RSS.
- Annotations updated in the background, live.
- Displays photos within the map.
- Zoom & Pan. Integrates with Zoomify for high resolution images.
- Accepts input for Collaborative Cartography.
- Annotations are categorizable. Javascript interface for GIS layer functionality.
- Connects annotations for GPS track routes.
- ntegration of worldKit as a content type (Map)
- Complete TTW (Through The Web) configuration of worldKit attributes
- ZCatalog based XML and RSS generation (config.xml, rss.xml)
- 3 annotation content types (Node, Line, Polygon)
- Base classes for content type developers
- Categorization of annotations TTW
- Time Navigation out of the box using "modified" index

The Persistence of Vision Ray-Tracer creates three-dimensional, photo-realistic images using a rendering technique called ray-tracing. It reads in a text file containing information describing the objects and lighting in a scene and generates an image of that scene from the view point of a camera also described in the text file.
The Persistence of Vision Ray-Tracer(tm) was developed from DKBTrace 2.12 (written by David K. Buck and Aaron A. Collins) by a bunch of people (called the POV-Team?) in their spare time. The headquarters of the POV-Team is on the internet (see "Where to Find POV-Ray Files" for more details).
The POV-Ray package includes detailed instructions on using the ray-tracer and creating scenes. Many stunning scenes are included with POV-Ray so you can start creating images immediately when you get the package. These scenes can be modified so you do not have to start from scratch.
In addition to the pre-defined scenes, a large library of pre-defined shapes and materials is provided. You can include these shapes and materials in your own scenes by just including the library file name at the top of your scene file, and by using the shape or material name in your scene.
Ray-tracing is not a fast process by any means, but it produces very high quality images with realistic reflections, shading, perspective and other effects.
Ray-tracing is a rendering technique that calculates an image of a scene by simulating the way rays of light travel in the real world. However it does its job backwards. In the real world, rays of light are emitted from a light source and illuminate objects. The light reflects off of the objects or passes through transparent objects. This reflected light hits our eyes or perhaps a camera lens. Because the vast majority of rays never hit an observer, it would take forever to trace a scene.
Ray-tracing programs like POV-Ray start with their simulated camera and trace rays backwards out into the scene. The user specifies the location of the camera, light sources, and objects as well as the surface texture properties of objects, their interiors (if transparent) and any atmospheric media such as fog, haze, or fire.
For every pixel in the final image one or more viewing rays are shot from the camera, into the scene to see if it intersects with any of the objects in the scene. These "viewing rays" originate from the viewer, represented by the camera, and pass through the viewing window (representing the final image).
Every time an object is hit, the color of the surface at that point is calculated. For this purpose rays are sent backwards to each light source to determine the amount of light coming from the source. These "shadow rays" are tested to tell whether the surface point lies in shadow or not. If the surface is reflective or transparent new rays are set up and traced in order to determine the contribution of the reflected and refracted light to the final surface color.
Special features like inter-diffuse reflection (radiosity), atmospheric effects and area lights make it necessary to shoot a lot of additional rays into the scene for every pixel.
Main features:
- Easy to use scene description language.
- Large library of stunning example scene files.
- Standard include files that pre-define many shapes, colors and textures.
- Very high quality output image files (up to 48-bit color).
- 16 and 24 bit color display on many computer platforms using appropriate hardware.
- Create landscapes using smoothed height fields.
- Many camera types, including perspective, orthographic, fisheye, etc.
- Spotlights, cylindrical lights and area lights for sophisticated lighting.
- Photons for realistic, reflected and refracted, caustics. Photons also interact with media.
- Phong and specular highlighting for more realistic-looking surfaces.
- Inter-diffuse reflection (radiosity) for more realistic lighting.
- Atmospheric effects like atmosphere, ground-fog and rainbow.
- Particle media to model effects like clouds, dust, fire and steam.
- Several image file output formats including Targa, BMP (Windows only), PNG and PPM.
- Basic shape primitives such as ... spheres, boxes, quadrics, cylinders, cones, triangle and planes.
- Advanced shape primitives such as ... Tori (donuts), bezier patches, height fields (mountains), blobs, quartics, smooth triangles, text, superquadrics, surfaces of revolution, prisms, polygons, lathes, fractals, isosurfaces and the parametric object.
- Shapes can easily be combined to create new complex shapes using Constructive Solid Geometry (CSG). POV-Ray supports unions, merges, intersections and differences.
- Objects are assigned materials called textures (a texture describes the coloring and surface properties of a shape) and interior properties such as index of refraction and particle media (formerly known as "halos").
- Built-in color and normal patterns: Agate, Bozo, Bumps, Checker, Crackle, Dents, Granite, Gradient, Hexagon, Leopard, Mandel, Marble, Onion, Quilted, Ripples, Spotted, Spiral, Radial, Waves, Wood, Wrinkles and image file mapping. Or build your own pattern using functions.
- Users can create their own textures or use pre-defined textures such as ... Brass, Chrome, Copper, Gold, Silver, Stone, Wood.
- Combine textures using layering of semi-transparent textures or tiles of textures or material map files.
- Display preview of image while rendering (not available on all platforms).
- Halt and save a render part way through, and continue rendering the halted partial render later.

QwtPlot3D is a Qt/OpenGL-based C++ programming library, providing essentially a bunch of 3D-widgets for programmers.
Main features:
- Common code base for Qt3 and Qt4
- Specialized widgets for surfaces, graphs etc.
- Parametric Surfaces
- Lighting (experimental)
- User defined visual objects
- Scaling, rotating, shifting, zooming of data sets and mathematical functions ( see Data Input Topics )
- Interactive mouse and keyboard handling
- Resolution changing on the fly
- Reading from MESH data files :See the data directory and NativeReader documentation for this . You will find example datasets here
- Reading from FEM files
- Flat (2D) labeling
- Wireframe, filled polygons, hidden line
- Floor projections (Isolines, Data)
- Free configurable (labeling, numbering; linear, log or user-defined transformations) and autoscalable axes
- Free color model
- Flat/Gouraud shading
- Color legends
- Pixmap output (all Qt supported formats)
- Vector output (PostScript, EPS and PDF) via gl2ps

Wykobi project is an efficient, robust, and simple to use multi-platform 2D/3D computational geometry library.
Wykobi provides a concise, predictable, and deterministic interface for geometric primitives and complex geometric routines using and conforming to the ISO/IEC 14882:2003 C++ language specification.
The design and structure of Wykobi lends itself to easy and seamless integration into projects of any scale that require a robust yet efficient 2D/3D computational geometry back-end.
Enhancements:
- Various algorithms were added, including 2D only Convex Hull algorithms (Graham scan, Jarvis march, and Melkman), Minimum Bounding Ball algorithms (Naive method (2D), Randomized (2D), and Ritter (2D and 3D)), Sutherland Hodgman polygon clipper, isotropic point normalizations (2D and 3D), covariance matrix calculation for point clouds (2D and 3D), ordered polygon from complex self-intersecting polygons (2D). naive group based pairwise intersections, axis projection polygon descriptor, a duplicate removal algorithm, and matrix calculations (2x2, 3x3, and 4x4).

uml2svg is an XSLT-based tool for converting XMI-compliant UML Diagrams into SVG.
We started the developing uml2svg with six main goals in mind:
- Standard conformance
- Good Documentation
- Modularity
- Extensibility
- Comprehensible SVG
- Multiple diagrams per XMI-file
SVG is a standard language for describing two-dimensional vector graphics in XML. As the open SVG standard gains in popularity and gradually replaces proprietary formats for vectorial graphics, the support provided by the Web browsers is getting better.
Plugins to display SVG exist for most browsers and it is most likely that the next generation of Web browser will provide built-in support for SVG. When that happens there will be no better way to distribute vector graphics on the web. Furthermore, not only web browsers can process SVG in a meaningful way; in fact that is just the tip of the iceberg. SVG can be easily read in, processed, and then transformed into many other formats, being well suited for both text and graphic tools as well as for web agents and screen readers.
UML diagrams are composed of lines, polygons, ellipses and text labels, so they are inherently vectorial. However, the SVG is not very well suited for direct use by UML tools. While some of them can in fact export UML diagrams directly to SVG, they do that by discarding all the information about structure, and converting everything into a shape. Moreover, some tools use the screen-capture function provided by their environment (such as java2d) and then they apply a filter to generate SVG out of the "screenshot".
What comes out of that is a pile of meaningless information, which by accident happens to draw a gorgeous diagram. How will a screen reader interpret such a file? How will a web crawler be able to index it? How will a web agent process it in a meaningful way? A program needs the semantic information that the humans can extract just by looking at a picture. For a machine, an obfuscated SVG file is not easier to process than a PNG file or any other image.
Although for humans it is better to be able to scale the image, for a program this is irrelevant. Programs need a way to "understand" the semantics of the UML models to be able to process and interchange them in a meaningfull way. This was the main idea behind the XML Metadata Interchange (XMI), an OMG specification for model interchange. And probably the best use that XMI has found so far is the exchange of UML models between different modeling tools. And while the XMI provides a standard way for tools to represent models as XML documents, it is still limited to the model elements only.
With the introduction of the UML 2.0 Diagram Interchange Specification as part of the upcoming UML 2.0 standard, it will become possible for tools to exchange the models together with the layout of the diagrams. We think that, once this specification appears, XMI will be used averywhere. Not only will the tools be able to exchange diagrams, but could even represent them internaly as DOM trees. Have you ever considered drawing your UML diagrams online, using only a web browser? This could be done even now by using a custom SVG syntax for the DOM tree, but a solution based on XMI could do even better and be a standard at the same time.
Therefore, we believe that with the advent of UML 2.0 and the increase in the use of SVG, the need for transformations between XMI and SVG will be great. Nevertheless when the uml2svg project was started, there was hardly any good open-source solution to convert XMI diagams into SVG.
The UML 2.0 Diagram Interchange Adopted Specification in its current incipient form references a set of XSL transformations. Although the standard draft covers them to a large extent, the link is actually broken (you can try for yourself). It has been broken for more than a year and most likely it will stay like that forever.
The personal webpage of Professor Mario Jeckle provides an online transformation service capable of dynamically generating SVG from XMI-compliant XML files. The XSL files accomplishing the transformations are also available on that website. These transformations are monolithic and not well documented (the only documentation is in the code, and it is generally written in German). With the tragic accident that took the life of Professor Jeckle, the transformations have no longer been maintained.
Finally, the STZ-IDA research center in Karlsruhe had to convert UML diagrams to SVG, as part of one of their projects. The XSLT stylesheet they created for this purpose was named xmi2svg and is available under the terms of the MIT license. At the time we started work on uml2svg the only type of diagrams supported was class diagrams.
Recently the package reached version 0.2 and it supports more diagram types, without major changes in the code (the opposite of what we were expecting). Andreas Junghans, the author of xmi2svg, provided us with a lot of insightful hints which helped us eliminate many glitches in uml2svg. It looks that the development of uml2svg and xmi2svg will continue in parallel, at least for a while. The good thing about this is that the two (quite different) implementations prove each others validity and the features tend to propagate freely from one side to the other. However, this comes with the prize of having to maintain two different code-trees and possibly confusing some users.
We did not like the two existing solutions because they were:
incomplete - just prototypes, not well suited for production environment
monolithic - hard to maintain and extend
not documented - hard to understand
At first sight, we thought we could find a way to improve one of the existing solutions and just add the features we needed. However, we slowly came to the conclusion that it would be better if we started anew. There are things one can fix in a project, but that does not include what we thought is was bad design. The fact that the two implementations presented above are open source helped us get quickly on the way with our own project.
Enhancements:
- Two annoying bugs were fixed.
- The site and documentation were updated.