I notice in the most recent CVS pull, as of last night , that the rendering of lights in the scenegraph is incorrect. In my game I make extensive use of adding/removing lights, and turn them on/off via mouse presses. This worked until the most recent CVS pull. I would guess this is due to the modifications make to the rendering system, perhaps adding a light is no longer recognized as changing the scene...don't know. This has died recently, in the last few days.

I notice in the most recent CVS pull, as of last night , that the rendering of lights in the scenegraph is incorrect. In my game I make extensive use of adding/removing lights, and turn them on/off via mouse presses. This worked until the most recent CVS pull. I would guess this is due to the modifications make to the rendering system, perhaps adding a light is no longer recognized as changing the scene...don't know. This has died recently, in the last few days.

I'll check it. But I suppose you didn't checkout several days. This can't be destroyed last night.

Sometime between the 17th and yesterday. I posted a Frame close question then and am pretty sure it all worked then

Now I see it, too. Must have something to do with Yuri's last changes (no offense). It just aggravated some effects, that previously were there. I promise, I'll search for a solution.

Sorry, I put this into the wrong thread. The "HUD regression" thread was the right one.

No, I don't have a good example, but I'll build up one. I do know, why removed lights don't get really removed. I forgot to handle them in AtomsRemover. Maybe speacial support must be done in ScenegraphModificationManager.onChildRemovedFromGroup() / .onChildAddedToGroup(). But this definitely is at least one reason.

No, I don't have a good example, but I'll build up one. I do know, why removed lights don't get really removed. I forgot to handle them in AtomsRemover. Maybe speacial support must be done in ScenegraphModificationManager.onChildRemovedFromGroup() / .onChildAddedToGroup(). But this definitely is at least one reason.

I've created and committed an example, that demonstrates the Lights problem. It is org.xith3d.test.lighting.DynamicLightsTest. I'm now working on a fix.

Take a look at the screenshots: S1.jpg is how it is looking in most cases; S2.jpg is how the same object looks after moving camera a bit (rotate right).S1.jpg is how it should look (and as it looks most of time), S2.jpg shows it is much brighter and no shadow.

I checked already that it has nothing to do with Color, Transparency and Lighting. My guess for a moment that something is wrong with Multitexturing.

Take a look at the screenshots: S1.jpg is how it is looking in most cases; S2.jpg is how the same object looks after moving camera a bit (rotate right).S1.jpg is how it should look (and as it looks most of time), S2.jpg shows it is much brighter and no shadow.

I checked already that it has nothing to do with Color, Transparency and Lighting. My guess for a moment that something is wrong with Multitexturing.

I guess I do know the reason. I didn't know that multitextureing is used in Q3Test. Display Lists are not yet correctly implemented for multi texturing. I simply didn't find the time to do it. Take a look at ShapeAtomPeer.renderAtom(), and you'll see certainly see it.

As of renderAtom(...) code, STATIC_APPEARANCE means static texture coordinates. Maybe it should be called like this?

STATIC_APPEARNCE was meant to be real static Appearance. I was recently trying to put all the Shader calls into the Display List, which wasn't working as I expected because of Shader state cache. I talked about it recently.

I guess having all the Shaders out of the Display Lists is the most important disadvantage of Xith compared to JME. renanse sayed, that on newer GPUs, JME is even faster compared to Xith, which is certainly due to this.

So STATIC_APPEARNCE should be kept naming like it is and Shaders need to be pushed into Display Lists as far as possible.

Sorry, but I had to make setTextureState method in TextureShaderPeer no-modifier - otherwise there will be no access from ShapeAtomPeer. Otherwise we had to make it public, which is even worser.

I only sayed I don't like no-modifyer methods. But they have their right to be there unfortunately. It would be better if Sun introduced a new modifyer for this behaviour. But as far as there isn't one, we will sometimes need no-modifyer. But if it is possible, that the specific method is needed to be visible in a subclass, than "protected" is always better.

btw. I would prefer no-modifyer to be equivalent with "private". I guess most people think it actually is, which is of course wrong .

We can easily experiment with disabling the state caching. There is only one method affected, so we can try to build complete appearance in display list.

On the other hand, I believe that higher efficiency of jME is in different area than display lists. For complicated scenegraphs numerous display lists may become an issue - it is even highlighted in some application notes for VBO extension.

BTW, I am still checking what is wrong with multitexture. Currently implemented architecture seem to be correct, but due to some reason it does not set up proper texture states if only one of textures changed.

After really long and complicated debugging I finally found a REAL reason for object flashing in Q3 Benchmark. It was... attempt to access texture unit states higher than allowed by OpenG: implementation. This means that for cards that support >= 4 texture unit states for multitexturing, the problem did not appear, but other implementations are silently clamping texture unit state number to maximum allowed if it is too big.

This caused highest texture to be turned off after the core was trying to switch off non-existing not-used texture (states 2 and 3 in case of Q3 Benchmark).

To fix this, stricter checks against implementation limitations added. I will commit the fix after removing all debugging stuff.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org