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

[Matthew Woehlke]

Ian Wadham wrote:
> On Thu, 15 May 2008 08:17 am, Matthew Woehlke wrote:
>> Ian Wadham wrote:
>>> On Fri, 9 May 2008 12:21 am, Eugene Trounev wrote:
>>> I think it is possible to do a background but I have not read up on the
>>> programming requirements yet.  Also I think the requirements for
>>> the graphics-file format might be a bit limiting, so better not draw
>>> anything yet.
>> I thought Qt allowed you to turn any QPixmap/QImage into an OpenGL texture?
>>
> Yes, but then what?  As I said, I have not read up on this yet, but as far as
> my present understanding goes, a texture has to be a power of 2 pixels
> in each dimension (e.g. 512x1024).

Eh, sure, but that's easy to fix (and a common problem); enlarge as 
needed and fill with junk, and set your coordinates to draw only the 
appropriate part. You can get cropping almost for free this way, also.

> So it gets re-projected, stretched,

Well, yeah, it gets stretched however you set the texture coordinates. 
Usually that's a /plus/ because you can scale and crop and GL does the 
heavy lifting.

> re-computed regarding lighting, etc. depending on the position
> and orientation of the underlying surface in 3-D space.

Ah... no. Normally you disable lighting for the background pass (or wait 
to enable it until you're done with the background). The background 
should not be lit, nor drawn with a perspective transform.

Your pipeline should look like this:

- load 2d matrix, viewport coordinates
- enable texturing
- draw background
- [disable texturing; if not being used for the scene]
- load 3d [perspective] matrix, scene coordinates
- enable lighting, etc
- draw scene
- disable lighting, etc

(You can shuffle around the effect toggle order, e.g. disable before 
drawing background, instead of disabling at the end of the pipe; I'm not 
aware that it makes any difference beyond personal preference.)

> AFAIK there is no concept of a "background" in OpenGL

Not "explicitly", but you get the same result just drawing a big 
textured quad, with z-write disabled, lighting disabled, etc, with a 
projection that maps GL coordinates to viewport coordinates. Then you 
turn back on z-write, lighting, etc. and set your usual scene 
projection. Effectively you start off "pre-filling" the GL buffer with 
the background.

> and certainly no reliance on pixel-based co-ordinates.

Not "reliance", no, but it's trivial to set the projection matrix to one 
that maps GL coordinates 1:1 with viewport coordinates.

> I think a background would have to
> be a rectangle, perpendicular to the Z-axis and some distance behind the
> cubes (which are centred at Z = -5.0).  Its size and position, in OpenGL
> X, Y co-ordinates, would have to be calculated so as to fill the current
> perspective view.  It might then turn out to be too far from the light and
> therefore a bit dim.  Also, when the texture is applied, the artwork might
> get stretched or clipped in undesirable ways and its perspective might
> clash with the perspective in which the cubes are drawn.

Ok, summary...

- Rectangle: yes, obviously.

- Z axis: irrelevant, set up the projection properly.

- X, Y coords: also not a problem; set up the projection properly.

- "some distance behind the cubes": also irrelevant; draw with z-write 
disabled (or clear the z-buffer after; I /think/ disabling z-write 
works, but I /know/ clearing the z-buffer will). All future operations 
will then correctly draw over.

- "too far from light": you probably shouldn't have lighting turned on 
at this stage :-).

- "might get stretched or clipped": well, yeah, you're going to have to 
clip to maintain aspect ratio (true for most or all of our games), and 
you'll have to do a little math to calculate appropriate texture 
coordinates.

- "perspective might clash": well, that's an art problem (unless you go 
to full 3d textures), but I'd think most backgrounds would be simple 
patterns, where being static is ok. Actually as long as the same lens 
length is chosen, even this shouldn't be a problem; it'll just look like 
the cube is floating in space, rotating freely (unless you change lens 
lengths in real time?).

Your problem stems from assuming that you cannot change the projections, 
effects, etc, in the middle of the pipe. Quit that ;-). Swapping out 
projections and effects is SOP (HUD's being the most blatant example).

>  I am sure there will have to be some rules
> or restrictions re the SVG artwork if it is to survive the transformations
> OpenGL might put it through and still look as good as the 2-D work we
> provide in other games.

SVG is nice because you can re-render it to match the actual resolution 
of the window (do it in the background, because GL will give you free 
smooth-scaling until the new version is ready), but that means that once 
the 1:1 size match flavor is ready, all GL is doing transform-wise is a 
hugely glorified bitblt. IOW the only constraints I'd expect are that it 
shouldn't clash with the arbitrarily-rotated cubes.

-- 
Matthew
The time you have spent
Reading this lame signature
Is now lost to you