There're some things able to be further optimized and some changes I'm not currently being notified of when they change. And dor some strange reason, all shapes disappear in the Q3 level, when I move the mouse. But the CameraFlight works and I got a 22% boost, which is not too bad, but I really expected more. Well... maybe I find more things to optimize tomorrow .

I've also run the Bleeding_BlendingTest and it works . The upper place stays transparent all the time. Maybe this problem is solved by accident, because I have no idea why it is solved . I'll commit my changes, when everything works fine again.

I totally agree with Marvin! Transparency problems like one demonstrated in Bleeding_BlendigTest existed at least for a year or even more!!!, I can garantee that.

What about render bins - they were always properly ordered till some very recent changes (I belive when you, Marvin was optimising staff with bins, bins by mistake got swapped), this had happen just back one-two weeks ago. Yes, this totaly destroyed transparencies . Again I can confirm that too. But when renanse fixed it, things got back to "normal", still with those problem like with Bleeding_BlendingTest happening.

And only now, that BlendingTest start working properly! It was simple test case, and it doesn't meen yet that the the problem is really fixed, but I hope so of course. I will check other problems (of the same nature) I had and see if it is sorted now, if it is - well, Marvin, I don't know how - but you did a miracle somehow!!!

What about render bins - they were always properly ordered till some very recent changes (I belive when you, Marvin was optimising staff with bins, bins by mistake got swapped), this had happen just back one-two weeks ago. Yes, this totaly destroyed transparencies .

And only now, that BlendingTest start working properly! It was simple test case, and it doesn't meen yet that the the problem is really fixed, but I hope so of course. I will check other problems (of the same nature) I had and see if it is sorted now, if it is - well, Marvin, I don't know how - but you did a miracle somehow!!!

Is it actually working? Did you test it? I didn't know if it is working on my current code state, which I haven't committed or on the one already committed. If it is, then I suspect, that the following changes did the trick:I changed the RenderBin implementation the the way, that the RenderAtoms are not put into an array anymore but are chained like a linked list. This is moch more efficient, if one wants to remove a Node from the list and Nodes can be easily added. Then I had to replace the sorting algorithm (Quicksort added by lilian I think) with a mergesort, which works even faster in worst case (all three cases, bast, average and worst case O(n * log(n)) ), when it's run on linked lists like in our case. qicksort has a worse worst case behaviour. and we're not wasting any memory neither by the sorting algorithm nor by the renderbin itself.

So I suspect the Quicksort did anything wrong, which the mergesort does correctly. Don't know. But I think, this will have solved it.

And only now, that BlendingTest start working properly! It was simple test case, and it doesn't meen yet that the the problem is really fixed, but I hope so of course. I will check other problems (of the same nature) I had and see if it is sorted now, if it is - well, Marvin, I don't know how - but you did a miracle somehow!!!

Is it actually working? Did you test it? I didn't know if it is working on my current code state, which I haven't committed or on the one already committed.

No-no, I didn't tested it yet myself!!! But you said in you first post you did and it worked for you!

So I suspect the Quicksort did anything wrong, which the mergesort does correctly. Don't know. But I think, this will have solved it.

I believe you are right. It was more or the less obvious anyhow that the problem is with the sorting the transparencies. And I guess (well, basing on changes you said you did) QuickSort was not properly sorting transparencies from back-to-front!!!! That's it!!!

Thanks Marvin for finding that! I believe many people will confirm that it was long term headacke with the transparancies!!!

@lilian: can you have a look at it and confirm? It was good algorithm, anyhow, and with the little fix it may become needed at some stage again.. It really worth fixing... Sorry

Bohdan.

Edit: I said: "QuickSort was not properly sorting transparencies from back-to-front!!!!"I really meant to say: "QuickSort was not properly sorting!!!!"

It just seems I was wrong before saying that test case worked, I discovered that it is working anyhow since I have set sorting for transparencies NONE when was playing with it (and forget about that)!

So basically, switch from one sorting to another doesn't seem to make a difference (regarding transparencies)... When I switching sorting OFF totaly - yes, that blending test case working, but just because order is correct straight away... In general case it will not work...

What I mean... I most likely was wrong blaming QickSort as for wrong sorting...

I asked about comparator since thay play role in sorting too... hmmmm... strange...

Whaah. It isn't working anymore (I didn't swap the planes so far) . Only if I disable the sorting. Hmm... Maybe the clue really is in the comparators.

It's a pitty...

But anyhow, to move forward. I checked default comparator for sorting transparencies, and yes... it seems to be far from being universal... The idea is, that centers of bounding spheres are taken and just distance is compared to the camera location... that's it. If you think about this - it will cause just exactly same behaviour as we see in the test..... Top plane would be top till the moment it get far away enough so that bottoms' plane bounding sphere center become actually closer to the camera then the top one.. - which is totaly wrong, of course. So:1. top one (BLUE) will be drawn first (instead of to be second) and will be blended with the background.2. bottom one (GREEN) drawn next and where it is not overlapping top one - is blended with background, but !!! - where it is overlapping top one (onscreen pixels wisely) - will not be drawn at all because it will not pass GL depth test! - so we see still BLUE plane there blended with the background.

I'm near to complete with the optimizations. We should be up to par with Java3D now .

But there's one thing driving me crazy. The Appearance is not updated when it's been modified. Could please someone check, if this is the case with the current CVS code? e.g. In the HUD test the Buttons should change the texture, when they're hovered. If they don't then I won't break anything when I commit the current changes and you can benefit from the speed-up.

I'm near to complete with the optimizations. We should be up to par with Java3D now .

But there's one thing driving me crazy. The Appearance is not updated when it's been modified. Could please someone check, if this is the case with the current CVS code? e.g. In the HUD test the Buttons should change the texture, when they're hovered. If they don't then I won't break anything when I commit the current changes and you can benefit from the speed-up.

The optimization is done As I said: From my calculations we should be up to par with Java3D now (even if I haven't tested it myself).

The scenegraph is now only refilled when, one sets the dirty flag on the VirtualUniverse object or the Locale or a BranchGroup. Or when a Switch node has changed it's value. The least behaviour can be avoided, too. But this needs some more brainstorming and I don't expect too much from it.

The scenegraph modifiactions are managed by com.xith3d.scenegraph.modifications.ScenegraphModificationsListener respectively com.xith3d.render.ScenegraphModificationsManager. Maybe I forgot to manage anything (being notified of a specific change in the scenegraph) if this is the case. please tell me.

Frustum culling of course needs to be done each frame. I've written a new class called FrustumCuller, which does the job quite efficiently. It makes use of the current frame id, which simply is a number, that is incremented each frame. Only atoms holding this number are rendered. This way the groupwise culling can still be done without clearing the RenderBins.

RenderBin sorting can be an FPS killer. It must not be done too often. I've added a field to the Renderer class called get/setMaxViewDelta(), which is by default 0.1f and which I have set to 1.0f for Q3 test. The view has to move 1.0f in the virtual world until the atoms get resorted (or if anything else has been changed, which needs resorting). 1.0f is a good tradeoff. Play with this value to increase performance.

renanse, could you please use the current version for the webstart thing?

If i forgot to mention anything, I'll tell you when I remember (or just ask).

Hmm, after updating xith3d and xith-tk, the geometry of the quake level is a bit odd. It looks like the indices are messed up in some places or something, especially over the doorways. Anyone else see that?

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