Dear All:
Given my recent work on this bug: http://bugs.winehq.org/show_bug.cgi?id=22918
and on D3DXCreateSphere, with the latest iteration being: http://www.winehq.org/pipermail/wine-patches/2010-July/091176.html
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: http://source.winehq.org/git/wine.git/?a=blob;f=dlls/gdi32/region.c#l26 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: http://www.winehq.org/pipermail/wine-patches/2010-July/091176.html
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 unique 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 comments/feedback.
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: http://www.phoronix.com/scan.php?page=article&item=wine_feb08_tests&... 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 hit.
In any case, this is my thought as to why http://www.winehq.org/pipermail/wine-patches/2010-July/091176.html 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!
Misha
Dear All:
Given my recent work on this bug: http://bugs.winehq.org/show_bug.cgi?id=22918
and on D3DXCreateSphere, with the latest iteration being: http://www.winehq.org/pipermail/wine-patches/2010-July/091176.html
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: http://source.winehq.org/git/wine.git/?a=blob;f=dlls/gdi32/region.c#l26 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: http://www.winehq.org/pipermail/wine-patches/2010-July/091176.html
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 unique 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 comments/feedback.
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: http://www.phoronix.com/scan.php?page=article&item=wine_feb08_tests&... 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 hit.
In any case, this is my thought as to why http://www.winehq.org/pipermail/wine-patches/2010-July/091176.html 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!
Misha
My apologies this does not seem to be going through with attachment and I cannot upload from my phone. Will send link shortly. Thank you.
Misha
---------- Forwarded message ---------- From: "Misha Koshelev" misha680@gmail.com Date: Jul 24, 2010 11:35 AM Subject: d3dx9: general direction/goal - speed, code "prettiness", etc? To: "wine-devel" wine-devel@winehq.org
Dear All:
Given my recent work on this bug: http://bugs.winehq.org/show_bug.cgi?id=22918
and on D3...
My sincerest apologies. I sent this two hours ago but wine-devel silently rejected apparently because it had an attachment.
I tried to forward from GMail for Android but, as you can see per my prior email, it did not quite work.
I have uploaded the file that was previously attached (freeglut_geometry from freeglut 2.6.0) and it can be found here: http://bugs.winehq.org/attachment.cgi?id=29810
I apologize I was not able to find another way to share this file with you, as online upload services all seem to result in malicious ads. I did not want to simply link you to a tar.bz2 file that you would have to download and extract.
I appreciate all your comments.
Thank you Misha
---------- Forwarded message ---------- From: Misha Koshelev misha680@gmail.com Date: Sat, Jul 24, 2010 at 10:33 AM Subject: d3dx9: general direction/goal - speed, code "prettiness", etc? To: wine-devel wine-devel@winehq.org Cc: Henri Verbeet hverbeet@gmail.com
Dear All:
Given my recent work on this bug: http://bugs.winehq.org/show_bug.cgi?id=22918
and on D3DXCreateSphere, with the latest iteration being: http://www.winehq.org/pipermail/wine-patches/2010-July/091176.html
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: http://source.winehq.org/git/wine.git/?a=blob;f=dlls/gdi32/region.c#l26 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: http://www.winehq.org/pipermail/wine-patches/2010-July/091176.html
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 unique 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 comments/feedback.
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: http://www.phoronix.com/scan.php?page=article&item=wine_feb08_tests&... 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 hit.
In any case, this is my thought as to why http://www.winehq.org/pipermail/wine-patches/2010-July/091176.html 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!
Misha
On 24 July 2010 17:33, Misha Koshelev misha680@gmail.com wrote:
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.
In the general case, maintainability. That includes things like consistency and complexity. That's not to say you shouldn't care about the other points *as well*, but if it comes down to a choice, maintainability will likely win, unless you can prove that something is e.g. a significant bottleneck in some applications.
-
Henri Verbeet -
Misha Koshelev