Re: d3dx9_36 [patch 2/3, resend]: Add tests for D3DXcreateTeapot
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=9720 Your paranoid android. === WINEBUILD (build) === Patch failed to apply
Re: D3DXCreateTeapot
Why not a tea pot pouring into a wine glass then? On Wed, Jul 21, 2010 at 10:12 AM, Peter Urbanec wrote: > On 20/07/10 04:54, Ian Macfarlane wrote: >> >> Following the question as to how to implement D3DXCreateTeapot, might I >> suggest making it in the form of a wine glass? >> >> Given that is unlikely to negatively affect anything (indeed the entire >> method does border on the ridiculous) I think it would make a nice hidden >> touch. > > The geometrical properties of a wine glass and the teapot are sufficiently > different that I would argue against that. For starters, a teapot is not > symmetrical, like a wine glass would be. The handle of the teapot also > creates a topological feature that is not present in a wine glass. > > > >
Re: D3DXCreateTeapot
On 20/07/10 04:54, Ian Macfarlane wrote: Following the question as to how to implement D3DXCreateTeapot, might I suggest making it in the form of a wine glass? Given that is unlikely to negatively affect anything (indeed the entire method does border on the ridiculous) I think it would make a nice hidden touch. The geometrical properties of a wine glass and the teapot are sufficiently different that I would argue against that. For starters, a teapot is not symmetrical, like a wine glass would be. The handle of the teapot also creates a topological feature that is not present in a wine glass.
Re: D3DXCreateTeapot
On 07/20/2010 01:39 PM, Reece Dunn wrote: On 19 July 2010 19:54, Ian Macfarlane wrote: Following the question as to how to implement D3DXCreateTeapot, might I suggest making it in the form of a wine glass? Given that is unlikely to negatively affect anything (indeed the entire method does border on the ridiculous) I think it would make a nice hidden touch. Sounds like a good idea. The DXDiag application could then use this API to render a nice Wine glass :) A 3D Wine glass rotating in the winecfg About tab should be cool but I guess it needs some work. If I were you, I would start with a simple sphere (kind of 3D stub) fixing the bug. Then you could freely work on it and let your imagination soar !
Re: D3DXCreateTeapot
On 19 July 2010 19:54, Ian Macfarlane wrote: > Following the question as to how to implement D3DXCreateTeapot, might I > suggest making it in the form of a wine glass? > > Given that is unlikely to negatively affect anything (indeed the entire > method does border on the ridiculous) I think it would make a nice hidden > touch. Sounds like a good idea. The DXDiag application could then use this API to render a nice Wine glass :). - Reece
Re: D3DXCreateTeapot
On 19 July 2010 19:54, Ian Macfarlane wrote: > Following the question as to how to implement D3DXCreateTeapot, might I > suggest making it in the form of a wine glass? > Given that is unlikely to negatively affect anything (indeed the entire > method does border on the ridiculous) I think it would make a nice hidden > touch. +1 :-D - d.
D3DXCreateTeapot
Following the question as to how to implement D3DXCreateTeapot, might I suggest making it in the form of a wine glass? Given that is unlikely to negatively affect anything (indeed the entire method does border on the ridiculous) I think it would make a nice hidden touch. Regards Ian
Re: D3DXCreateTeapot and reverse engineering?
Thank you. I will take a look at this tomorrow morning. On Jul 18, 2010 8:05 PM, "Jeff Zaroyko" wrote: On Mon, Jul 19, 2010 at 10:48 AM, Misha Koshelev wrote: > I believe the GLMap2f... I don't know if this is entirely necessary for your purpose, but OpenGL has a feedback buffer which can be used to capture vertex data. There's an example here http://www.opengl.org/resources/code/samples/mjktips/Feedback.html Jeff
Re: D3DXCreateTeapot and reverse engineering?
On Mon, Jul 19, 2010 at 10:48 AM, Misha Koshelev wrote: > I believe the GLMap2f functions are actually creating further vertex data... > I could be wrong though. Thx > > Misha I don't know if this is entirely necessary for your purpose, but OpenGL has a feedback buffer which can be used to capture vertex data. There's an example here http://www.opengl.org/resources/code/samples/mjktips/Feedback.html Jeff
Re: D3DXCreateTeapot and reverse engineering?
I believe the GLMap2f functions are actually creating further vertex data... I could be wrong though. Thx Misha On Jul 18, 2010 5:46 PM, "Roderick Colenbrander" wrote: On Sun, Jul 18, 2010 at 11:58 PM, Misha Koshelev wrote: > On Sun, 2010-07-18 at... How raw do you want to have it: http://cgit.freedesktop.org/mesa/mesa/tree/src/glut/glx/glut_teapot.c ? ;) Roderick
Re: D3DXCreateTeapot and reverse engineering?
On Sun, Jul 18, 2010 at 11:58 PM, Misha Koshelev wrote: > On Sun, 2010-07-18 at 14:37 -0700, Dan Kegel wrote: >> IMHO, our criterion is "we only need to implement what apps really need", >> and for the moment, that app probably could live with a stub for >> D3DXCreateTeapot. When we run into a complaint about >> our lousy teapot, we can create a better one. So relax, >> just do a stub, and move on to more important things. >> >> Also, as Roderick says, sucking tables out of Windows is >> not ok, for copyright reasons. > > Very well. I will only devote a very limited amount of time to looking > at the teapot. > > I am currently looking at the GLUT code. They seem to have simplified > this quite a bit compared to Windows data - at which I will not look per > all your comments. > > I do not really know much (anything) about OpenGL but have pulled this > code as a combination from: > http://mindfuck.de-brauwer.be/articles/glut/ > http://www.it.freebsd.org/pub/Unix/NetBSD/NetBSD-current/xsrc/external/mit/MesaGLUT/dist/src/glut/beos/glut_teapot.c > > Any ideas how one could quickly look at the raw vertex buffer data using > OpenGL? > > Thank you > Misha > > How raw do you want to have it: http://cgit.freedesktop.org/mesa/mesa/tree/src/glut/glx/glut_teapot.c ? ;) Roderick
re: D3DXCreateTeapot and reverse engineering?
On Sun, 2010-07-18 at 14:37 -0700, Dan Kegel wrote:
> IMHO, our criterion is "we only need to implement what apps really need",
> and for the moment, that app probably could live with a stub for
> D3DXCreateTeapot. When we run into a complaint about
> our lousy teapot, we can create a better one. So relax,
> just do a stub, and move on to more important things.
>
> Also, as Roderick says, sucking tables out of Windows is
> not ok, for copyright reasons.
Very well. I will only devote a very limited amount of time to looking
at the teapot.
I am currently looking at the GLUT code. They seem to have simplified
this quite a bit compared to Windows data - at which I will not look per
all your comments.
I do not really know much (anything) about OpenGL but have pulled this
code as a combination from:
http://mindfuck.de-brauwer.be/articles/glut/
http://www.it.freebsd.org/pub/Unix/NetBSD/NetBSD-current/xsrc/external/mit/MesaGLUT/dist/src/glut/beos/glut_teapot.c
Any ideas how one could quickly look at the raw vertex buffer data using
OpenGL?
Thank you
Misha
#include
#include
#include
using namespace std;
//#include "glutint.h"
/* Rim, body, lid, and bottom data must be reflected in x and
y; handle and spout data across the y axis only. */
static int patchdata[][16] =
{
/* rim */
{102, 103, 104, 105, 4, 5, 6, 7, 8, 9, 10, 11,
12, 13, 14, 15},
/* body */
{12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23,
24, 25, 26, 27},
{24, 25, 26, 27, 29, 30, 31, 32, 33, 34, 35, 36,
37, 38, 39, 40},
/* lid */
{96, 96, 96, 96, 97, 98, 99, 100, 101, 101, 101,
101, 0, 1, 2, 3,},
{0, 1, 2, 3, 106, 107, 108, 109, 110, 111, 112,
113, 114, 115, 116, 117},
/* bottom */
{118, 118, 118, 118, 124, 122, 119, 121, 123, 126,
125, 120, 40, 39, 38, 37},
/* handle */
{41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52,
53, 54, 55, 56},
{53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64,
28, 65, 66, 67},
/* spout */
{68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79,
80, 81, 82, 83},
{80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91,
92, 93, 94, 95}
};
/* *INDENT-OFF* */
static float cpdata[][3] =
{
{0.2, 0, 2.7}, {0.2, -0.112, 2.7}, {0.112, -0.2, 2.7}, {0,
-0.2, 2.7}, {1.3375, 0, 2.53125}, {1.3375, -0.749, 2.53125},
{0.749, -1.3375, 2.53125}, {0, -1.3375, 2.53125}, {1.4375,
0, 2.53125}, {1.4375, -0.805, 2.53125}, {0.805, -1.4375,
2.53125}, {0, -1.4375, 2.53125}, {1.5, 0, 2.4}, {1.5, -0.84,
2.4}, {0.84, -1.5, 2.4}, {0, -1.5, 2.4}, {1.75, 0, 1.875},
{1.75, -0.98, 1.875}, {0.98, -1.75, 1.875}, {0, -1.75,
1.875}, {2, 0, 1.35}, {2, -1.12, 1.35}, {1.12, -2, 1.35},
{0, -2, 1.35}, {2, 0, 0.9}, {2, -1.12, 0.9}, {1.12, -2,
0.9}, {0, -2, 0.9}, {-2, 0, 0.9}, {2, 0, 0.45}, {2, -1.12,
0.45}, {1.12, -2, 0.45}, {0, -2, 0.45}, {1.5, 0, 0.225},
{1.5, -0.84, 0.225}, {0.84, -1.5, 0.225}, {0, -1.5, 0.225},
{1.5, 0, 0.15}, {1.5, -0.84, 0.15}, {0.84, -1.5, 0.15}, {0,
-1.5, 0.15}, {-1.6, 0, 2.025}, {-1.6, -0.3, 2.025}, {-1.5,
-0.3, 2.25}, {-1.5, 0, 2.25}, {-2.3, 0, 2.025}, {-2.3, -0.3,
2.025}, {-2.5, -0.3, 2.25}, {-2.5, 0, 2.25}, {-2.7, 0,
2.025}, {-2.7, -0.3, 2.025}, {-3, -0.3, 2.25}, {-3, 0,
2.25}, {-2.7, 0, 1.8}, {-2.7, -0.3, 1.8}, {-3, -0.3, 1.8},
{-3, 0, 1.8}, {-2.7, 0, 1.575}, {-2.7, -0.3, 1.575}, {-3,
-0.3, 1.35}, {-3, 0, 1.35}, {-2.5, 0, 1.125}, {-2.5, -0.3,
1.125}, {-2.65, -0.3, 0.9375}, {-2.65, 0, 0.9375}, {-2,
-0.3, 0.9}, {-1.9, -0.3, 0.6}, {-1.9, 0, 0.6}, {1.7, 0,
1.425}, {1.7, -0.66, 1.425}, {1.7, -0.66, 0.6}, {1.7, 0,
0.6}, {2.6, 0, 1.425}, {2.6, -0.66, 1.425}, {3.1, -0.66,
0.825}, {3.1, 0, 0.825}, {2.3, 0, 2.1}, {2.3, -0.25, 2.1},
{2.4, -0.25, 2.025}, {2.4, 0, 2.025}, {2.7, 0, 2.4}, {2.7,
-0.25, 2.4}, {3.3, -0.25, 2.4}, {3.3, 0, 2.4}, {2.8, 0,
2.475}, {2.8, -0.25, 2.475}, {3.525, -0.25, 2.49375},
{3.525, 0, 2.49375}, {2.9, 0, 2.475}, {2.9, -0.15, 2.475},
{3.45, -0.15, 2.5125}, {3.45, 0, 2.5125}, {2.8, 0, 2.4},
{2.8, -0.15, 2.4}, {3.2, -0.15, 2.4}, {3.2, 0, 2.4}, {0, 0,
3.15}, {0.8, 0, 3.15}, {0.8, -0.45, 3.15}, {0.45, -0.8,
3.15}, {0, -0.8, 3.15}, {0, 0, 2.85}, {1.4, 0, 2.4}, {1.4,
-0.784, 2.4}, {0.784, -1.4, 2.4}, {0, -1.4, 2.4}, {0.4, 0,
2.55}, {0.4, -0.224, 2.55}, {0.224, -0.4, 2.55}, {0, -0.4,
2.55}, {1.3, 0, 2.55}, {1.3, -0.728, 2.55}, {0.728, -1.3,
2.55}, {0, -1.3, 2.55}, {1.3, 0, 2.4}, {1.3, -0.728, 2.4},
{0.728, -1.3, 2.4}, {0, -1.3, 2.4}, {0, 0, 0}, {1.425,
-0.798, 0}, {1.5, 0, 0.075}, {1.425, 0, 0}, {0.798, -1.425,
0}, {0, -1.5, 0.075}, {0, -1.425, 0}, {1.5, -0.84, 0.075},
{0.84, -1.5, 0.075}
};
static float tex[2][2][2] =
{
{ {0, 0},
{1, 0}},
{ {0, 1},
{1, 1}}
};
/* *INDENT-ON* */
static void
teapot(GLint grid, GLdouble scale, GLenum type)
{
float p[4][4][3], q[4][4][3], r[4][4][3], s[4][4][3];
long i, j, k, l;
glPushAtt
Re: D3DXCreateTeapot and reverse engineering?
On 18 July 2010 22:37, Dan Kegel wrote: > IMHO, our criterion is "we only need to implement what apps really need", > and for the moment, that app probably could live with a stub for > D3DXCreateTeapot. When we run into a complaint about > our lousy teapot, we can create a better one. So relax, > just do a stub, and move on to more important things. That teapot looks a lot like a ball/sphere :)! - Reece
re: D3DXCreateTeapot and reverse engineering?
IMHO, our criterion is "we only need to implement what apps really need", and for the moment, that app probably could live with a stub for D3DXCreateTeapot. When we run into a complaint about our lousy teapot, we can create a better one. So relax, just do a stub, and move on to more important things. Also, as Roderick says, sucking tables out of Windows is not ok, for copyright reasons.
Re: D3DXCreateTeapot and reverse engineering?
On 18 July 2010 21:56, Roderick Colenbrander wrote: > Others have mentioned before that the only 'reverse' engineering > method we allow is black box reverse engineering. Technically this is > black box, but I would say that you can't use the output because of > copyright reasons. In the US, a public domain dataset cannot be made copyright by a machine transformation, per Bridgeman v. Corel. Wikimedia has dealt with this one extensively - running the data through a Microsoft machine transformation absolutely does not establish a new copyright. This is established law. In other countries, it is less certain. However, approximately no-one is willing to risk their asserted copyrights trying it out. The last one Wikimedia had was the National Portrait Gallery making legal threats, and merely making the threat got them pretty much ostracised by the museum and academic community and Wikimedia are about the only people still on speaking terms with them, 'cos we love everybody and approached their foolish legal aggression as an error ;-) - d.
Re: D3DXCreateTeapot and reverse engineering?
On Sun, Jul 18, 2010 at 11:05 AM, Misha Koshelev wrote: > Dear All: > > I just wanted to double check before I do anything with > D3DXCreateTeapot. > > I have several options for implementing this: > > Option A > > One, the slightly harder option, involves the original dataset: > http://www.sjbaker.org/teapot/teaset.tgz > > Option B > > Another, much simpler method, would be to: > a) Call D3DXCreateTeapot > b) D3DXCreateTeapot returns a vertex and index buffer > c) I can easily use these to create a header file that _exactly_ > reproduces the vertices and indices created by Windows. > > My question: is Option B allowed, and if not, why not? > > Thank you > Misha > Others have mentioned before that the only 'reverse' engineering method we allow is black box reverse engineering. Technically this is black box, but I would say that you can't use the output because of copyright reasons. I think we are entering some gray area. It might be good to get some answers, here some examples: - Lets say Wine lacks a font e.g. 'Arial' which we need for some reason. Are we allowed to let Window render text in this font and read back the glyph data? - Lets say Wine had ugly icons in the common dialogs. We could probably create some test to draw a file open dialog on Windows and read back icons. Is this fine? - Lets say MS decided to make the default background color of a window 'pink'. Would we be allowed to use this exact same color of pink (you could make a screenshot, write a test or whatever)? I would say the answer to the first two questions is 'No' for certain because of copyrights. I'm not sure about the last one but I guess it is fine because right now we use the same colors as Windows, Where do we have to draw the line? Personally I would go for option A. Do applications really need the exact data? I remember the teapot in some d3d SDK examples (I believe at least in some teapot cubemap one) and one or more demos at codesampler.com. Apparently some game mentioned in the book needs it (I guess it is a joke from the programmers who seriously uses this call), typically it are only demos which use it. BTW glut should have the teapot as well, if it is under a usable license and it is easier to use, consider using it. Even if going for A, I'm not sure how Alexandre wants to have it implemented. A few kilobyte of static data isn't fun. If there was a way to express it in a number of equations, that might be better but you would have to ask him. Roderick
D3DXCreateTeapot and reverse engineering?
Dear All: I just wanted to double check before I do anything with D3DXCreateTeapot. I have several options for implementing this: Option A One, the slightly harder option, involves the original dataset: http://www.sjbaker.org/teapot/teaset.tgz Option B Another, much simpler method, would be to: a) Call D3DXCreateTeapot b) D3DXCreateTeapot returns a vertex and index buffer c) I can easily use these to create a header file that _exactly_ reproduces the vertices and indices created by Windows. My question: is Option B allowed, and if not, why not? Thank you Misha p.s. This is for this bug: http://bugs.winehq.org/show_bug.cgi?id=22918
