Pretty Poly Editor Documentation

I. PPE Manual - 1. What is PPE?

Key features are:

• You can use PPE as a Single view 3D modeller (eg K3D, MultiGen Creator) - or as a more traditional Top/Side/Front/3D view modeller (eg AC3D, 3Dstudio). In fact, you can have any combination of views.
• Open Source. This means anyone can get the source and change it to suit their needs.
• Portable. Runs under Linux and Win32. Ports to BeOS, MacOS, OS-X, IRIX, Solaris and BSD should be easy and forthcoming.
• At first targeted at creating content for real-time visualisation like games. Therefore polygonal objects are created. While you can generate 3D objects for raytracers etc from the start, they will not be optimal. This will probably change later.
• WYSIWYG by full support for 3D accelerators, although they are not required. Since 3D renderers may vary in their interpretation of the contents of various 3D data files, to get PERFECT WYSIWYG, you'd need to use the same renderer as PrettyPoly. Fortunately, PPE uses the PLIB renderer which is also designed to work well for games and other, similar 3D applications.
• You will be able to work at the lowest level, if needed. For example, a WYSIWYG input of texture coordinates is planned.
• Support all primitives and attributes of opengl.
• Use opengl for the views of the modeller.
• Besides geometric views there is a structure editor to edit the hierarchy of the model and a material editor to edit surface properties like shininess, texture, etc.
• The hierarchy is not only a tree-structure, but one sub-object may be used repeatedly, for example a car could have 4 references to one wheel-object.
• Polygonal primitives: Vertex, line, triangle, regular n-sided polygon, mesh, cube..
• Non-polygonal primitives (planned): Sphere, cylinder, 3D-text, torii, the teapot. Probably NURBS, metaballs ("blobs") and sds (subdivision surfaces).
• Non-polygonal primitives are only tessellated ("polygonized") when absolutely necessary.
• Geometric operations: Translate, rotate, scale, project, sweeps, solids-of-revolution.
• Enable the user to input Level-Of-Detail data.
• Enable the user to input arbitrary data, which is not used by the modeller or renderer. For example, you could input a friction, so that certain areas in a game are "slippery".
• Animations can be set up and controlled from within the modeller.
• Files shall be able to refer to other files. For example a forest scene may reference an "external" file holding a single tree. If the file with the tree is changed, the forest is automagically updated.
• The scripting language python was used from the start as a middle tier between the User Interface and the "core" (= engine). The implications for the user are:
• There is a powerful scripting-language to drive PPE.
• You can write plugins.
• You can create scripts by logging your actions, editing them in an ASCII-editor and then replaying them.
• PPE automatically executes '.ppe_rc' as a Python script during startup. Hence you can easily "personalize" PPE.
• It should be relatively easy to use other scripting-languages beside python.

Things we probably won't implement:

• Fractals, bezier patches, procedural textures, voxels.
• You won't be able to generate/edit textures, there are enough 2D-drawing and painting programs out there already.