Pretty Poly Editor Documentation

III. Discussion Topics - 1. Planned features

• simple texture positioning, either by predefined mapping-modes (cylindric, spherical, box etc) or through a uv-view or even both. Currently, the only way to position a texture is to project it from the current working plane.
• Input of all parameters from OpenGL.
• Input of all parameters from SSG, for example LOD-data. Exception: user-data.
• Exact numerical input of, for example, a translation vector.
• complete manual.
• Tutorial.
• Something to get a correctly flipped model (that is, frontface/backface has to be correct). Experience tells that this is/will be a problem.
• Easy installation, many times it is more trouble installing the requirements than the application itself.
• Menu-points "check everything" and "show problems". Internally, its one function with different parameters. These functions warn the user about inconsistencies (pointing to code errors) or a modelling style that is allowed, but not nice (for example more than two neighbourfaces for an edge). From my experience, this function is worth its weight in gold, especially when you start coding geometric "base" code and it alerts you early to mistakes. Therefore, I would hope its in the first version.
• Probably we should have some more geometric operations like scale, rotate, and maybe mirror.
• A modified flag so that PPE asks whether to save when the user wants to close a changed object. This might also be used for other things like only rendering the scene when it has changed.
• If we want the first version to be for fgfs, then we need:
  • A tracing view (thats easily derivable from texture input view or vice versa)
  • unslice or connect loops or however you want to call it. Does anyone know a free algorithm or at least implementation somewhere? Else we would have to use the one from mdi_edit.
  • perhaps an aircraft-design-function. Dent expect too much, its quite simple. But I cant describe it in one sentence and one would probably need a discussion (Maybe Steve could ask the artists what they need to model aircraft?).
• Undo (according to the old feature list this is a V1.0 thing :-))

• The "camera-movement" should use a timer so that it is independent of how fast the computer is.
• Full internal/technical docs for developers.
• A function that is called after a geometric operation on the vertices that changes the position of the selected vertices. This function subdivides polys that have become non-planar.
• MAD should be scriptable. Example: PovRay can create *beautiful* procedural textures (which OpenGL can't use for obvious reasons). So I'm writing a script that allows me to assign a procedural texture to my OpenGL model. As soon as I click on OK PovRay is started automagical and renders different views from the model, the script takes the resulting files and creates a new PPE texture from that and inserts it in the 'texture-directory' of the material editor and assigns that texture to the model. (Quite complex, isn't it? But it should be trivial to write the script as long as texture space isn't a problem...)
• Tools for archives for 3d-files and 2d-files (textures). Some features of these archives could be:
  • There should also be the ability to copy and rename materials - along with a kind of 'symbolic link' so that... manmade/construction/brick/brick_with_vines_growing_up_it ...can also appear under: natural/plants/climbing_plants/brick_with_vines_growing_up_it.
  • Comment-, Keyword- and see-also-fields in the files.
  • A search engine.
• rotational sweep.
• General sweep of poly-line along other poly-line. Simple extrusions can then be implemented as a special case.
• Files should refer to other files. (e.g. I have a scene with a dozen trees in it. I model a single tree - but to position the trees into the terrain, I have to physically copy them into the terrain file. If I then want to change the tree, I either have to edit twenty copies or delete them and reposition them all again.)
• As long as possible, immediate feedback to user input. (One of us wrote: "something I don´t like about Gimp the last time I used it: you define modifications and then you have to wait what they will really do... something like a preview or a first peek at a lower res would be great").
• complex texture positioning, both by predefined mapping-modes and through a uv-view.
• user-data for materials, for example friction, temperature etc.
• user-data for SSG.
• user data MAY be stored as name/value pairs.
• complete control when there are hierarchy-nodes with more than one parent.
• Have one click start an external renderer (for example, PovRay, bmrt or a renderman renderer), transfer the scene to it, set options and start the rendering. Obviously, Giram does something similar (I havent looked at it).
• Other versions, like Mac, BeOS, etc.
• Some scripts and plugins as examples for others and to test our system.

• automatic reduction of Polys.
• 3DText
• NURBS. Philippe Lavoie has a very nice NURBS library that we could use. It doesn't do polygonalization or trim curves, but it has all the pure NURBS features you would want.
• sds (subdivison surfaces). They are the new wave in curved surfaces. They support difficult topologies much easier than even trimmed nurbs. They provide significant control over level of detail. They aren't really very hard to implement. In fact, most of your operations are just changes to the polygonal control hull.
• The teapot.
• Blobs (also called metaballs).
• Bones, IK (inverse kinematic).
• Animation. Probably by converting each parameter of the scene (for example, each x,y or z-coordinate of a vertex) into a "channel" which may be animated and which may interact with other channels. It would also be nice to have the possibility to define bones etc. and assign control points (or vertices or whatever) to links and joints etc.
• Additional primitives like spheres and cylinders which will only be tessellated when needed. Convert to mesh functions for all non-mesh objects.
• boolean operations like add or subtract geometric objects. This is sometimes also called CSG.
• Maybe auxiliary lines.

• I want to get something going as fast as possible and consider at every step the primary need for this project not to fail as so many before it have. Keeping up the momentum is important.
• Having a good time and learning things as we go along.
• I'd like people to think of this like they think of GIMP.
• I'd hope to attract 3D modelling enthusiasts to this tool and hence to create a vast library of freeware 3D objects that games designers could pick up and use.

• Fractals.
• Height fields.
• bezier patches.
• procedural textures.