2 suggestions(maybe not practical): (1): leave those holes, have your background color looks like sea
(2): write a program to find all those vertices lying on the sea(this is easy), try to re-construct the sea using all those vertices you found(is it possible? I am not qutie sure) white On Wed, 3 Jul 2002 10:15:41 +0200, Roger Berggren <[EMAIL PROTECTED]> wrote: >Hi Roy, > >I have thought about a similiar problem and I'm wondering >if one solution is to move the earth surface a short distance >away from the water sphere. > >I know this means you have to traverse and modify all your >coordinates for the earth surface, but this will not take that >much time even with large datasets (500 000+ coordinates). > >If you do not think that this is a solution could you please >explain why. > >Roy Duffy wrote: > >>We have been running into a problem in Java3D for over a year now, and >>we are looking for a better solution to the problem than we are >>currently using. The >>problem is this: we have a database of polygons that make up the >>earth's surface, but just for land, not for the oceans. There is no >>easy way using the data to >>separate out the coastline, so we can't really generate the water >>ourselves. >> >>So, what we want to do is render a high-resolution blue sphere, and then >>render the land on top of the sphere. The two parts are coplanar (there >>is no >>elevation data in our dataset), so we clearly need to do something to >>get around the Z-fighting problem. We have tried a variety of things, >>but none of them >>seem to work: >> >> 1.The correct solution would be to use a DecalGroup (since that is >>what it was created for in the first place!!!) Unfortunately, there is >>a known bug in >> Java3D (BugId 4476109) that messes up the depth buffer when using a >>DecalGroup on Nvidia cards. We >> submitted this bug report a year ago, and it has not yet been >>resolved. >> 2.Our second attempt was to use an OrderedGroup instead of a >>DecalGroup, setting setDepthBufferEnable(false) and >> setDepthBufferWriteEnable(false). This had the exact same problem >>as the DecalGroup attempt. >> 3.The third attempt was to use the polygonOffset to try to bump the >>Z-buffer value of the land to prevent Z-fighting. This was CLOSE to >>working, but >> there was still Z-fighting in certain spots. And besides, the >>Java3D archives are full of messages saying "be careful with >>polygonOffset. It works >> differently on different graphics cards" >> 4.The only way we were able to get it working (and I use that term >>loosely) is to set a transparency attribute on EVERY object in the >>scene. So, we are >> effectively disabling the depth buffer and rendering every object >>using alpha blending. Which means that you have some objects rendered >>in front of >> other objects even though they should be behind them, and even the >>objects themselves are sometimes drawn backwards, with parts of the >>object >> incorrectly in front of other parts. >> >>So, what I'm looking for is (a) a brilliant solution to the problem, (b) >>a kludgy solution that works better than what we have, or at least (c) a >>better feel for >>when (and more importantly, IF) the bug mentioned above will ever be >>fixed. >> >>Thanks, >> -Roy Duffy >>[EMAIL PROTECTED] >> >>=========================================================================== >>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". >> >> >> > > ========================================================================== >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". =========================================================================== 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".
