GLSelect Picking and Shader State Update fixes

Engines, Libraries and Tools Xith3D Forums
#1

Hi,

I just committed fixes for glSelect picking. Two new samples - GLSelectPickingRenderPassTest.java and GLSelectPickingViewTest.java - also committed to xith-tk. These two samples differ by the way how projection policy is switched (in View or RenderPassConfig). Now glSelect picking (both Parallel and Perspective projected) should be working fine in all configurations.

To use glSelect picking, use Canvas3D.pick*(…) methods, because of default View’s picking goes to PickingLibrary.

Another fix is a change to Shader State Updates. This solves “strange” appearance glitches that you might have in your apps after dynamic scene changes via by-reference access. At least one of the tests affected - Q3FlightBenchmark.java does not show up “flashing” textures anymore (it was the case before).

Yuri

#2

Thanks. I adapted your changes in CanvasPeerImpl also for LWJGL.

There’re two things that disturb me a little bit. You changed BranchGroup to extend Group. Why did you do that? BranchGroup isn’t supposed to be used as a regular group. And the traverse method is important to be override the one from GroupNode or Group, since only by doing it this way, the correct method of DetailedTraversalCallback is called.
And you put an updateShaders() call to FrustumCuller, which should be unnecessary, since it is called in ShapeAtomPeer.renderAtom().

Is it ok, when I revert these two this change?

Marvin

#3

Hi,

As of the BranchGroup inheritance from the Group, for me is only important that I can preserve my old-style use of the BranchGroup wherever I want in the scenegraph - this saves me from A LOT of explanations to my developers of why they should change their coding style (using BGs) I explained to them, so this is mostly personal (and corporate) preference.

The only need is that BranchGroup extends Group. If I removed correct BG’s behaviour, then you are free to revert it back. I only ask that we should keep “BG extends G” - I save few tens hours on that, while I believe it will not hurt the design too much.

On the other hand, I believe I checked line-by-line the implementation of the traversal, and it was exactly the same as in Group. But I maybe missed something, which is also possible - too many parallel tasks these days.

Yuri

#4

…and I believe there were no objections to change back the inheritance of BG to G… (I believe I can find appropriate post dated few days ago)

Yuri

#5

There’s no objections for me.

Although we should exhort new users (which do not have a codebase of several thousands of lines) to use BranchGroup only for rendering passes, and Group for the remaining.

#6

Hi,

There is a check in Group anyway, but I would like to have a switch that turns warnings of (should be ON by default, or even can throw Runtime Exception).

Yuri

#7

BG extends G is ok.

There’s absolutely no difference in the implementation of this method. But the method of the DetailedTraversalCallback interface, that is called from within the traverse() method will be a different one, if it is overridden in BranchGroup. I’ll put this mehtod back into BranchGroup, but leave it extending Group.

Marvin