Justin. I've been also having problems with textured background. Sometimes, the texture simply disappeared drawing only a white background. contrary to your example, i had no dynamic thingy, it was just a background with a texture. Also, the mapping modes of the objects that were in front of the background could change the way the background was mapped. (changing colours) I think it's related to your bug. if not, there's something else going on. Kelvin, you already have the program, it's the one i sent you many times at least one month ago about wakeup criterion and refresh cap.
Here are thoughts from the top of my head. I might (and will certainly) write things that will make me ashamed, but anyway, starting a reflexion is important. Here is what i can think of my case, and that might apply for yours, Justin. As far as i understand, background nodes are drawn first, then zbuffer is cleared to infinite, and the process starts again for other nodes. As background is rendered first, it can not be perturbed by the objects that are rendered on top of it. But it can eventually be perturbed by something done in previous frame, that would not be cleared correctly. Something like an init that would be different from normal render background render and would forget to clear some bits... By the way, here is the correct URL to access your zip... :) http://www.vlc.com.au/~justin/mt_bug.zip At 07/03/2003 20:18:00, you wrote: >I'm seeking a little help from the more advanced J3D users to help track >down and isolate some bugs I've been having with both Multitexture and >cubic environment mapping. I've already sent the details off to Kelvin >and I have a bug Id (4829458) for it, but the bug report is quite >nebulous, so I'm hoping with a number of people poking at it, we'll be >able to help the J3D team narrow down the exact problem much sooner. >They're going through testing for 1.3.1 final release right now so the >quicker we can track this down, the more likely we'll get a fix for that >release (remember that the next release after is supposed to be 1.4 and >that is some very major architectural changes, so will be a long way off) > >Here's a bit of a clip from what I sent them: > >The best way of describing it is that multitexture just fails to apply >one or more stages at semi random times. In addition, it gets textures >completely messed up. Texture IDs get screwed up because background >textures will get swapped with the mutltexture or the environment >mapping texture gets out of whack. The problem seems to be related to >the dynamic way that we create and work with the multitexture setup. All >of our usage builds the stages on the fly and does a lot of dynamic >manipulation of them (for example turning on and off stages). > >The demo code can be downloaded here: > >http://www.vlc.com.au/~justin/mt_bugs.zip > >The demo program contains a background (cube geometry), a object with >multitexture, and one of the multitexture stages is using a cubic >environment map. The last is unnecessary for the demo, but it also shows >another bug we're experiencing. > >The demo consists of a heap of images for the textures, the Java source >for the demo program and a copy of the current j3d.org JAR file. This >last is mainly used for texture loading and navigation. > >After compiling the source, run it in the same directory as the images. > >The first thing you should see is a single polygon in front of you with >a white background textured geometry behind it. Everything is turned on >at this point, so by rights you should be seeing the reflected text, a >bump map, stencil map and light map all applied to the polygon. > >This is the first bug - the cubic environment map does not show up. Even >using normal map, you can't see the actual text that should be there. > >To make the text turn up, click on the Reflection Mapping radio button >on the right. Now you will see the text turn up - mainly black with a >purple outline. > >Now click back on the Normal Mapping radio button. Notice that the text >does not change at all. It is failing to pick up the change of mode. So >that's bug number 2. > >With the bottom set of controls, start clicking on and off the textures. >After about 20 or so changes, things start disappearing. On random runs, >the complete background texture disappears to be replaced by grey >garbage. Other times the whole polygon stops rendering or you start >getting garbage textures displayed. The stencil map stops working and >the whole lot disappears or just turns completely black. Other times I >can turn off the bump mapping and the whole object goes black, rather >than blue-ish (base colour set to blue) tint that should be expected. >Trying to track down what is really going on is close to impossible. >We've spent probably two months now on and off trying to develop test >cases, but we can't accurately work it out. > >The problems are made worse when you combine the environment mapping >with the multitexture code. We separately have the MT code running in >Xj3D and it displays some of the similar problems (fails to >detect/forgets about the usage of one or more MT units or just gets very >confused). > >We're running only the OpenGL version of J3D, but have seen the bugs on >both nVidia and ATI hardware. Also, have been using Win2K/XP and both >show it too. Given all this, I'm very confident that there's a problem >in the Java3D code, not the video drivers because similar code using raw >OpenGL does not show these issues. > >-- >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". > =========================================================================== 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".
