Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (476)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (531)
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  
  GLSelect Picking and Shader State Update fixes  (Read 2139 times)
0 Members and 1 Guest are viewing this topic.
Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Posted 2006-10-25 11:23:42 »

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

Yuri Vl. Gushchin
JProof Group
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #1 - Posted 2006-10-25 19:55:25 »

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

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

Senior Member




Speak Java!


« Reply #2 - Posted 2006-10-26 01:46:25 »

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

Yuri Vl. Gushchin
JProof Group
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #3 - Posted 2006-10-26 02:00:46 »

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

Yuri Vl. Gushchin
JProof Group
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #4 - Posted 2006-10-26 11:08:38 »

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.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #5 - Posted 2006-10-26 12:01:41 »

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

Yuri Vl. Gushchin
JProof Group
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #6 - Posted 2006-10-26 12:33:01 »

BG extends G is ok.

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.

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
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 (13 views)
2014-07-24 01:59:36

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

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

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

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

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

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

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

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

Riven (50 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!