Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (534)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Scenegraph regression.  (Read 4328 times)
0 Members and 1 Guest are viewing this topic.
Offline hawkwind

Junior Member




Java games rock!


« Posted 2006-10-25 23:21:18 »

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. Tongue
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #1 - Posted 2006-10-25 23:48:32 »

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. Tongue

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

Marvin
Offline hawkwind

Junior Member




Java games rock!


« Reply #2 - Posted 2006-10-26 00:13:09 »

Sometime between the 17th and yesterday.  I posted a Frame close question then and am pretty sure it all worked then
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #3 - Posted 2006-10-26 00:20:19 »

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
Offline hawkwind

Junior Member




Java games rock!


« Reply #4 - Posted 2006-10-26 00:21:53 »

As time permits...not complaining, just observing...
Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #5 - Posted 2006-10-26 01:22:34 »

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

Yuri Vl. Gushchin
JProof Group
Offline hawkwind

Junior Member




Java games rock!


« Reply #6 - Posted 2006-10-26 04:29:23 »

My game is way to big at the moment to isolate a test case,

Quote

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 do you have a simple example??
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #7 - Posted 2006-10-26 12:23:13 »

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.

Marvin
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #8 - Posted 2006-10-26 22:48:28 »

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.

Marvin
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #9 - Posted 2006-10-26 22:56:46 »

I'm now working on a fix.

Should be fixed now Smiley.

Marvin
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline hawkwind

Junior Member




Java games rock!


« Reply #10 - Posted 2006-10-27 04:46:23 »

Cool...will pull and retets.  What was the problem??
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #11 - Posted 2006-10-27 15:24:02 »

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 Smiley.
Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #12 - Posted 2006-10-28 14:29:28 »

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


Yuri Vl. Gushchin
JProof Group
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #13 - Posted 2006-10-28 15:39:52 »

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.

Where do you see these flashing objects? I've never seen them.

Just compare the latest versions of ScenegraphModificationManager.

Marvin
Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #14 - Posted 2006-10-28 16:03:59 »

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

Yuri Vl. Gushchin
JProof Group
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #15 - Posted 2006-10-28 16:07:39 »

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.

Marvin
Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #16 - Posted 2006-10-28 17:20:08 »

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

Yuri Vl. Gushchin
JProof Group
Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #17 - Posted 2006-10-28 17:30:34 »

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

Yuri Vl. Gushchin
JProof Group
Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #18 - Posted 2006-10-28 19:26:05 »

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

Yuri Vl. Gushchin
JProof Group
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #19 - Posted 2006-10-28 19:30:31 »

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 Smiley.

Maybe we have to review the architecture for mutitexture and texture states to eliminate different codepaths for single-textured and multi-textured shapes.

That would be cool.

Marvin
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #20 - Posted 2006-10-28 19:32:34 »

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.

Maybe state caching is less performance boosting, if the shaders are in a Display List. Maybe the advantage of Display Lists is worth more than the state cache can do. But I don't know...

Marvin
Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #21 - Posted 2006-10-28 22:58:26 »

Hi,

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.

Yuri

Yuri Vl. Gushchin
JProof Group
Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #22 - Posted 2006-10-29 03:48:25 »

Hi,

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.

Yuri

Yuri Vl. Gushchin
JProof Group
Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #23 - Posted 2006-10-29 12:42:15 »

Hi,

Fix committed to CVS.

Yuri

Yuri Vl. Gushchin
JProof Group
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

pw (35 views)
2014-07-24 01:59:36

Riven (33 views)
2014-07-23 21:16:32

Riven (21 views)
2014-07-23 21:07:15

Riven (24 views)
2014-07-23 20:56:16

ctomni231 (55 views)
2014-07-18 06:55:21

Zero Volt (47 views)
2014-07-17 23:47:54

danieldean (38 views)
2014-07-17 23:41:23

MustardPeter (43 views)
2014-07-16 23:30:00

Cero (59 views)
2014-07-16 00:42:17

Riven (56 views)
2014-07-14 18:02:53
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!