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.
Marvin
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.
Marvin
As time permits…not complaining, just observing…
Hi,
Lets us try to produce the test case.
The changes I made are easy to revert back in order to chechk which one (if one) caused the regression (it is easy to track by cmments on CVS log).
If you have an example, publish it somehow and I will attend this immediately.
Yuri
My game is way to big at the moment to isolate a test case,
Marvin do you have a simple example??
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.
Marvin
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.
Marvin
Should be fixed now :).
Marvin
Cool…will pull and retets. What was the problem??
Lighting information is stored in each affected Shape’s RenderAtom. This was not correctly handled. Now it is :).
Hi,
Looks like we again have the same problem with flashing objects in Q3 Benchmark. Few days ago the problem gone, but now again it is here. I don’t know after which changes it re-appeared.
Yuri
Where do you see these flashing objects? I’ve never seen them.
Just compare the latest versions of ScenegraphModificationManager.
Marvin
Hi,
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.
Yuri
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.
Marvin
Hi,
After taking a short look at the current implementation renderAtom(…) I got a question:
As of renderAtom(…) code, STATIC_APPEARANCE means static texture coordinates. Maybe it should be called like this?
Yuri
Hi,
OK, I localized the problem - texture unit state was not set in setupTextureUnit(…).
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.
Maybe we have to review the architecture for mutitexture and texture states to eliminate different codepaths for single-textured and multi-textured shapes.
Yuri
Hi,
The fix in CVS is definitely suboptimal. There is a problem with state caching of texture unit states for multitexture. This is still under deep investigation by me.
Yuri
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.
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 :).
That would be cool.
Marvin