David Yazel wrote: > The alpha blending problem for coplanar surfaces is a real weakness.
As Doug has said, this looks like a bug in Java3D. However, I'm going to challenge the basic assumption that you need coplanar surfaces in order to Do It Right. > Our engine can calculate textures for every splat at any desired density, as > well as splat masks for compositing. The problem we are facing is that we > need to generate terrain for a large area, so we can't afford to store that > many high density patch-specific textures. Well we can get close with 6.3 > GB of storage :) So there's nothing particularly unusual about that amount of data. If that was a GIS, it would be classed in the tiny realm. Some GIS's work with Terrabytes of data, so from a purely philosophical perspective, I see nothing special in the above requirements. One situation that I always find disappointing is that game developers don't talk to the simulator developers and vice-versa. Almost all of the techniques are interchangable to some degree. For example, how is an MMPORG covering half a million square kilometers any different to an F/A-18 flight simulator or an Abrahams tank simulator? Both have to cover very large pieces of "earth", every patch must be unique, the user can move about in very quick fashion, and a lot of detail is needed (particularly in the tank sim case). In the simulation world, a lot of the information is dragged directly from some form of GIS. As a general rule, GISs produce basic surface texturing data as an image and the rest as vector plots. For example you wil get back a satellite image of the plot of land and then a collection of vector data describing roads, rivers etc (we're ignoring elevation data). The renderer then has to make something of this. Obviously it can't draw just straight lines in 3D space to represent a road, it has to create something that looks realistic. In a lot of cases that I've seen or read about, these simulators most of the detail work is taken care of by generating textures on the fly. You start with the basic texture such as a 2 lane, centerline road and then tile your own textures as needed. The reason for this was that it is much faster to do it this way because it uses 2D hardware rather than using 3D hardware. 2D hardware was far faster than 3D for these sorts of actions for a long time. In the MMPROG world, I don't see that there needs to be much difference in approach. Instead of coming from a formal GIS package, you have your own propertary system. Moving through the world is just a case of picking up the detail vectors and compositing together as two, maybe 3 textures (basic colour, lightmap, bump map). You should have enough CPU cycles to do these compositing steps on the fly. -- Justin Couch http://www.vlc.com.au/~justin/ Java Architect & Bit Twiddler http://www.yumetech.com/ Author, Java 3D FAQ Maintainer http://www.j3d.org/ ------------------------------------------------------------------- "Humanism is dead. Animals think, feel; so do machines now. Neither man nor woman is the measure of all things. Every organism processes data according to its domain, its environment; you, with all your brains, would be useless in a mouse's universe..." - Greg Bear, Slant ------------------------------------------------------------------- =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA3D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
