• Home
Name Date Size #Lines LOC

..--

IBM_cull_vertex.txtD12-May-20244.6 KiB13791

IBM_multimode_draw_arrays.txtD12-May-20246.1 KiB194131

IBM_rasterpos_clip.txtD12-May-20243 KiB11267

IBM_static_data.txtD12-May-20244.1 KiB13789

IBM_texture_mirrored_repeat.txtD12-May-20243.4 KiB12877

IBM_vertex_array_lists.txtD12-May-20248.7 KiB250178

README.txtD12-May-20242.7 KiB7656

README.txt

1    Intel's static_vertex_array and vertex_array_set specifications are
2    proposals for new functionality in OpenGL 1.2 or beyond. They are not
3    current implemented by anyone that we know of (although SGI supports
4    compiled_vertex_array, which is very close to static_vertex_array).
5
6    There are two proposed versions of vertex_array_set, one of which names
7    the set with integers, the other (in vertex_array_set.alt.spec) with
8    pointers.
9
10    Jon Leech
11
12-------------------------------------------
13Comments from Bimal Poddar of Intel follow:
14-------------------------------------------
15
16I have created this extension only for the purpose of inclusion
17in OpenGL 1.2. If it does not go in OpenGL 1.2, this does not
18exist.
19
20Firstly, everybody had a problem with the compiled_vertex_array
21name. Hence, I renamed it to static_vertex_array.spec.
22
23Secondly, keeping in mind that the goal is to get this extension
24into OpenGL 1.2 irrespective of VertexArraySet, I have made minor
25tweaks to the original extension. One tweak is to disallow the
26change of array pointers and enables. This is consistent with
27what we talked about at the ARB meeting. The second tweak is
28to remove the "first" since there seemed to be a consensus to
29do that.
30
31If VertexArraySet does get into OpenGL 1.2, then it might be nice
32to have LockArraysExt and UnlockArraysExt accept the ArraySet name
33as input parameters. But the whole package works with or without
34that change.
35
36Finally, another point to ponder - it was clear at the ARB meeting
37that this extension did not serve the purpose of explicity signaling
38to the implementation that it should go ahead and pre-compute a
39range of indices. I have a radical thought here. I would suggest
40eliminating DrawElementsRange and instead use the following commands:
41
42	  DefineElementRange (first, count)
43	  UndefineElementRange (void)
44
45This would not only serve Drew's purpose of providing an explicit
46hint about requesting the geometry pipeline to pre-compute the
47data, but it would also add the range element functionality with
48a very good potential of reuse across multiple DrawElement()
49calls. The anticipated usage of these would be:
50
51	DefineElementRange (first, count);
52	   DrawElements();
53	   DrawElements();
54	   DrawElements();
55	   DrawElements();
56	UndefineElementRange ();
57
58I am hoping that somebody creative out there could come up with a
59better name than Define/Undefine.
60
61To summarize, if you have problems/ideas with the following list,
62please let me know as soon as possible:
63
641. Restriction on not allowing pointer change and enable change for
65   vertex array state within lock/unlock.
66
672. Elimination of "first".
68
693. Should Lock/Unlock take the VertexArraySet name?
70
714. Point to ponder about DefineElementRange.
72
73Thanks
74
75Bimal
76