[Kde-games-devel] Ksudoku, Kubrik 3D background

[Matthew Woehlke]

Ian Wadham wrote:
> On Wed, 18 Jun 2008 10:23 am, Matthew Woehlke wrote:
>> That sounded too much like a challenge to pass up.
>>
> No challenge or contest was intended ... :-)

"Challenge" as in, I knew it should work, and so felt the need to figure 
out how to make it work :-).

> If you want a *real* challenge, how about the 4D and 5D cube? ;-)

Eheheh... :-)

>> My 2D GL-fu must 
>> still be good; the attached patch took about 30-40 minutes, of which I
>> got the background quad rendering in a few minutes and spent most of it
>> figuring out that I needed the line 'glShadeModel (GL_SMOOTH);' to make
>> it shade as I wanted. (Say, can we keep this as one of the options? I
>> like the colors quite a bit ;-).)
>>
> Eugene and I are considering a fixed background picture for KDE 4.1.
> Graphics themes, including your background option (i.e. a multi-way
> color gradient), are a possibility for Kubrick in KDE 4.2.

That's fine, there's all sorts of GUI you'd have to do to get it right 
anyway, so no rush. It's just that it's so pretty (well, I think so 
anyway ;-) ) I thought it'd be a shame if it only ever sees the light of 
day in this hacked-up patch :-).

>> The steps aren't quite the same order, but this should give you an idea
>> what is needed. I'm guessing you missed one of them (I'd be curious
>> which one).
>
> Now here is a strange thing.  gluOrtho2D has params left, right, bottom,
> top, in that order, and you are writing gluOrtho2D (0.0, 1.0, 1.0, 0.0),
> which works.  But should not 0.0 be the bottom and 1.0 the top in OpenGL
> co-ordinates?  I was writing gluOrtho2D (0.0, width, 0.0, height).

Why? ;-) I prefer "screen" coordinates, with Y increasing downward, so I 
set the matrix that way. (Effectively you're setting up a Y-mirror 
transform. No reason it shouldn't work ;-), and of course, it *does* 
work just fine.)

I was thinking about the coords; width, height is fine if you want to 
have to feed the vertex coordinates that way. Personally, I might 
arrange so that the vertex coordinates are always 0.0 and 1.0 with 
appropriate texture coordinates, and set the view coordinates to crop 
appropriately. But that's really your choice. (I do, as you noticed, 
have a preference for 2D projections having Y increase downward, since 
that's how I'm used to thinking about screen coordinates. 2D = Y-down, 
3D = Z-up+Y-back.)

> If I change your code to read gluOrtho2D (0.0, 1.0, 0.0, 1.0), it gives the
> same problem as I had before - no background is drawn.
> 
> What is going on?  Will the real gluOrtho2D please stand up?

D'oh! I see the problem now; that's even more subtle and trivial than I 
thought. Try reversing your winding order on the quad :-D. I'll also bet 
(can't check now, my GL went from only working in software to not 
working at all) that mine "stops working" if you reverse the winding order.

In fact, since I see you used 'glEnable (GL_CULL_FACE)', I'm pretty sure 
about that. GL_CULL_FACE isn't a problem (you can, and probably should, 
leave it enabled), just wind the vertices the right way :-).

And on that note, you can and should ignore that I changed the param for 
glColorMaterial from FRONT to FRONT_AND_BACK; that's a useless change 
with backface culling enabled. IIRC that was something I tried when it 
was giving me a solid color, before figuring out I needed to set the 
shade mode to SMOOTH.

> P.S. I seem to have read somewhere that "Arthur the Paint Engine"
> is based on OpenGL.  Hence my earlier thoughts about QPainter.
> Maybe Qt is reversing the OpenGL Y-axis, to make it follow the
> QPainter convention (zero at the top).

Could be... that's what I'm doing, as you noticed.

-- 
Matthew
I have super powers. I break most everything I touch. -- Allen Winter