From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16401 invoked by alias); 4 Jan 2005 19:15:10 -0000 Mailing-List: contact xconq7-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: xconq7-owner@sources.redhat.com Received: (qmail 16354 invoked from network); 4 Jan 2005 19:15:02 -0000 Received: from unknown (HELO edam.execulink.net) (199.166.6.57) by sourceware.org with SMTP; 4 Jan 2005 19:15:02 -0000 Received: from opal.ansuz.sooke.bc.ca (dsl113.rba1.pppoe.execulink.com [66.203.174.114]) by edam.execulink.net (8.11.6/8.11.6) with ESMTP id j04JF1c32530; Tue, 4 Jan 2005 14:15:01 -0500 Date: Tue, 04 Jan 2005 19:15:00 -0000 From: mskala@ansuz.sooke.bc.ca To: Eric McDonald cc: xconq7@sources.redhat.com, xconq-hackers@lists.sourceforge.net Subject: Re: Image handling: update on my status and plans In-Reply-To: <41C52E21.8030407@phy.cmich.edu> Message-ID: References: <41C52E21.8030407@phy.cmich.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2005/txt/msg00018.txt.bz2 On Sun, 19 Dec 2004, Eric McDonald wrote: > that Ed Felten seems to have fueled your competitiveness; I recognize > that name from elsewhere; I think he had something to do with the DeCSS > stuff or maybe a DMCA lawsuit.... He was an expert witness in the Federal Microsoft anti-trust case, and more recently was attacked by the RIAA after leading the team that broke the SDMI Challenge files. > The terrain generator ensures that the all terrain with the 'liquid' > property set has a uniform elevation with all neighboring liquid terrain. I think what triggers the bug is elevation=0 rather than liquid terrain as such, but the way the games are designed means that terrain at elevation 0 normally will be liquid. > As far as the interfaces calling the kernel every time for an image, I > am mostly for it, since this keep things more consistent and take most > of the image-handling burden away from the interfaces. However, if we > ever evolve Xconq into a client-server model, I might be concerned about > traffic in the case of a network game. Of course, the image-handling > part of the "kernel" might be able to be linked into the client apps. I Well, by "kernel" I just meant the code common to all interfaces - it could well be part of the client-side library rather than the kernel kernel that lives on the server. The point is that we shouldn't have to make each change to the "decide what image to show" code in more than one place in the source tree; I think we're on the same page about that. > My thinking has been: > (1) Calculate elevation gradients (slopes) from cell edge to cell edge. That's a bit more complexity than I had in mind - what I was thinking of was simply code that could automatically generate something similar to the current designer-specified isometric images. The way those work is with one image per terrain type. That image is of a three-dimensional chunk of (for instance) mountains, with a hexagonal base but sticking up vertically, probably outside the hex tile boundaries, to express vertical height. When the interface draws it on the screen, it also draws a pedestal underneath it (isometric view of a hexagonal prism) to represent the height of the hex, which is the height of the bottom of the relief shown in the image. One problem with the current approach is that if the view is rotated, the designer-specified image can't be rotated because doing so would require converting the 2D image back to 3D, rotating, and then converting back, and the relief makes that impossible. It would be unpleasant, but theoretically possible, without the relief. The current scheme of NOT rotating isometric terrain images when the view rotates actually looks quite good, but it is visibly a schematic rather than realistic portrayal of terrain. What I was imagining for automatic generation would be that the designer specifies a hexagonal overhead view (they already do), the program renders that into 3D as a flat hexagon, and then if the designer wants relief, they specify a height field which is used to add the relief. There would be just one image, or one image for each of the six view directions, or one or six images multiplied by the number of "variant" images, generated per terrain type - not one per hex. The objective would be to create images similar to the ones that designers are currently specifying by hand. I had not intended that this feature would be combined with the satellite-image feature - in theory it could be, I suppose, but that would be another significant computational load. > It might also be sufficient to just throw down some splines. As long as I think that anything which takes into account per-cell elevation gradients, is best left to the hypothetical future developer of a true-3D interface. -- Matthew Skala mskala@ansuz.sooke.bc.ca Embrace and defend. http://ansuz.sooke.bc.ca/