OpenGL Architecture Review Board Meeting February 13-15 (Winter), 1995 Attendees Kurt Akeley, Silicon Graphics Paula Womack, Silicon Graphics Mason Woo, Silicon Graphics Jim Cobb, Evans and Sutherland John Dennis, Digital Equipment Dale Kirkland, Intergraph Linas Vepstas, IBM Bimal Poddar,IBM Phil Huxley, 3Dlabs Israel Pinkas, Intel Steve Wright, Microsoft Henri Warren, Megatek Mike Heck, Template Graphics Software Randi Rost, Hewlett-Packard Fred Fisher, AccelGraphics H.B. Siegel, Silicon Graphics Monday morning 10 AM Discussion begins with ski adventures and size of Sony television in E and S conference room. John Dennis: Discusses ways to communicate performance information along with X visuals. Lots of customers having problems selecting visuals which are optimal. Using mechanism for extended properties for a year now. Use same mechanism to indicate if certain buffers are "fast" or "slow." Likely candidates are depth buffer, alpha, stencil, etc. Can query these. "Fast" or "slow" is probably enough for most apps. An alternative is a ranking within a set of visuals. Kurt had sent an e-mail. Kurt: either a 2 or 3 valued scheme for each visual. "Good", "mediocre", or "bad." "Mediocre" would return a huge negative score, would only be chosen if no good were available. "Bad" would not be returned unless specifically requested by application. Allows you to export visuals which has more precision or more something. Some visuals you want people to use; others you don't want people to use. They might not be related to performance. Could be talking about visuals which take other resources. You could also have two values: just "good" and "bad." Paula: Two values makes it easiest for unsophisticated programmers. John: would there be an advantage to having more resolution. What is causing trouble: which buffer, for example. Helps more sophisticated app. Try to accomplish 2 things--help naive app and more sophisticated app. Phil: maybe combination of both. I like Kurt's idea, because it's simple. Dale: to the sophisticated app programmer, it's not enough information John: in fairness here, this only applies to X. We have no control over Windows. Jim: that's understood. But it may set an example. Dale: discussed having code which applies a test and "benchmark" capabilities. Paula: The code is there. It's called "isfast" John: we don't recommend our customers to use that. Releases can change performance. Linas: this should be a motivation for groups like the ARB to keep and distribute this information Mason: it's a mess for this group to create and maintain John: difficult to know a priori what an application will find important Discussion about weighting these results. John: glXChooseVisual() often makes the wrong choices in our environment. The min/max triggers provide the wrong ones. Paula: adding new visual attributes is doable, such as SGI has done this with multisampling. John: is changing behavior of chooseVisual backwards compatible? I guess it is. Paula: have to make sure about client/server return. Kurt: don't have to change the man page much. Now some visuals will have new score: a large negative one. John: other requirement is mechanism has to be portable across all implementations. Linas: third method. Instead of "3 different groups" have the visual return "percentage of full performance" John: a have a problem with giving a single number for a visual, because it depends upon what you are doing. I can see how both of the first two methods could work together. Not incompatible. Kurt: how can you work them together into one glXChooseVisual(). Discussion about performance issues not related to buffers, such as texture, line drawing, shaded triangles, etc. Linas discusses getting a bucket of performance information. Paula: What about isfast.c? Can that characterize performance for sophisticated user? John: I like "this is fast in this context." Bimal: You have quality and speed issues. Mason: more important issue is naive users. ISV's will do more work to figure out what's right. John: however, our experience with ISV's is that the ISV's don't do it right. The set up code gets written first, so poor choices in visuals are done. People aren't writing their own choosers. Kurt: I like the ex post facto effect of my proposal. Jim Cobb: I like Kurt's proposal, because it works well for tire kickers. Dale: do you have to modify the API? Kurt: for the 3 choice proposal, there will have to be API modification for the "bad" visuals. We'll have a new category of visuals which are so bad they aren't returned unless specifically requested. John: with that new chooseVisual, is that done automatically or must you pass a token? Kurt: automatically. classic case is you have 8 bit RGB and 12 RGB, but the 12 bit runs 10% of speed of 8 bit. If you make 8 bit good and 12 bit mediocre, then you'll get the 8 bit, unless you specifically ask for more bits. If it was 90% of the speed, maybe they'd be both "good" John: I like this idea. Would like to differentiate the 10% difference. Kurt: going down the slippery slope. This is SGI-centric historically, in that SGI would NOT ship a poor performing visual. But that has changed and all vendors may decide to ship. John: DEC alpha is an example Jim: app asks for what it doesn't need. Need to think about enumerating all cases to see if this method works. Kurt: wouldn't you make a "soft alpha" a mediocre visual? Bad case today is if you had 8 bit RGB and 12 bit RGBA, today 12 bit RGBA would win. You could tune the algorithm. John: examples which are problems: alpha buffer, intermediate color buffer sizes (which are higher performing), double buffering (hardware or copy forward double buffering) Dale: isn't copy forward double buffering affected by window size and who else is using it? John: occurs, but with less frequency. Phil: in particular configuration, you can only have one h/w double buffered window. The 2nd/3rd, etc. are using copy forward. Fred: another one to the list: stencil buffer. Bimal: alpha test. blending modes. John: slippery slope Kurt: want to make the list where the wrong visual is chosen slows performance. Is there a simple policy which fixes that? Paula: example where you have two depths of zbuffer. Is there a case where you have best performance with no depth of zbuffer? Fred: situation where you ask for more than the hardware supports. Give me the best for the hardware. Kurt: but the composite good/mediocre/bad should work John: we've discussed a number of methods. Label each visual "good/bad" and making glXChooseVisual() making backwards compatible. Paula: two choices: tri-value composite per visual (good/mediocre/bad) or per buffer (good/bad per buffer). what are the goals? < From this point on, the tri-value method is referred to as "The Good, Bad, and Ugly" > John: I think granularity vs. simplicity is moot, since simple apps will be shielded by glXChooseVisual(). Discussion about how EVERY method will have the problem of what if visuals are removed in future releases. Discussion about how choosing between the two versions: per visual or per buffer. If buffer types are added in the future, we must default to not wanting them. The ones you get but don't ask for, you don't care about. Straw Vote: #1 composite score per visual; #2 per buffer; #3 do both Fred: 2 Kurt: 1 Phil: 3; second choice 2 IBM: 1 Intergraph: 1 E & S: 1 Digital: 3 straw decision: do #1 now, doesn't preclude eventually going to #3. will it be an extension or an API change (bumping release number). John Dennis suggests avoiding extension. Won't require a protocol change. Will require next token. Paula: compile time issues, client/server issues (it will return error). Must do version bump or extension. I prefer extension. Less permanent; easier to convert later. Kurt and John: The good thing is the app vendor gets the benefit from this first. John: Could do 2 pass scan: first time only considering "good" ones. Second pass folds in "bad" or other visuals. Kurt: My proposal was that any "bad" visual gets a negative value, guaranteed to be worse than any "good" one. Jim: Will this extension be folded into sample implementation? Paula: Like vertex array extension, we can fold it in. The goal is to fold in all EXTs. This would be a candidate. First step is to put together an extension spec for ChooseVisual change. Second step is to fold it into the sample implementation. John Dennis: We have a sense of urgency. having it by the next sample release might be too late. One way to divide the work is to have one person write the spec and one person to write the code. Kurt: I'll write the spec, and will John write the code? Digital and SGI will decide how to work it out. Kurt will write a spec. Paula will check the registry. The spec will be made available to all licensees. John will lead in implementing. < Lunch > Monday afternoon Topic: OpenGL, GLX specification typos, clarifications, and changes Paula: Clarification #1: Clarify what is display listable in GLU. BACKGROUND: Currently all GLU commands can be called after glNewList. However there are a few things to note: 1. gluBuild1DMipmaps and gluBuild2DMipmaps make glGet* calls and also call glPixelStorei. These routines basically implement the following algorithm: retrieve pixel store modes create mipmaps set desired pixel store modes call glTexImage1D/2D to load the mipmaps reset pixel store modes Only the glTexImage1D/2D calls will be placed in the display list. Since the pixel storage modes used are those which are in effect when the display list is created, this will result in the expected behavior. 2. When the nurbs property GLU_AUTO_LOAD_MATRIX is set to GL_TRUE, the NURBS code will retrieve the projection matrix, model view matrix and the viewport from OpenGL in order to compute sampling and culling matrices for each curve or surface that is rendered. The glGet* calls will be executed immediately, so the culling and sampling matrices used to generate the curves/surfaces will be based on matrices in effect when the list was created -- not those in effect when it is executed. 3. Currently gluGetString does not query OpenGL to find out the version and available extensions. However, if we want to allow the GLU to configure itself according to this information in the future (if the GLU is interface is changed so that it is informed when the current context is changed) we should not allow this call after a glNewList. GLU routines that call OpenGL, but don't make any OpenGL Get* calls: gluOrtho2D gluPerspective gluLookAt gluPickMatrix gluBeginPolygon gluTessVertex gluNextContour gluEndPolygon gluTessBeginPolygon gluTessBeginContour gluTessEndContour gluTessEndPolygon gluCylinder gluSphere gluDisk gluPartialDisk gluBeginCurve gluNurbsCurve gluEndCurve gluBeginSurface gluNurbsSurface gluEndSurface gluBeginTrim gluPwlCurve gluEndTrim GLU routines that call OpenGL including OpenGL Get* calls: gluScaleImage (Returns the resulting image to the caller) gluBuild1DMipmaps gluBuild2DMipmaps Nurbs rendering when property is GLU_AUTO_LOAD_MATRIX GLU routines that don't call OpenGL: gluGetString gluProject gluUnProject gluNewTess gluDeleteTess gluTessCallback gluTessProperty gluTessNormal gluNewQuadric gluDeleteQuadric gluQuadricCallback gluQuadricNormals gluQuadricTexture gluQuadricOrientation gluQuadricDrawStyle gluNewNurbsRenderer gluDeleteNurbsRenderer gluNurbsCallback gluLoadSamplingMatrices gluSetNurbsProperty (for properties other than GLU_AUTO_LOAD_MATRIX) gluGetNurbsProperty gluErrorString PROPOSAL (with typos changed): Add the following text to Section 1 "Overview": All GLU routines, except for the initialization routines listed in Section 2 [ed. note: was 1], during display list creation [editor's note: changed from "may be called after glNewList"]. This will cause any OpenGL commands that are issued as a result of the call to be stored in the display list. The result of calling the intialization routines after glNewList is undefined. Add the following paragraph to Section 7.6 "NURBS properties", after the paragraph about GLU_AUTO_LOAD_MATRIX: You may get unexpected results when GLU_AUTO_LOAD_MATRIX is enabled and the results of the NURBS tesselation are being stored in a display list, since the OpenGL matrices which are used to create the sampling and culling matrices will be those that are in effect when the list is created, not those in effect when it is executed. Jim: Is the culling a backface removal call? Is it a tesselate? Trivial reject? Paula: I'm assuming it's referring to tesselation. The GLU_AUTO_LOAD_MATRIX doesn't have to be set. You can pass in your own matrices. When it's set to true, then several matrices will be loaded. When it's false, you can load the sampling matrices yourself. Kurt: Maybe should create a non view dependent tesselation for a display list, but it's not possible. Linas: Not in the Addison-Wesley books. Paula: Books are out of date; new sampling methods. Kurt: "may be called after glNewList" may be too vague. Paula: better wording is "during display list creation". Linas: Do you want to change the man pages? Kurt: may want to note that on initialization routine. John D: I'm confused. gluGetString() won't go into a display list, anyway. Why is that spelled out? Jim: I think it's worth leaving in. Paula: In first sentence, reference should be to Section 2. Linas: It's not so much that AUTO_LOAD_MATRIX is enabled. You will get unexpected results if you have a view dependent matrix. Paula: Can use view independent method. There are these methods. Jim, Paula, Kurt: If someone creates a view dependent NURBS and then calls it, and they get a result, it's predictable. Now if someone forgets they've done that, the result would be unexpected, but that's user error. Jim: Tesselation code is unexpected if you have a view independent matrix. Paula: Trying to say here where the matrices are loaded. Sampling and culling matrices. Kurt: change is in 2nd sentence of 2nd part: "results of the NURBS tesselation is" to "results of the NURBS tesselation are" Linas continues to object. Paula points to spec, within context. man page changes will be in a separate proposal. 7-0 proposal with 3 changes passes. GLU 1.2 Paula: e-mail vote on 1.2 brought up other issues (including typos) John Dennis: want to have a blind data pointer in the Begin/End callbacks. Same mechanism be generalized to all callbacks. They are doing polygon tesselation on behalf of a client. Maintaining their own data structures. Want to be able to do initialization and clean up during tesselation. Want to have their own global variables. Seemed trivial. Comment that Hock made against it was that it would break backwards compatible. Paula: Hock said you need to use existing routines. BeginTess callback exists today without the blind data pointer. You could make another callback routine. John: You are adding new functionality. Some of it is new. Maybe a mishmash of what's old and new. Paula: In Section 5.7, the problem is the gluTessCallback(), which doesn't take a pointer today. John: There will have to modifications to or additions to gluTessCallback(). Jim: Doesn't it generate errors. John: To summarize, the callback should be able to pass user data pointers and believe we can do the backwards compatibility issue. Kurt and John: to meet this evening and see if this can be done. Paula: to vote on gluGetTessProperty() John: asks if new routines should be used. Paula: yes, new routines are recommended. Old routines are for compatibility. 1. Rev GLU to 1.2 2. Replace section 5, "Polygon Tessellation" with: 5. Polygon Tessellation The polygon tessellation routines triangulate concave polygons with one or more closed contours. Several winding rules are supported to determine which parts of the polygon are on the "interior". In addition, boundary extraction is supported: instead of tessellating the polygon, a set of closed contours separating the interior from the exterior are generated. To use these routines, first create a tessellation object. Second, define the callback routines and the tessellation parameters. (The callback routines are used to process the triangles generated by the tessellator.) Finally, specify the concave polygon to be tessellated. Input contours can be intersecting, self-intersecting, or degenerate. Also, polygons with multiple coincident vertices are supported. 5.1 The Tessellation Object A new tessellation object is created with gluNewTess: GLUtesselator *tessobj; tessobj = gluNewTess(void); gluNewTess returns a new tessellation object which is used by the other tessellation functions. A return value of 0 indicates an out-of-memory error. Several tessellator objects may be used simultaneously. When a tessellation object is no longer needed, it should be deleted with gluDeleteTess: void gluDeleteTess(GLUtesselator *tessobj); This will destroy the object and free any memory used by it. 5.2 Polygon Definition The input contours are specified with the following routines: void gluTessBeginPolygon( GLUtesselator *tess, void *polygon_data ); void gluTessBeginContour( GLUtesselator *tess ); void gluTessVertex( GLUtesselator *tess, GLdouble coords[3], void *vertex_data ); void gluTessEndContour( GLUtesselator *tess ); void gluTessEndPolygon( GLUtesselator *tess ); Within each gluTessBeginPolygon/gluTessEndPolygon pair, there can be zero or more calls to gluTessBeginContour/gluTessEndContour. Within each contour, there are zero or more calls to gluTessVertex. The vertices specify a closed contour (the last vertex of each contour is automatically linked to the first). "polygon_data" is a pointer to a user-defined data structure. If the appropriate callback(s) are specified (see "Callbacks" section), then this pointer is returned to the callback function(s). Thus, it is a convenient way to store per-polygon information. "coords" give the coordinates of the vertex in 3-space. For useful results, all vertices should lie in some plane, since the vertices are projected onto a plane before tessellation. "data" is a pointer to a user-defined vertex structure, which typically contains other vertex information such as color, texture coordinates, normal, etc. It is used to refer to the vertex during rendering. When gluTessEndPolygon is called, the tessellation algorithm determines which regions are interior to the given contours, according to one of several "winding rules" described below. The interior regions are then tessellated, and the output is provided as callbacks. gluTessBeginPolygon indicates the start of a polygon, and it must be called first. It is an error to call gluTessBeginContour, outside of a gluTessBeginPolygon/gluTessEndPolygon pair; it is also an error to call gluTessVertex outside of a gluTessBeginContour/gluTessEndContour pair. In addition, gluTessBeginPolygon/gluTessEndPolygon and gluTessBeginContour/ gluTessEndContour calls must pair up. 5.3 Callbacks Callbacks are specified using void gluTessCallback( GLUtesselator *tess, GLenum which, void (*fn)()); This routine replaces the callback selected by "which" with the function specified by "fn". If "fn" is NULL, then any previously defined callback is discarded and becomes undefined. Any of the callbacks may be left undefined; if so, the corresponding information will not be supplied during rendering. (Note that, under some conditions, it is an error to leave the combine callback undefined. See the description of this callback below for details.) "which" may be one of GLU_TESS_BEGIN, GLU_TESS_EDGE_FLAG, GLU_TESS_VERTEX, GLU_TESS_END, GLU_TESS_ERROR, GLU_TESS_COMBINE, GLU_TESS_BEGIN_DATA, GLU_TESS_EDGE_FLAG_DATA, GLU_TESS_VERTEX_DATA, GLU_TESS_END_DATA, GLU_TESS_ERROR_DATA, or GLU_TESS_COMBINE_DATA. The twelve callbacks have the following prototypes: void begin( GLenum type); void edgeFlag(GLboolean flag); void vertex(void *vertex_data); void end(void); void error(GLenum errno); void combine(GLdouble coords[3], void *data[4], GLfloat weight[4], void **outData ); void beginData( GLenum type, void *polygon_data); void edgeFlagData(GLboolean flag, void *polygon_data); void vertexData(void *vertex_data, void *polygon_data); void endData(void *polygon_data); void errorData(GLenum errno, void *polygon_data); void combineData(GLdouble coords[3], void *data[4], GLfloat weight[4], void **outData, void *polygon_data ); Note that there are two versions of each callback: one with user-specified polygon data and one without. If both versions of a particular callback are specified then the callback with "polygon_data" will be used. Note that "polygon_data" is a copy of the pointer that was specfied when gluTessBeginPolygon was called. The begin callbacks indicate the start of a primitive; type is one of GL_TRIANGLE_STRIP, GL_TRIANGLE_FAN, or GL_TRIANGLES (but see the description of the edge flag callbacks below and the notes on "boundary extraction", in section 5.4 where the GLU_TESS_BOUNDARY_ONLY property is described). It is followed by any number of vertex callbacks, which supply the vertices in the same order as expected by the corresponding glBegin call. "vertex_data" is a copy of the pointer that the user provided when the vertex was specified (See gluTessVertex.) After the last vertex of a given primitive, the "end" or "endData" callback is called. If the one of the edge flag callbacks is provided, no triangle fans or strips will be used. When "edgeFlag" or "edgeFlagData" is called, if "flag" is GL_TRUE then each vertex which follows begins an edge which lies on the polygon boundary (i.e., an edge which separates an interior region from an exterior one). If "flag" is GL_FALSE, each vertex which follows begins an edge which lies in the polygon interior. The edge flag callback will be called before the first call to the vertex callback. The "error" or "errorData" callback is invoked when an error is encountered. "errno" will be set to one of GLU_TESS_MISSING_BEGIN_POLYGON, GLU_TESS_MISSING_END_POLYGON, GLU_TESS_MISSING_BEGIN_CONTOUR, GLU_TESS_MISSING_END_CONTOUR, GLU_TESS_COORD_TOO_LARGE, GLU_TESS_NEED_COMBINE_CALLBACK. The first four errors are self-explanatory. The GLU library will recover from these errors by inserting the missing call(s). GLU_TESS_COORD_TOO_LARGE says that some vertex coordinate exceeded the predefined constant GLU_TESS_MAX_COORD in absolute value, and that the value has been clamped. (Coordinate values must be small enough so that two can be multiplied together without overflow.) GLU_TESS_NEED_COMBINE_CALLBACK says that the algorithm detected an intersection between two edges in the input data, and the "combine" callback (below) was not provided. No output will be generated. The "combine" or "combineData" callback is invoked to create a new vertex when the algorithm detects an intersection, or wishes to merge features. The vertex is defined as a linear combination of up to 4 existing vertices, referenced by data[0..3]. The coefficients of the linear combination are given by weight[0..3]; these weights always sum to 1.0. All vertex pointers are valid even when some of the weights are zero. "coords" gives the location of the new vertex. The user must allocate another vertex, interpolate parameters using "data" and "weights", and return the new vertex pointer in "outData". This handle is supplied during rendering callbacks. For example, if the polygon lies in an arbitrary plane in 3-space, and we associate a color with each vertex, the "combine" callback might look like this: void myCombine( GLdouble coords[3], VERTEX *d[4], GLfloat w[4], VERTEX **dataOut ) { VERTEX *new = new_vertex(); new->x = coords[0]; new->y = coords[1]; new->z = coords[2]; new->r = w[0]*d[0]->r + w[1]*d[1]->r + w[2]*d[2]->r + w[3]*d[3]->r; new->g = w[0]*d[0]->g + w[1]*d[1]->g + w[2]*d[2]->g + w[3]*d[3]->g; new->b = w[0]*d[0]->b + w[1]*d[1]->b + w[2]*d[2]->b + w[3]*d[3]->b; new->a = w[0]*d[0]->a + w[1]*d[1]->a + w[2]*d[2]->a + w[3]*d[3]->a; *dataOut = new; } If the algorithm detects an intersection, then the "combine" or "combineData" callback must be defined, and it must write a non-NULL pointer into "dataOut". Otherwise the GLU_TESS_NEED_COMBINE_CALLBACK error occurs, and no output is generated. This is the only error that can occur during tessellation and rendering. 5.4 Control over Tessellation The properties associated with a tessellator object affect the way the polygons are interpreted and rendered. The properties are set by calling: void gluTessProperty( GLUtesselator *tess, GLenum which, GLdouble value ); "which" indicates the property to be modified and must be set to one of GLU_TESS_WINDING_RULE, GLU_TESS_BOUNDARY_ONLY or GLU_TESS_TOLERANCE. "value" specifies the new property value. The GLU_TESS_WINDING_RULE property determines which parts of the polygon are on the "interior". It is an enumerated value; the possible values are: GLU_TESS_WINDING_ODD, GLU_TESS_WINDING_NONZERO, GLU_TESS_WINDING_POSITIVE, GLU_TESS_WINDING_NEGATIVE, and GLU_TESS_WINDING_ABS_GEQ_TWO. To understand how the winding rule works first consider that the input contours parition the plane into regions. The winding rule determines which of these regions are inside the polygon. For a single contour C, the winding number of a point x is simply the signed number of revolutions we make around x as we travel once around C (where CCW is positive). When there are several contours, the individual winding numbers are summed. This procedure associates a signed integer value with each point x in the plane. Note that the winding number is the same for all points in a single region. The winding rule classifies a region as "inside" if its winding number belongs to the chosen category (odd, nonzero, positive, negative, or absolute value of at least two). The previous GLU tessellator (prior to GLU 1.2) used the "odd" rule. The "nonzero" rule is another common way to define the interior. The other three rules are useful for polygon CSG operations (see below). The GLU_TESS_BOUNDARY_ONLY property is a boolean value ("value" should be set to GL_TRUE or GL_FALSE). When set to GL_TRUE, a set of closed contours separating the polygon interior and exterior are returned instead of a tessellation. Exterior contours are oriented CCW with respect to the normal, interior contours are oriented CW. The GLU_TESS_BEGIN callback uses the type GL_LINE_LOOP for each contour. GLU_TESS_TOLERANCE specifies a tolerance for merging features to reduce the size of the output. For example, two vertices which are very close to each other might be replaced by a single vertex. The tolerance is multiplied by the largest coordinate magnitude of any input vertex; this specifies the maximum distance that any feature can move as the result of a single merge operation. If a single feature takes part in several merge operations, the total distance moved could be larger. Feature merging is completely optional; the tolerance is only a hint. The implementation is free to merge in some cases and not in others, or to never merge features at all. The default tolerance is zero. The current implementation merges vertices only if they are exactly coincident, regardless of the current tolerance. A vertex is spliced into an edge only if the implementation is unable to distinguish which side of the edge the vertex lies on. Two edges are merged only when both endpoints are identical. Property values can also be queried by the user: void gluGetTessProperty( GLUtesselator *tess, GLenum which, GLdouble *value ); will load "value" with the value of the property specified by "which". To supply the polygon normal call: void gluTessNormal( GLUtesselator *tess, GLdouble x, GLdouble y, GLdouble z ) All input data will be projected into a plane perpendicular to the normal before tessellation and all output triangles will be oriented CCW with respect to the normal (CW orientation can be obtained by reversing the sign of the supplied normal). For example, if you know that all polygons lie in the x-y plane, call "gluTessNormal(tess, 0.0, 0.0, 1.0)" before rendering any polygons. If the supplied normal is (0,0,0) (the default value), the normal is determined as follows. The direction of the normal, up to its sign, is found by fitting a plane to the vertices, without regard to how the vertices are connected. It is expected that the input data lies approximately in plane; otherwise projection perpendicular to the computed normal may substantially change the geometry. The sign of the normal is chosen so that the sum of the signed areas of all input contours is non-negative (where a CCW contour has positive area). The supplied normal persists until it is changed by another call to gluTessNormal. 5.5 Polygon CSG operations The features of the tessellator make it easy to find the union, difference, or intersection of several polygons. First, assume that each polygon is defined so that the winding number is 0 for each exterior region, and 1 for each interior region. Under this model, CCW contours define the outer boundary of the polygon, and CW contours define holes. Contours may be nested, but a nested contour must be oriented oppositely from the contour that contains it. If the original polygons do not satisfy this description, they can be converted to this form by first running the tessellator with the GLU_TESS_BOUNDARY_ONLY property turned on. This returns a list of contours satisfying the restriction above. By allocating two tessellator objects, the callbacks from one tessellator can be fed directly to the input of another. Given two or more polygons of the form above, CSG operations can be implemented as follows: Union Draw all the input contours as a single polygon. The winding number of each resulting region is the number of original polygons which cover it. The union can be extracted using the GLU_TESS_WINDING_NONZERO or GLU_TESS_WINDING_POSITIVE winding rules. Note that with the nonzero rule, we would get the same result if all contour orientations were reversed. Intersection (two polygons at a time only) Draw a single polygon using the contours from both input polygons. Extract the result using GLU_TESS_WINDING_ABS_GEQ_TWO. (Since this winding rule looks at the absolute value, reversing all contour orientations does not change the result.) Difference Suppose we want to compute A \ (B union C union D). Draw a single polygon consisting of the unmodified contours from A, followed by the contours of B,C,D with the vertex order reversed (this changes the winding number of the interior regions to -1). To extract the result, use the GLU_TESS_WINDING_POSITIVE rule. If B,C,D are the result of a GLU_TESS_BOUNDARY_ONLY call, an alternative to reversing the vertex order is to reverse the sign of the supplied normal. For example in the x-y plane, call gluTessNormal( tess, 0.0, 0.0, -1.0 ). 5.6 Performance The tessellator is not intended for immediate-mode rendering; when possible the output should be cached in a user structure or display list. General polygon tessellation is an inherently difficult problem, especially given the goal of extreme robustness. The implementation makes an effort to output a small number of fans and strips; this should improve the rendering performance when the output is used in a display list. Single-contour input polygons are first tested to see whether they can be rendered as a triangle fan with respect to the first vertex (to avoid running the full decomposition algorithm on convex polygons). Non-convex polygons may be rendered by this "fast path" as well, if the algorithm gets lucky in its choice of a starting vertex. For best performance follow these guidelines: - supply the polygon normal, if available, using gluTessNormal. This represents about 10% of the computation time. For example, if all polygons lie in the x-y plane, use gluTessNormal(tess,0,0,1). - render many polygons using the same tessellator object, rather than allocating a new tessellator for each one. (In a multi-threaded, multi-processor environment you may get better performance using several tessellators.) 5.7 Backward Compatibility The polygon tessellation routines described previously are new in version 1.2 of the GLU library. For backwards compatibility, earlier versions of these routines are still supported: void gluBeginPolygon(GLUtesselator *tess ); void gluNextContour(GLUtesselator *tess, GLenum type ); void gluEndPolygon(GLUtesselator *tess ); gluBeginPolygon indicates the start of the polygon and gluEndPolygon defines the end of the polygon. gluNextContour is called once before each contour; however it does not need to be called when specifying a polygon with one contour. "type" is ignored by the GLU tessellator. ("type" is one of GLU_EXTERIOR, GLU_INTERIOR, GLU_CCW, GLU_CW, or GLU_UNKNOWN.) Calls to gluBeginPolygon, gluNextContour and gluEndPolygon are mapped to the new tessellator interface as follows: gluBeginPolygon -> gluTessBeginPolygon gluTessBeginContour gluNextContour -> gluTessEndContour gluTessBeginContour gluEndPolygon -> gluTessEndContour gluTessEndPolygon Constants and data structures used in the previous versions of the tessellator are also still supported. GLU_BEGIN, GLU_VERTEX, GLU_END, GLU_ERROR, and GLU_EDGE_FLAG are defined as synonyms for GLU_TESS_BEGIN, GLU_TESS_VERTEX, GLU_TESS_END, GLU_TESS_ERROR, and GLU_TESS_EDGE_FLAG. GLUtriangulatorObj is defined to be the same as GLUtesselator. The preferred interface for polygon tessellation is the one described in sections 5.1 to 5.4. The routines described in this section are provided for backward compatibility only. ------ Paula: next issue is not really for voting. Chris brought it up for the last meeting when a CopyContext occurs. What happens to states, matrices, etc. He has a program which he posted on the net. Please try this. After we try it, we (the ARB) should figure out if we want to clarify the spec. Bimal: After I read the program, I expected "red" and that's what happened. Linas: On the latest release? Discuss about whether to expect "green & green" or "green & red." The spec does not say what's going on here. The idea here is to collect some data. Maybe we'll have a proposal after more data is collected. Paula: One last thing. If you aren't copying the color bit and lighting bit together, it's actually order dependent. Chris Frazier is changing what's enabled: diffuse and specular. Bimal want to talk to Paula later. --------- FORTRAN (page 17) Fortran bindings: update from last meeting At the last meeting we voted to have the Fortran constants named the same as the C constants (i.e., prefix them with GL_ instead of FGL_.) There were a couple of open issues: 1) What happens for names longer than 31 characters? Most fortran compilers have a truncation option so these identifiers will be truncated to 31 characters. There are some compilers that do not support this and will error out on ids with more than 31 characters. Is this an issue for any licensees? Should we be providing short versions of the identifiers, that are selectable by a compile time option? 2) What happens when the 31st character is an underscore? This is not an issue since F90 allows an underscore as the trailing (last) character in an identifier. F77 doesn't allow underscores in the name at all (but it appears that most F77 compilers will handle this case.) Paula: Again, this is for discussion, not for a vote. FORTRAN constant names should be same as C. What to do if name is longer than 31 characters. Allen Akin was wrong about underscores. Post-Fortran 77 compilers don't have problems with underscores. (F77 did have a problem with underscores, but also > 6 letter names, too.) Israel and Paula: Discuss research into this. Internal examples and compiler authors cited. Jim: Is there an implementation? Paula: It's a spec, but not a sample implementation. < below are e-mail comments from Allen Akin > There's been some confusion about [underscore problems]. Even though the F90 standard doesn't object to an underscore in the last significant position of a long name, we have one report of an F77 compiler that does, and I suspect the problem could apply to both F77 and F90. Consider the common UNIX FORTRAN practice of adding a trailing underscore to external references, so that it's easy to build FORTRAN wrappers for C library routines. In environments where the maximum length for externally-visible names is 32 characters, a FORTRAN compiler would process a name this way: X234567890123456789012345678901_ABC -> X234567890123456789012345678901 (truncate to 31 chars) -> X234567890123456789012345678901_ (append underscore) While a C compiler would process the name this way: X234567890123456789012345678901_ABC -> X234567890123456789012345678901_ (truncate to 32 chars) This makes the C and FORTRAN names indistinguishable, and thus messes up linking. It's quite possible that there are FORTRAN compilers that check for this condition and report it as an error. Personally I'd rather pick OpenGL names that are guaranteed not to have this problem. However, the rest of the FORTRAN binding crew has beaten me into submission. I gave in because none of today's linker-visible OpenGL names have underscores, so the risk seems manageable. However, if something changes in the future, or if OpenGL is ever used on the F77 compiler that complains about underscores in the last significant position, you were warned. :-) ---------------------------------- Changes to Vertex Array Man Pages: Paula: The following (see below) are updates to man pages. Don't think we need to vote, since they are an extension. Kurt: Who is implementing vertex arrays? John Dennis: Digital's is shipping in 2 weeks Fred: Is this public? Kurt: It's public to other licensees. Israel: How do people know how to use it? Paula: Man pages are only info. It's not part of the spec, because it's an extension. It's a moving target. 1) Clean up "See Also" sections: glGetPointerEXT -> glGetPointervEXT glArrayElementEXT: 2) Change 1st sentence of description from : glArrayElementEXT commands are used within glBegin/glEnd pairs to specify vertex and attribute data for point, line and polygon primitives. When glArrayElementEXT is called, a single vertex is drawn, using vertex and attribute data taken from location "i" of the enabled arrays. to: glArrayElementEXT commands are used within glBegin/glEnd pairs to specify vertex and/or attribute data for point, line and polygon primitives. If GL_VERTEX_ARRAY_EXT is enabled when glArrayElementEXT is called, then a single vertex is drawn, using vertex and attribute data taken from location "i" of the enabled arrays. If GL_VERTEX_ARRAY_EXT is not enabled then no drawing occurs but the attributes corresponding to the enabled arrays are modified. and remove this from the notes section: glArrayElementEXT executes even if GL_VERTEX_ARRAY_EXT is not enabled. No drawing occurs in this case, but the attributes corresponding to enabled arrays are modified. ----------------- glColorPointerEXT, glEdgeFlagPointerEXT, glIndexPointerEXT, glTexCoordPointerEXT, glNormalPointerEXT, glVertexPointerEXT: 3) Add to "See Also": glEnable. 4) Change first sentence from: specifies the location and data format of an array of to use when rendering. to: specifies the location and data format of an array of to use when rendering using the vertex array extension. (e.g. "glColorPointerEXT specifies the location and data format of an array of color components to use when rendering using the vertex array extension.") 5) Remove extra comma: Although, it is not an error to call ----- Conformance Test issues Paula: Simon Hui noticed that the conformance tests weren't initializing the window property hint fields in the data structures. Vote to initialize window property hints in conformance tests. To initialize: vote 7-0 passes Reordering in tests of conformance script Jim Cobb: a portion of conformance are mustpass.c and a portion is "not mustpass." Current ordering is: covglx, covgl, mustpass, conform (path 0), conform (path 1), conform (path 2), conform (path3), conformx, primtest, covglu. The ones which are part of covgl, mustpass, primtest, covglu, and (maybe mandatory for X) covglx. Would like to propose shuffling the sequence to put the "mustpass" to the top. Would like to propose this reordering, also with new C shell script initialization: #!/bin/csh -f covglx covgl covglu primtest mustpass conform path 0 conform path 1 conform path 2 conform path 3 conformx Proposal passes: 7-0 -------- glXIntro man pages The man page assumed a single buffer visual was available. Proposal to look for single, and if that fails, it looks for double. Linas: need to do swapbuffers to have drawing Jim: some implementations where you get a double when you ask for a single. Such as Softgraphics. Linas: won't return a visual John Dennis: I thought this was supposed to create the shortest possible program on the man page. Kurt: Can always do draw into front buffer. John: Swap is a better example for naive users. Paula: If we add swapbuffers to end (adding a flag, if double buffers is used). Proposal with flag and swap buffers: Passes 7-0. ------ Discussion from Dale Kirkland about next ARB meeting. Will be starting Monday, May 15 at 9 AM. OPC starting Wednesday, May 17th. Best place to fly into is Pensacola. If you want to go on Saturday and spend the entire weekend on the beach, you must reserve your room now! You can change the reservation to Sunday, up to 3 days in advance. However, if you say Sunday, you probably can't change it to Saturday. There's good golf, too. Make your reservations directly with the hotel, until the rooms are all booked out. MUST REGISTER BY APRIL 14, 1995. After that, rates and availability are uncertain. Break time ---------- Sample GL release (1.0.16) Paula: We're back into development mode. GLX 1.1 , GLU 1.1, Vertex array extensions. This is the shift we want to go to. We would like to go into a 6 month release cycle. John Dennis: We at Digital are at a 3 month release cycle. Linas: We have 4 month cycles Paula: We'd like to have next sample release at June. Also, we'd like to know which extensions are available. We're not saying that we'll make the 6 month cycle permanent, but for this once. John: We'd be willing to support it, if there is some mechanism for pre- release versions of other features (for not solid features). Willing to get it untested. Caveat to have some confidence it will work. Paula: 1.0.16 will have: -bug fixes -ada bindings -metafiles with a viewer (that runs on GLX) -GLU 1.2 -extensions, including abgr, blend_logic_op, rescale_normal, polygon_offset, texture_object -port samples to GLUT (maybe viewperf?) John: Told by one of Digital customers that SGI is shipping libtess. Mason & Paula: We're providing libtess.a as an alpha to a handful of beta sites, for testing, but it's not folding into GLU. Who is the customer? John: Can't remember. Someone in France. Jim: What is rescale_normal? Kurt: Right now, the normal is transformed by inverse of modelview matrix. That includes scaling. This eliminates that effect. Paula: If anyone has an extension for the sample implementation, that's important, please let me know. Jim: What about vertex array? Paula: It's already in the sample implementation. Mason: I had received a request for Ada status. I believe this means an Ada specification will be ready for the June release. Paula: That's true. In a method similar to FORTRAN. Kurt: I think it's important that that be reviewed beforehand. (Enumerants are one issue.) Fred has some questions about Ada. Discussion about having different names from C. Ada might have different names from C. Depends upon how formal--research to be done. ------- Kurt has general questions and spec changes Kurt: talked with Dale at break. Amended texture objects to be shared between contexts, as long as display lists are also shared. Dale: few things that came up while implementing texture objects. You can delete it while someone else is accessing it. Hopefully, no one will use it like that, anyway. Kurt: Has anyone tried to implement pbuffer (pixel buffers)? We're spending lots of time debating how it's implemented and may make drastic changes. Jim: I know of some customers who are very interested. Fred: how does it work? Kurt: AUX buffers was one way of accessing memory which was less volatile than windows, but more volatile than frame buffer. Also not limited to size of windows. Pbuffers is another way. Some X people are upset by making windows not visible to the X server. That drove us away from the AUX buffer solution. This is sort of a warning. We're not finished with the off-screen rendering problem. John: What demand do we have? Kurt: There is demand for using it, both for geometric and imaging ISVs. Another issue is that we want to be able to go from one drawable into another. For example, copy pixels from one window to another or into another's texture. We're thinking of relaxing the visual similarity rules for these copies. Paula: A pbuffer is a separate drawable. It's not tied to any window. In theory, a pbuffer could support its own zbuffer, etc. It's an accelerated pixmap that's volatile. Kurt: Want to go over vertex array, versus display lists. When you put vertex array stuff in a display list, there are NO unresolved references in that display list. Can't put pointer references, because they may be unresolved. Otherwise, it wouldn't work for client/server! If they are static, immediate mode, then the pointer reference can be in there. Kurt: Transparent pixel extension. Preliminary proposal of what to add for GLX. To add to GLX so you can get not only the GLX_LEVEL of a window, but also the pixel value of the transparent pixel. This way the application can ask for a transparent visual, and hopefully glXGetConfig() will tell you which pixel is transparent. The obvious ones are all zeros and all ones. John: Some of things in the Core visual aren't returned. Paula: Depth, some of the masks. That's about it, right? Kurt: If there is anything a typical X programmer wants, let us know. Linas: makes point about color map type. What about True_Color and Direct_Color. John: by the end of the day, you have to go back to core X for information about visuals. No such thing as one-stop shopping. Kurt: there are 6 GLX tokens, which correspond to the standard 6 X visuals: True, Direct, Psuedo, etc. It doesn't have API protocol, but there was a small semantic change. Action Item: do the VisualInfo extension modify chooseVisual, so you can specify X Visual types? Kurt and Paula to find out. Randi Rost: Yes, I really think it does. The motivation was to get RGB rendering semantics for other visual types. < Since the ARB meeting, Paula has checked the VisualInfo extension spec to verify that it supports querying the X visual type of a particular visual. It does. > ----- Kurt spec changes from Mark Segal mundane: Copyright page doesn't include 1995. Change dates on every page to 1/1/1995. Linas: request to add revision number on front page. Jim and John: would be nice to have GLU revision to refer to GLX and GL revision. The following are spec changes: Kurt: In table 2.2, page 10, changes Figure 2.4, 3rd line, has extra word, "the" Page 89: equation for Tau. Brackets and parentheses should be swapped. Jim: Ceiling function and floor function aren't defined in the spec. That was confusing to some people. Israel: But those are standard mathematical symbols. What about all math symbols: greater than, for example? Kurt: Been asked if negative numbers round towards zero or infinity. Jim: Put those in there, too. Kurt: Does the spec use Trunc? Trunc is generally a bad idea in graphics. page 131: Indices to which no display list correspond are "simply" ignored. Suggestion to remove "simply." Vote on those 6 "typos": Pass 7-0. Page 12, middle of 3rd paragraph, "If generating command...", change to "would have returned a value, then it returns zero." Changes next sentence, too. Jim: He is correct. Henri: He would have been. No one in favor, does not pass. Page 30: under equation 2.1 (2nd line of text): "If m sub u is the ...", changes to: "To simply normal transformation, an implementation may choose to obtain (n_x' n_y' n_z') from Vote in favor: 7-0. Linas: Intermixing evaluator calls with explicit specific of color and normal calls. Evaluator calls have same problem as vertex array. Bimal: I think what Linas is saying is that what does it mean to say that evaluation has been performed. Kurt: Evaluation shouldn't update color and normal. Linas says you should be allowed not to. John: may be a problem with our specification. Kurt: Chpt 3, 3rd para (pg. 51) strike final sentence Jim: I don't like deleting it. I could see replacing it with another sentence about the assumption of square fragments in OpenGL. Dale: We don't do any x/y ratio math. John: What about PC world? Dale: Problem is when doing 1K by 1K on a rectangular tube. Most people move them back out. Kurt: I want to leave this alone. I won't propose a vote on it. Page 73 (section 13) Pixel unpacking: convert typography for type names typewriter font (i.e., references to ubyte) 1st paragraph: last 2 sentences should be one sentence with a semi-colon. 2nd para; 2nd sentence: Remove "set to" and capitalize table; add period after table number. Vote to all previous changes: Passes 7-0 3rd para; change sentence before equation 3.5. Kurt: I didn't say clearly that a location in memory is in units of whatever the elements are. Mark wants to rewrite the sentence to make it more clear. The intention is to make the units of location more clear. Steve Wright: Use of "indicates" makes it more vague. Kurt: Oh, yes. It's also wrong to say "skipping" here. This is the address measured in elements. This is Mark's choice to rewrite it. I want to fix the skipping problem. Proposal is to accept the text exactly the way: Passes 7-0 Kurt: last one. Table 4.3 (pg. 103) Replace table to say "all 1's" and strike the first sentence of the 2nd paragraph of the logicop section. Israel: Not is referred to elsewhere in the table. Jim: Tilde 0, using the same ~ elsewhere Discussion about !0, which is 1. Vote on exactly the way Mark wrote changes: Passes 7-0. Adjourn for Monday Tuesday, February 14, 1995 Additional Attendees Dick Coulter, Digital Equipment Hock San Lee, Microsoft Mike Lambert, Chief Technical Officer, X/Open Robert Noyes, X/Open Alberto Savoia, Sun Labs 9 AM It's snowing like hell outside. I don't think we're going night skiing. Mike Lambert of X/Open to discuss X/Open and how OpenGL may be submitted for consideration as an X/Open standard. Who is X/Open? * stakeholders in Open Systems, committed to maximizing the value of Open Systems * Not for profit Intl consortium with a proven track record * incorporated in the United Kingdom * legally vendor independent and product neutral * the integrator * can submit directly to ISO * objective is not to take over the work of other consortiums * objective is to accelerate open systems * Shareholders pay $600K annually * Technical Buy-Out members pay $150K/year. Other levels available. * NPO's pay $5K/year. * X/Open is about 55 staff members: UK, US, and Tokyo. But over 800 individuals are actively participating with X/Open projects. What does X/Open do? To bring Value to Users through the Practical implementation of Open Systems. Became independent in 1987. To create a volume market for software in Europe. 5 rules for Open systems: 1) specification must be fit for purpose 2) widespread availability 3) co-existence with legacy systems (legacy == existing) 4) assured conformance (including trademark and branding scheme) 5) basis for innovation (fight moribund technology) John Dennis: You said you have the legal authority to enforce conformance. Mike: will address that. Book/Brand/Survey Branding * certification scheme * Open to any applicant * operates through Trade Mark law certain markets where brand is a major door opener. Where X/Open is mandatory, but preferred. We allow implementors to go beyond the spec? Hock: Do you have conformance tests? How do you do them? Mike: We have them. I don't think they are as important as I originally thought. Sun is our prime contractor for automated testing. Hock: What happens if there is a bug which is tested for incorrectly? What if Windows ships with a bug, which is now (an incorrect) part of conformance? Mike: relays anecdotes about situations where conformance tests written to the specification have uncovered bugs. The sample implementation is more important than the specification. The specification should be modified to reflect reality. UNIX, as an example, went to the IEEE. Would UNIX be better another way? Maybe academically true, but the practical considerations are overriding. John: Is that an invitation to incompatible changes to specifications? Mike: The market drives the solution, the take up in the market. Jim Cobb: Is there a divergence between the X Consortium and the X/Open X? Mike: No, there isn't. We get little interest from anyone in the industry to improve the spec. We have given some feedback on the bitmap rendering of curves, and gave that to MIT. But people think the standard is the sample implementation from MIT. We worked with the X consortium to develop a test suite. And all the implementations failed, and failed consistently. That showed how the specification and SI were out of line. John Dennis: Isn't there a case-by-case decision making? Who is making these value judgements? Mike: X/Open has an interpretations process, hopefully as lightweight as possible. We have an industry expert and interpretations group. 9 times out of 10, it's a no-brainer. Linas: Have you ever disagreed with Bob Scheifler? Mike: No. We don't have any problems with position of X. Broad industry agreement. Decisions can't take too long. We have a 28 day decision deadline; sometimes we make interim decisions/temporary interpretations. John Dennis: Who is on the interpretation committee? Mike: Good question. When X/Open was only shareholders, it was easy. The pragmatic approach is that all the companies who participate in the creation of the spec make up the committee. Where there is a 3rd party, we go back to the committee. There is a liaison agreement. H.B.: What's a shareholder or technical buy out member? Mike: Legally, each shareholder has a 1 pound share. A shareholder has a financial annual commitment, and is a buy-out of everything X/Open has access to. Technical buy-out gets you a technical manager" seat. Israel: What about ambiguities in specs? Mike: That's one of the reasons we are moving towards formal language. Either we'll evolve the spec towards the true behavior. We also have a conformance statement questionnaire. For example, are you familiar with CDE (common desktop environment), we needed to put many specs in place (windowing, ui, motif, calendaring/scheduling) and they are integrated. We have conformance tests where appropriate. And then the questionnaire is how the product relates to the specification. Where there is an OR," the implementor specifies which option is used. Or "Does it do....?" Some people put their conformance statement questionnaires on the Web. Linas: Where can a customer get their conformance statement questionnaire? Mike: From the implementor. It's not supplied by X/Open. But the implementor MUST make it available. John: Seems like X/Open encourages grey areas in specs. What's the process? Mike: X/Open thinks it's highly undesirable. Target is nil. But we understand it will happen. Will discuss process later. Israel: I think the grey area is more important to specs without sample imp. Mike: I wouldn't agree. An SampleImp may make you lazy. Linas: Is John talking about willful misinterpretation? John: No. I just want to know how the process works. If two divergent Imps exist, how does the process seek to eliminate that ambiguity? Mike: It comes back to market presence. If the vote is decisive, then one behavior is dominant. If there isn't a dominant behavior, you usually live with the ambiguity, unless it's dangerous. John: It seems that the "Conformance Statement Questionnaire" encourages or tolerates ambiguity. Mike: It should be the last resort. Linas: There will be ambiguities. Israel: I think the statement is for known gray areas or optional features. John: How long does that ambiguity stay in existence? Mike: It lasts only as long as the next release. How does X/Open do it? Mike: the traditional spec process; consensus based; 75% of working group for adoption. Currently there are 19 votes. Jim: Is it the same committee for all the standards? Mike: Yes. Looking to create an integrated approach. $25K/year to participate. Simple majority to start (agree to baseline). Consensus for specification and industry consensus. Adoption is not a Yes/No vote; it's a Yes/If vote. We've had 2 failures throughout the entire history. X/Open defers to all international standards. "Remains fit for purpose" We have 3 categories of specification: 1) snapshot (limited consensus; proof of concept; no commitment; no conformance claims) 2) preliminary (full consensus; prototype implementation; commitment to proceed; no basis for conformance still) 3) X/Open (full consensus; available product; commitment to establish branding; basis for branding) Hock: Is there a sample implementation? Mike: We don't demand samp Imp. We're not in that business. We're increasingly moving away from traditional specification process, the more we work towards Fast Track. For OpenGL, we would have no value to create an Expert Working Group. Fast Track means specification goes right into Adoption vote. Warning: X/Open is not a rubber stamp. There are 2 things which can cause failure: 1) specification is of poor quality. For example, DCE from OSF, but RPC specification failed--too many gray areas. 2) something which is proposed just doesn't have industry acceptance. Linas: How does branding work? How many products? Mike: No obligation to ship any of the products. There is a component description for each branded product. The essence of the X/Open branding is to link specifications to what people want to buy. There are about 10 today. Jim: Let's say you meet 4 branded technologies. If a 5th one comes along, do you lose your branding. Mike: No, that doesn't happen. The 5th one will be treated as a distinct brand. Paula: Have you branded any other graphics libraries? Mike: No. Looked at PHIGS, PEX, and GKS, but no action taken. About 2 years ago, I had my first conversations about OpenGL. But 75% would not have been possible then. But I think it would be close today. X/Open and OpenGL Mike: Fast Track is clearly the way to go. Needs: * a specification * a sponsor * access to technical expertise (the ARB seems to be that) Mason: Silicon Graphics has interest in being the sponsor, if no negative impact on the ARB. 1. OpenGL ARB agrees to submit to the Fast Track agrees to meet X/Open Interface Adoption Criteria on successful completion. * copyright (license to print the specification) * patents * anyone can create API 2. X/Open Technical Managers vote to acept spec into Fast Track 3. X/Open appoints Manager for process Only at end of process, do IPR (intellectual property rights) move over. John Dennis: licensing fees for use of this technology and trade mark. Mike: licensing income for trademark (OpenGL logo) and sample implementation Lightweight process for acceptance of updates. Use of OpenGL trademark in branding is subject to negotiation. 4. OpenGL specification delivered to X/Open 5. X/Open assesses acceptability of quality/format and advises regarding changes to ensure success 6. technical managers execute a detailed "company review" Kurt: Concerned that you might find that successful 3D graphics standards will have gray areas. Linas; We heard earlier about pixelization of arcs, circles, etc. in X Windows. Israel: The OpenGL spec says that pixel inexactness is built into OpenGL Mike: Gives CDE as an example. We say that it has a calculator, we don't say it is blue and green. Another example is that int and pointer are assumed to be the same size. We have experience with deliberate lack of precision. Steve: What kind of issues gave up with PHIGS, PEXlib, etc? Mike: They weren't even submitted at the end of the day. It wasn't seen as as important as other things. 7. OpenGL expert group review issues and proposes how to resolve them 8. Technical Managers vote on proposed resolution This usually gets to closure. If vote passes: 1) X/Open publishes spec 2) X/Open and ARB jointly develop necessary test suites and branding materials 3) Either X/Open or ARB provides ongoing maintenance If vote fails: 1) ARB maintains control * may change spec and resubmit * may register with X/Open as non-consensus spec * may withdraw from the process 2) SGI retains all IPR rights until completion of process Embarassment will result from efforts to sabatoge. Why Use X/Open? Vendor neutral Proven Fast-track process (legal in US) Respected Branding scheme Legal Infrastructure Direct route to procurement/formal standardization Presentation to X/Open Techncial Managers in support of submission: * March in Austin, Texas (after Uniforum) * June in Glasgow, Scotland (beginning of June) * July in Annecy, France John Dennis: OpenGL spec is incomplete. There are ancillary specs unique to specific environments (such as GLX and WGL). Are there other examples? Mike: There are many in the communications arena. John: There are some cases where the ancillary specs are considered proprietary and not in control of the ARB. H. B.: Mentioned some situations were not technically satisfying. Give an example where the review process made it better. Mike: ISAM. Operating systems interfaces. CDE is a success story, because it will have created a volume market. Transaction processing (interoperability specs and heterogenous demonstrations). Linas: What about version numbering? Mike: I can answer that in 2 weeks time, but not today. I'll explain then. Randi: What does the X in X/Open stand for? Mike: Wanted to call ourselves of the Open Unix Group. So we used X to mean UNIX. --------------- Break 11:30 AM Alberto Savoia, Director, Software Research, Sun Labs discussing creating testing suites * give OpenGL ARB an overview of ADL project and technology. * help ADL project team and ARB decide if a joint effort to develop a test suite. ADL project overview * mission: identify technology with most promise * key participants are MITI, X/Open and Sun Project budget is $8M for 4 years. Year 1 (selection criteria/review board) Year 2 93-94 (design spec) Year 3 94-95 (alpha) Year 4 95-96 (implementation) Formal methods have bad rap in the past. Formal methods to deliver higher quality and productivity. Also to enable automation. 2 ways to improve software quality * defect prevention * detection and removal When people use ADL, they use a formal language at right level of abstraction. Formal methods find and prevent defects. Kurt: When did you find out? Alberto: Some academic papers. But we have in house, making every single deliverable in-house. Formal spec used for implementation. Defect detection. Formal spec is used as basis for automatically generating auto-checking tests. Behavior imbedded in formal spec. Uses automatic test generator to generate test suite. Not working at automating creating an implementation from a formal spec :-) Think of a sorting routine. Spec could be simple: everything more than previous ones. Many ways to implement. Key to success easy to learn for average software easy to read, write, communicate with (not using APL characters :-) ) suitable for automated test generation suitable for wide range of programming and spec languages (C, C++, ADA, FORTRAN, IDL, etc.) allows partial specs engineer decides level of abstraction ADL--Assertion Definition Language (the practical spec language) * satisfies all requirements * version 1.0 * rapidly gaining acceptance. May be first standard * international standard (X/Open, maybe ISO, but you lose control of language with ISO) ADL has simple specification model Operation is a list of assertions If people know C or Ada, they can use those expressions, and some ADL- specific operators. @disk_full() --> return == -1 && errno == ENOSPC if disk full before execute operation, return -1 and error code glIsEnabled(GL_SCISSOR_TEST) <-> !gltsModifiable(x - 1, y - 1) emphasis on Error semantics ADL allows use with auxiliary functions and high level of abstraction Once you have specifications like this, use ADLT ("World's Most Powerful Automated Test Generator") * ADLT--ADL Translator * generates test suites from ADL specifications * Versions 0.6 (1.0 scheduled for Dec 95) * freely available from ftp.uu.net:/vendor/adl ADLT inputs: ADLT spec, test data description, natural language dictionary output: test case, test spect, natural language spec TDD (Test Data Description) test cases and negative test cases (should generate error) data and directives clearly should use variable values (SMALL, LARGE, etc., not fixed values) each assertion in the spec is exercised at least once Initial results * have been able to specify every interface and implementation. We were able to write ADL specs for the interface, generate tests and find defects. UNIX system calls, libs, and comands Motif OMG's CORBA (common object request broker architecture) PIKS X/Open TET * a growing number of companies and standards organizations (e.g., X/Open, ISO, NIST, Mitre, APTest, ..) have decided to adopt or are planning to adopt ADL technology. Basic OpenGL proposal * To demonstrate the power of the technology to the industry at large, we have decided to organize, subsidize, and manage the development of 2 or 3 large scale test suites using ADL technology. H.B.: Did you apply ADL to itself? Alberto: ADL is good/great for some things, like interfaces and libraries. Compilers work miserably. We are looking for systems with the following properties: * medium to large size and complexity * relatively stable * more than one implementation * interesting & suitable semantics * user base * test suite Why do we like OpenGL * size and complexity right * no thorough, non proprietary test suite * there are multiple implementations and more * active and growing user community * no thorough, non proprietary test suite * juicy semantics (state machine with many states) have experience in this area: both PHIGS and GKS. can add real value to OpenGL FUN! Joint effort Evans & Sutherland HP IBM Microsoft SGI Template Win-Win * should be great win for OpenGL (deliver validation suite, quality and consistency, better time to market, happier implementors, affordable first class test suite) * ADL win-clear demonstration of power of this technology. Graphics make good demos. As a researcher, I want as many people to use my research as possible. Alberto's grad student's guess: 40-45% of OpenGL can be completed automated. 40-45% partially. 10- 20% will require a traditional approach. Kurt: Is caching a good analogy? Do you have 10% of cache misses? Alberto: I think compilers are a better analogy. You would do 90% in high level abstractions, but 10% in assembler. Jim: What's nasty? Alberto: Didn't bring my list here. Pixel accuracy issue is largest. You have to allow a degree of freedom among architectures. For some functions, a complete spec. Testing sequence is: run standard implementation on reference HW platform then run implentation under test on hardware on test take difference between images through image processing tricks you can eliminate allowable differences Funding model: budget is $900K (~6 to 7 MTS years). Still have to propose to MITI and X/Open in March at Uniforum to get some funding. We'll need some partners. We'll have a very thorough test suite in 18 months. After it has been generated, changing ADL, TDD, or "provide" functions, or "auxiliary" functions (such as gltsScissorBox) John: What's your portability experience? Alberto: Very portable. Porting ADL is not an issue. Has been implemented on many UNIX systems. Internationalization and X/Open has been watching us. Israel: You've just glossed over it. How about DOS or PC/non-UNIX? Alberto: I don't have all the information. However, we are ready for 8 character names. John: What about word sizes? 64 bit? Dick Coulter: Work on a Cray? Work on an Alpha? Alberto: We have worked on many different systems. Haven't tried those, yet. Proposed Schedule: Q1-95 (ADL project steering board: Dallas, March 95) decision < will get slide from Alberto Savoia > Summary: ADL is a joint international research project Want to get some technology for testing Think OpenGL is a great example. Will be a win-win for ADL and OpenGL Best test suite for a graphics standard Jim: Are you looking for cash or engineers? Alberto: Probably would rather have engineers. Technology transfer is a contact sport. HB: Are ADL and X/Open independent? Alberto: They are completely disjoint. There is synergy for both. Tuesday, February 14th afternoon Mike Heck of Template Graphics Software to discuss AGL (Apple GL interface) John: Will this interface be proprietary or like the GLX and controlled by the ARB? Mike: We expect the AGL will be proprietary with Apple. It's being co- developed by Apple and Template Graphics Software. AGL still in development: MAY CHANGE! Partnership was announced last week at Demo '95. It's public knowledge. Template was a provider of 3D since 1981, when part of Megatek. Did PHIGS since 1985, and still sell them. Have PHIGS tools: PSO, FIGraph, FIGt, and now OpenGL We are doing OpenGL for Sun ZX, for any X server, Windows 3.1, PowerMac, Hardcopy/PostScript, and will do custom OpenGL for new hardware. Actually acquired OpenGL for ZX from 3Dlabs and made optimizations for lighting. OpenGL for PowerMac supports: * direct rendering only (screen or memory) * multiple monitors at multiple depths * windows move or span between monitors * user change color depth interactively * integration with Mac desktop Each device (monitor) defined by GDevice (aglChoosePixelFmt) Off-screen pixmap defined by a GWorld (aglCreateAGLPixmap) glX equivalents aglChoosePixelFmt(GDHandle *dev, int ndev, int *attribs) different from wgl and its fixed struct aglCopyContext (AGLContext src, AGLContext dst, GLuint mask) Kurt: might not want to do that. We've been discussing whether it's needed. aglCreateAGLPixmap(AGLPixelFmtID pix, GWorldPtr pixmap) aglCreateContext (AGLPixelFmtID pix, AGLContext shareList) Paula: Do you have to choose a window to be a particular type of pixel format? Mike: No. You have to tie it to a monitor. aglDestroyAGLPixmap (AGLPixmap pix) aglDestroyContext (AGLContext ctx) Jim: Do you need AGL in the Destroy Pixmap? Redundant? Mike: Might be. Have to check. Other functions reviewed: aglGetConfig, aglGetCurrentContext, aglGetCurrentDrawable, aglListPixelFmts, aglMakeCurrent, aglQueryVersion, aglSwapBuffers, aglUpdateCurrent, aglUseFont Linas: Are they like X Visuals? Mike: No, they're more like "Pixel Formats" in WGL. Since it's not a client/server model, it's expensive to keep track of the contents. aglUpdateCurrent says damage has probably occurred, you need to update the resources. Slightly different way of handling fonts. You have a family ID. Code fragment: pxlfmt = aglChoosePixelFmt (NULL, 0, attrs); ctx = aglCreateContext (pxlfmt, 0); aglMakeCurrent (window, ctx); Paula: Might need a query extension. To identify which versions have changes. Mike: That's a valid point. We've ported auxlib, tk, and GLUT. Most of GLUT ported easily, except for timers. Paula: Overlays? Would they be part of pixel format. Mike: Not yet. But that's a good way to implement it in the future. John: What's the relationship with Apple? How is it positioned against their own 3D library? What about a 3rd party who want to use agl? Mike: This is a TGS product, which Apple is cooperatively developing. Apple is not currently planning to sell this as an Apple product, nor participate in the ARB. Both Apple and TGS are interested in feedback. Don't want to answer 2nd question. No absolute answer about a 3rd party who wanted to use AGL, but TGS would like to see one standard interface: AGL. Israel: The WGL and PGL are shipped with the OS. The AGL is not part of the OS. Mike: The goal is to make the interface absolutely available. John: What about the University people creating their own interface. Isn't that an example of fragmenting? For example, GLX is controlled by the ARB. Many people: That wouldn't preclude some university from avoiding GLX. Mike: The intent wasn't to not consider anyone's elses work. We worked with Apple. The university is aware of what we are doing. Desktop integration QuickDraw3D = new Apple software (like both OpenGL and Inventor) immediate mode graphics hierarchical retained graphics API binary and ASCII file formats 3DMF = new Apple desktop data format OpenGL apps will be able to * import 3DMF file " drop" and "paste" of file and data Linas: Is 3DMF legally protected? Mike: I think they would be happy that others would be using it. Mason: Where can you find doc on this? A programming guide? Mike: You should contact the product manager, John Alfano. aglMetafileOpen(char *filename) access 3DMF file on disk aglMetafileBuffer(Handle buffer) access 3DMF data in memory, such as a clipboard Kurt: Can you mix OpenGL and QuickDraw3D in the same window? Mike: Not sure anyone's tried. Phil: Is the Metafile part of a separate library or part of AGL? Mike: Inclination was to put this into a completely different library. Apple does see it as central to the 3D graphics problem (paste). Steve: Make sure we understand it's just paste, not cut and paste. You can't cut the OpenGL object. Mike: want to make it simple API. Handle multiple input sources. Other routines are aglMetafileGetBBox, aglMetafileGetCentroidv, aglMetafileImport, aglMetafileFinish Jim: Are you taking Metafile information and manipulating it or just sending it to QuickDraw3D? Mike: The implementation does make OpenGL calls. It's a real OpenGL program. We know you can bring it bits of geometry, and maybe eventually a complete scene. Steve: Are all OpenGL calls display listable? Mike: Yes, exactly. That's definitely one of the goals. John: Do you have a translation both ways between OpenGL and 3DMF? Mike: Currently, there is no direction from OpenGL to 3DMF. From 3DMF to OpenGL, there are differences, but it isn't too hard. It's harder to do it from Inventor, where there are subtle differences. Some ugly issues with NURBS, because the NURBS implementations are different. We've been able to implement some fairly complex models. John: In summary, you don't anticipate situations where elements are not transformable. Mike: In converting from OpenGL, it'll be near 100% John: Why is it so hard to go to OpenGL? Does that direction have far less importance? Mike: It was a timing issue. It's important to go the other way, for us. Phil: Aren't both ways important? What about rendering to a printer? Mike: You would need to get inside OpenGL and syphon off some of the primitives. GLS is conceptually a solution; converting to 3DMF. Apple would prefer the output to be directly to 3DMF. Israel: Going down to GLS, you lose information. Mike: But you're so low there that you don't lose much. Fred: What's the advantage of having 3DMF over the GL streams calls? Mike: Trying to solve the problem of if there are QuickDraw3D calls, what do we do to transfer data around. Kurt: Would like to see mixed graphics rendering into the same window: QuickDraw3D and OpenGL. Multiple renderers into same window. Mike: QuickDraw (not 3D) coexists well with OpenGL. However, QuickDraw3D and OpenGL coexist about as well as PEX and OpenGL to the same window. Would like a sense of whether all this Metafile stuff belongs to AGL. John: I share Phil Huxley's belief to keep it separate from the AGL. And I'm still concerned about who owns the specification for AGL. This is the first time a 3rd party provider. Dick: Who has the right to modify the spec? Phil: Can the ARB endorse it? discussion ensues about feedback, endorsement, and what that all means. Break GLU (continuation from Monday) John Dennis: wrote up a proposal for modification of GLU for new tesselation without breaking backwards compatibility (from yesterday). This adds a blind data pointer. Typos are spotted by Hock and Paula and fixed above. John's proposal: add these enumerants: GLU_BEGIN_DATA GLU_EDGE_FLAG_DATA GLU_VERTEX_DATA GLU_END_DATA GLU_COMBINE_DATA GLU_ERROR_DATA To allow these new callbacks (note: these routines are user provided) begin_data (GLenum type, void *user_data) vertex_data (void *data, void *user_data) end_data (void *user_data); error_data (GLenum errno, void *user_data) edgeFlag_data (GLboolean flag, void *user_data) combine_data (GLdouble coords[3], void *data[4], GLfloat weight[4], void **outData, void *user_data) Modify these API entry points (add user_data) gluTessBeginPolygon (GLUtesselator *tess, void *user_data) Hock: Could we forbid people from doing mixed (with and without user_data)? Jim: What happens if both a GLU_BEGIN and GLU_BEGIN_DATA were set? Do they conflict? John: I think mixing and matching is potentially useful. Kurt: If both GLU_BEGIN and GLU_BEGIN_DATA are set, then you have two state values. They don't point to the same thing. Israel: Might just have a flag that says GLU_DATA. John: I'm not a big fan of setting modes, but in light of this conversation, it might make sense. Jim: You have problems with the prototypes. Bimal: How about passing a NULL for the last one? Jim: That only works on some compilers. More discussion. John: new proposal: * Only new enumerant is GLU_DATA * two sets of callback prototypes * gluNewTessProperty entry point Dale: Can't mix and match John: I don't think it's a terrible loss. Formal ARB vote: 7-0 passes GLU 1.2, GetTessProperty, etc. Overrides e-mail vote on GLU 1.2 The precedence rules are: * with data * user specified without data * default ------------- Moderated discussion about ADL (Alberto Savoia's presentation) to determine what's next. Brainstorm issues and put into 3 categories: pro, con, and don't know impact and then follow-up directions are summarized Pro * partial implementation with PHIGS * UNISOFT test suite was great for X, fewer errors * help flush FP issues * development optimization tool * if it fell in your lap, it would be great * MITI, bigger co. involvement * OpenGL still new to ISVs * if successful, OpenGL will be the case study * synergy for many companies w/ OpenGL test suites * buys us something for future releases Con * what if they can't do it * costs $500K * 18 months away * lack of support/experience with other architectures, window systems, O/S and 64 bit * combinatorial explosion * s/w only rendering path * differences of images * if user hasn't found bug, is it important? * we're in development cycle now, it may be too late. Don't Know Impact * create X/Open Test Suite * would it supercede conformance? * is 90% coverage the easy 90% * coverage from current tests * might be fundamentally different * feasibility--possibly funding for prototype Alternatives * status quo * X/Open does the work, not individual companies Who's interested? * everyone * 50% want to hear more What next? * have the ADL team try one primitive/area to show results * have them explain how they would go about it * what code is generated * if they do the prototype, companies on the ARB would fund remainder Moderated discussion about X/Open (Mike Lambert's presentation) Pro * "Are you a standard?" With X/Open, answer is clearly yes. * Least painful standard body * European acceptance * US government contracts * marketing/legal/trademark experience * administrative infrastructure Con * some companies not interested/disinterested * $$$ * one more impediment to shipping product * versions between ARB and X/Open can go out of sync * historical small impact on other specs * potential loss of ARB control * timeliness * version numbering * non licensees * Intellectual property rights and copyrights somewhat transferred * working with standards groups can be a lot of work! * once we start the process, getting out will be hard or embarassing * lack of experiences with graphics standards * conformance variances Don't Know Impact * What does it buy us? * How does it apply to non UNIX * WGL, PGL, GLX, AGL differences * Cost to end user? * Momentum building already--would X/Open change things? * Would not doing X/Open hurt OpenGL? * Would Europe or US Govt insist upon X/Open branding? * Would energy be better spent elsewhere? * bug fix versus real releases * ARB conformance vs. X/Open branding--can they be identical? No foreseen Impact * ARB maintains much control * OpenGL is already a standard Alternatives * status quo/control own branding/marketing force * ISO, ANSI, IEEE * NSTL What next? * what are the benefits? * X/Open will probably discuss OpenGL with their shareholder contacts Wednesday, February 15, 1995 < special thanks to Randi Rost for taking down these notes > Topic: OpenGL 1.1 Invention of Process for Developing OpenGL 1.1 ---------------------------------------------- What's being requested? SGI says that extensions to expose high end features and additional imaging capabilities are the most requested things. Development of Specification Identify goals Develop initial feature list Needs evaluation End user solicitatoin Licensee solicitation Proof of concept Any proposed extension must reflect proven extensions Evaluate vendor-specific extensions to see if any qualify as EXT Reevaluation of extensions (EXT, vendor-specific) Evaluation of feature list Produce draft spec Produce final feature list Review and comment period Solicit end user input Deliver final spec Deliver sample implementation Deliver conformance tests Interoperability testing between vendors Brainstormed Goals for OpenGL 1.1 --------------------------------- 1. Create successful process 2. Timeliness (end of calendar year) 3. Create a successful release 4. Enough substance 5. End user acceptance 6. Stability 7. Protect performance 8. Backwards compatible with 1.0 9. Vendor commitment (enough will ship) Potential Feature List for OpenGL 1.1 ------------------------------------- {current suffix}(companies showing interest) [companies that have implemented] vertex array - {EXT} (Everyone) [SI, SGI, Microsoft, DEC, Intergraph] ABGR - {EXT} (E&S, SGI) [SGI] (?) Kurt thought that this extension is a transition thing, and that it was not really the intention to fold it into OpenGL proper. texture object - {EXT} (Intergraph, others) [SGI, Intergraph] blending ops for RGBA: logicop, min/max, sub - {EXT} (Intergraph, others) [SGI] rescale normal - {EXT} (SGI, E&S) [available in IrisGL] (?) Hasn't been implemented polygon offset - {EXT} (SGI, DEC) [SGI] texture extension (defines internal image/texture format) - {EXT} (SGI) [SGI] (?) Anyone interested besides SGI? copy texture - {EXT} (SGI, E&S) [SGI] (?) feature only for high end workstations? subtexture (?) - {EXT} (E&S, SGI) [SGI] (?) feature only for high end workstations? Note: when OpenGL goes to 1.1, GLX goes to 1.2. Potential Feature List for GLX 1.2 ---------------------------------- visual performance token - good/bad/ugly visual info extension transparent pixel extension Procedure for getting something into OpenGL ------------------------------------------- The following process was agreed as the way to pursue getting something added to OpenGL proper: 1. Create vendor specific extension 2. Work with one or more vendors to make it an EXT extension 3. Implement it 4. Propose for next rev. of OpenGL Content of OpenGL 1.1 --------------------- For May 1995 meeting, everyone should come with list of extensions implemented (or a confidence factor that indicates their implementation experience with each of the interesting extensions). After some discussion, the extensions being considered were sorted into the following buckets: High Confidence of Getting Into V1.1 vertex array texture object blending constant color: logicops only rescale normal polygon offset visual performance token (GLX extension) visual info extension (GLX extension) transparent pixel (GLX extension) Low Confidence of Getting Into V1.1 copy texture subtexture No Confidence of Getting Into V1.1 ABGR blending constant color: min/max, add, subtract texture internal SGI will make these extension documents available for public review. Schedule for OpenGL 1.1 ----------------------- Identify goals - Done Develop initial features list - Done Solid feature list - May ARB meeting Vote on inclusion of individual extensions - May ARB meeting Draft specification (inc. conformance) - July Final feature list Internal review period (OpenGL licensees) - July - Aug. Internal review (OpenGL licensees) over - Sept. ARB meeting Public review period - Oct. - Nov. Final spec - Dec. '95 Sample implementation/man pages Conformance tests ------------------------- Topic: choosing date for July-Sept ARB meeting Decided to have after SIGGRAPH September ARB Meeting - Sept. 11-13 at SGI in Mountain View