Pretty Poly Editor Documentation
III. Discussion Topics - 3. Building modes
Obviously there is no alternative to using opengl as rendering engine for PPE.
However, it can be discussed whether the UI should be as heavily influenced by opengl
as it is now. All the building modes there are now could be compressed down to three:
vertex, vertex/line and vertex/line/polygon (v, vl and vlp).
Actually, this might give you more, not less possibilities. For example, you want to do
a disc with a hole in it. Say you have already created all the vertices.
Now, you go into TriStrip or QuadStrip-mode and click on the existing vertices.
In vertex/line/polygon-mode, you do just the same until you click the last
one or two vertices to close it. There is no problem with vertex/line/polygon-mode,
but what happens in QuadStrip-mode? Are two additional vertices created?
Another problem with the current building modes is that it is very easy to make mistakes.
Please look again at the form from the chapter
building modes.
The real solution creates very thin triangles. Normally, artists want to avoid this, so
they might do something like:
When they have done triangle C, then 4 and 5 are the newest vertices. However,
triangle D doesn't border the edge 4-5. Therefore this wont work as a TriStrip.
One can also see this by looking at the number of edges going out from vertex
3. It is clear, that this bunch of triangles can not be represented as one strip, but
only for example as one strip and one fan.
The question is whether the user should be forced to think about such technicalities.
But even when you subdivide the form in a criss-cross pattern, you can get into trouble.
After you created the second triangle, the third should border on
edge 3-4, but doesn't.
Also, it MIGHT be counterintuitive how to input quads versus a quad that is part of a quad-strip.
Lets number the vertices counterclockwise around the first quad. For a single quad, you
input 1,2,3,4. However, for the first quad in a strip you have to input 1,2,4,3.
One proposal would be to always store polygonal leaf nodes as vertex arrays and only
convert them into TriStrips etc when needed. I don't know whether the stripify-algorithm
is good enough for this task?
PPE could then also optimize the model for the current renderer.
When writing an object, PPE could try to generate CVAs, TriStrips, Quadstrips
etc from the internal format, profile them and write the fastest representation to disk.
But of course my main aim is to burden the artist as little as possible with technicalities.
Another possibility would be to have v, vl and vlp-modes as standard and the other modes in
an "expert-setting" or additional "expert-widget".
Something else connected with this is how we solve the problem that due to different
texture coordinates for the same "original" vertex, PPE might generate several vertices
at the same 3D-point. While I no longer think that this will lead to a catastrophe, I still
think it is confusing to the user and should be avoided. If this problem can be solved
for texture coordinates, then we should not have multiple vertices because TriStrips
or QuadStrips need them. How does a cube made of QuadStrips look?
I (Wolfram Kuss) would also like to write down my experience with my own modeller.
Actually, I have four modes: create nothing, v, vl and vlp-modes.
(I just call vlp vef instead, for vertex/edge/face).
Lets look at the following, not uncommon situation:
1-------2--------3----------------4------5
6----7----------8-------------------9--------10
You already have the vertices 1-5 and the edges between them from some "part 1" you created
and the vertices 6-10 and the edges between them from some "part 2" you created.
You now want to connect them. You want to use the feature that the cursor snaps to
vertices. One possibility in my editor would be to:
start vlp-mode
click 1, 6, 7, 2, 1. Since I closed the lines, a polygon is created.
start vlp-mode again (!) This means: Forget the last vertex I clicked on (vertex 1 in this case)
click 2,7,8,3,2
etc.
You see that many steps are necessary, you often have to click vertices twice to close
things and you often have to restart vlp-mode.
Therefore, I implemented something that might be called "auto-close". When you click on
1,6,7,2, my editor realizes that it can create a polygon by using the lines
1-6-7-2 and an additional, already existing line (2-1). Therefore, to do the above,
you just have to:
start vlp-mode
click 1,6,7,2,3,8,9,4,5,10.
Thats it.
This is very fast and for us (=Hammes Software) THE main priority is to make input of models as
fast as possible. However, I have to admit that sometimes polygons are (correctly)
created which you haven't thought about. To minimize this problem, when a polygon has been created,
I write into the status bar how many vertices it has.
Normally, in the situation above you have polygons "above" the line 1-2-3-4-5
and maybe below the line 6-7-8-9-10. When you create the quad 1-2-7-6,
its flipping is calculated from its neighbors. That means, you can either
go clockwise (6-1-2-7) or counter clock-wise (1-6-7-2) and it will always come out right.
Only when there are no existing neighbors, then cw/ccw makes a difference.
Using the same rule, once you created the first polygon, the flipping of all the polygons to come.
Our experience with this "flipping rule" is very good.
However, I think there is still an unsolved problem:
How to have a building mode that is fast (few clicks required), doesn't force you to say I want
to do quads only know (this is required by opengl/PPE) and there is no danger of it creating
polygons you don't want (that is the drawback of the solution in my editor).
Maybe you can satisfy all three aims at the same time.