d3dx9: general direction/goal - speed, code "prettiness", etc?

Misha Koshelev misha680 at gmail.com
Sat Jul 24 11:35:21 CDT 2010

Dear All:

Given my recent work on this bug:

and on D3DXCreateSphere, with the latest iteration being:

I have been giving quite a bit of thought to d3dx9 and to mesh creation
functions in particular.

I have realized there is no "perfect" sphere creation function. Rather,
there are functions that may be optimized for different purposes.

Thus, I thought I'd pose the question - as to d3dx9, is our goal:
a) speed
b) code "prettiness"
c) something else?

I am tempted to think it is (a), but wanted to double check.

For example, I have taken a look, per Henri's suggestion (wrt teapot),
at freeglut 2.6.0 sources. For your reference:
> freeglut is released under the X-Consortium license.

Per http://www.winehq.org/pipermail/wine-devel/2010-July/085266.html, I
believe it is okay to look at this code. In fact, the license looks
strikingly like the one in:
with X Consortium changed to Pawel W. Olstza (?)

In any case, I have taken the liberty of copying and pasting
glutSolidSphere to the top of the attached file. As you can see, it is
implemented in terms of triangle fans and quad strips. (You will notice,
btw, the use of lookup tables - fghCircleTable - for cos and sin, which
reinforces my belief that speed is our top interest in terms of a
graphics library).

Now you will note, my current D3DXCreateSphere patch:

creates unique vertices and indices (creating indices on a per-vertex
basis per Henri's suggestion). I admit, this may not "look" as pretty as
having triangle fans and quad strips.

In fact, of course on possibility is to:
a) create helper functions that make triangle fans and quad strips -
because we are dealing with (unique) vertex buffers and index buffers
for our (triangular) faces, we will need additional floating point
comparison calls in each function to make sure that our vertices are
b) use code a la freeglut to generate our vertex and index buffers

Now this code might be a little "prettier" to look at, but I see some
serious problems with this approach and would appreciate your

Here are some issues:
i) KISS (keep it simple .. umm .. silly) - although not a computer
scientist by formal training, I know well enough that in any system, the
more complex the system, the more opportunities for random behavior. In
other words, bugs. Clearly, this is why we have conformance tests. But
it seems like it would be overkill to have conformance tests for helper
functions, especially helper functions used in a test.
ii) Most importantly - this would add at least three floating point
comparisons per vertex that we add. This may not seem like a lot - until
you start thinking of a sphere with, say, 1000 vertices (not too much
for a spherical-looking sphere), and, say, for a game that generates 100
spheres. This means 100 x 1000 x 3 = 30000 extra floating point
comparisons (which would involve a subtraction and comparison because we
would be comparing to a predefined epsilon - not to mention the eternal
question - which epsilon do we use?)

Now this link is quite old:
but surely Wine is constantly being benchmarked as far as graphics
performance, since I believe one of the big uses of Wine currently is
for games.

Thus, it is reasonable that we do not want to take such a performance

In any case, this is my thought as to why
is a good implementation for a sphere, rather than doing something more
high level.

And, in general, why we probably want to keep doing the vertex
buffer/index buffer approach, and forgo an approach where we:
(a) create non-unique vertices uses nice geometrical structures on the
fly (triangle fans, quad strips)
(b) generate vertex and index buffers from these on the fly.

However, as always, feedback appreciated.

Thank you and have a nice Saturday!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: freeglut_geometry.c
Type: text/x-csrc
Size: 43478 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20100724/160f349c/attachment-0001.c>

More information about the wine-devel mailing list