Primitives to support:
We intend to release all code as freeware, probably under something like the BSD License. Our development target is C code portable to Linux and varities of UNIX, using X for graphics.
Comments in files are good. Do we want to support:
[defaults. the individual fields can be absolute or relative to this] The defaults are for material settings.
Wireframe mode and modes highlighting edges are useful.
Tools on side and bottom Alias style configuration. Alias style mouse menu.
Several kinds of cubic splines (B-splines, Be'zier curves, etc.) all do the same curves, but with different specifcations. Our user interface should allow the user to say "now show it to me as a B-spline", and so on.
There are two options for this kind of spline that matter, though:
Uniform/Nonuniform: The uniform splines have all the points where it changes from one curve segment to another uniformly spaced. Non-uniform doesn't (more control).
Rational/Nonrational: A rational spline has an extra coordinate that gets divided, making the whole thing perspective-invariant (it also lets you do perfect circles, etc).
Put together, that's NonUniform Rational B-Splines = NURBS. They cover most of the stuff we'd want to do, and aren't that hard. They don't handle aerodynamic properties very well, but that's about it.
Also on splines: I think that building surfaces out of triangle-like spline surfaces could be nice user-interface-wise. That is, draw the polygon version, and then squish around the triangles. The program is responsible for keeping the edges in sync.
Unfortunately "Subtle lighting effects" is really hard to translate to code. I can do the whole range of directional, specular, diffuse lighting, and I can do ray-tracing, radiosity, ray-casting. Or rather could, given enough time. Doing the non-realistic stuff that looks right is really hard, as it doing stylized stuff, like fantasy artwork. (Or maybe that's not at all what you meant.) While I'm on the lighting topic, I'll mention that the standard Red, Green, & Blue model doesn't handle things like prisms very well, and really fails on stuff like diffraction gratings and holograms.
speaking of, theres no problem having a command line somewhere. buttons can be configurable with batch commands also being linkable(recursively of course) it would be nice to also be able to call it in a mode just as an interpriter of its own scripting language.
I meant for solid objects. Suppose I'm trying to model a piece of metal that has been machined with several holes through it, but has seen been slightly melted. I can't model the surface just as a single spline grid, and unless I always want to store (and edit!) it as CSG operations, I need some way to make sure that the separate spline surfaces stay glued together correctly at the edges. Basically allowing arbitrary otherwise unrelated objects to share verticies and control points is a good idea.
I like having all the displays be (potentially) independent. Having a separate window display the numeric versions of whatever is selected in some main window is a use for non-independent windows.
Cel shading isn't too bad. You can (for the most part) do it after rendering by doing an edge-detect, and quantizing to fewer colors. Depending on what effects you're trying to achieve, other things are possible too.
And while we're discussing non-real stuff, being able to do Escher-like models would be really cool. I don't know how to do it, though.
Non-RBG color models: This is actually really easy. Each "color" of light is dealt with in exactly the same way. It's just a matter of using >3 element vectors instead of 3 element ("true" color) or 1 element (grayscale). The only exceptions are things like phosphorescence, which is a pretty exotic property.
There are some good uses for independent selection. Displaying numeric data about two selected parts is one of the best ways to compare them. Configurable, I guess, but I don't yet see the interface.
Surfaces (polygons, splines, etc.) either have 2 sides (although they default to the same color) or are the boundary of a solid object. That way a user basically can't get to the wierdness involving half-invisible stuff. If you try and make a solid out of a non-closed surface, then it will tell you so. If you make a box and leave off one side, then it will automatically include an inner surface, albiet with the same color by default.
The other thing that a make-solid command gets is the ability to have volumetric textures. So I could make a cube, fill it with a wood texture, and then use CSG stuff to carve it. The system would then automatically fill in the correct grain on the new surfaces.
Cut-away views are a useful feature.
Additional feature: Adding a surface texture onto the volume texture. Useful for stuff like imperfectly opaque paints, or woodstains.
Textures: rasters (2d/3d, various modes, and procedural) sampled transparent volume texture rendering methond
What sorts of components do we care about for texturing?
The program keeps in memory a heirarchy of "things". These can be solids, or lights, or polygons, or any number of other primitives. They can also be collections of other things. There are operations that work on things, like the CSG ones, groupers, ungroupers, transformations, copies, load/save, etc. We can also attach windows to view things, and use them to pick things (generate and change focus things) and manipulate them. If a thing gets modified, it also notifies every thing that contains it, so we get automatically updating windows, easy debug output, accurate numeric displays, etc. Windows can have delayed updates, of course -- It may take a long time to update a photoreal window.
So the way a transparency map works is just like how any other map works, but with an extra property. Or do we want separate transparencies for each of R,G,B? That way a stained-glass window texture could be a 6 property texture map.
Now that I think about it, you might want to be able to specify totally unrelated texture maps (and coordinates) for different properties. I don't know how useful it might be, but we can support it.
Library structure: We define the kinds of properties that can be stored in a "thing", and then the library has functions for creating, grouping, loading, saving, exporting, etc.
Display code uses library traversal functions, and some user interface stuff, and we have a modeler.
But since we made it a library, we could replace the UI with a different one without a lot of code changes. We also get scriptability the same way, and we can support different script languages, too.
I think the rendering style should really be a per window property, and not part of the model itself. That way I can have a realtime updated window that I'm editing in wireframe, and a shaded version that updates only when I click on it. No need to change the data itself...
Actually, this "thing" model allows some interesting save possibilities. You can save your whole workspace just as it is, or just the models inside it. This in addition to being able to save the individual models themselves.
Start with some simple primitives like "keep points a and b X apart" and "keep angle abc at 90 degrees" (or better, keep cos(abc) at .5) Similarly, allow "line between" and "surface defined by"
Also a "noise" function for starting off the correct interpretation of bad (coplanar, all on same point...) input data.
Simulate rigid objects by having them do an intermediate series of recomputations between each step of the larger system.
Instead of doing formal constraints, just use forces on rubber-type material -- it's all spring-mass.
Methods for constraints:
Similarly, allow "line between" and "surface defined by"
Also a "noise" function for starting off the correct interpretation of bad (coplanar, all on same point...) input data.
Simulate rigid objects by having them do an intermediate series of recomputations between each step of the larger system.
Instead of doing formal constraints, just use forces on rubber-type material -- it's all spring-mass.
So the prism case isn't obviously supported, but you can do it: Just set up more than 3 indicies, and feed it to a renderer that knows about it... The renderer becomes the hard part.
Back to my main page.