Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (498)
Games in Android Showcase (117)
games submitted by our members
Games in WIP (564)
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  
  Xith UI System - Performance debate  (Read 2070 times)
0 Members and 1 Guest are viewing this topic.
Offline Amos Wenger

Senior Member




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


« Posted 2005-09-01 15:12:27 »

I haven't started to code yet, but I'm actually designing the future Xith UI System.
I have a question about performances and I WANT ( Wink) your opinions on that.
Is it better :
 - To do multiple textured quads and simple picking
 - Or to do a unique textured quads and make 5 picks (4 corners + mouse position) and interpolate ?
In other words : is it better to have more polygons or more picking operations ?

"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 kevglass

JGO Kernel


Medals: 165
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #1 - Posted 2005-09-01 15:18:18 »

Personally, I think it'd be better to resolve the issue of Parrallel/Perspective projection swapping. Then just use the parrallel mode to avoid picking altogether Smiley

Even nicer might be to avoid using the scenegraph for the GUI at all (since its not the best of fits). If the ability to plugin in bits of LWJGL/JOGL code directly to the sccenegraph is made available (see other post) then you could just plugin a GUI module which swapped into glOrtho matrix and drew the GUI.

I think however you design it - using the scenegraph for the GUI is going to lead to a slow(er) implementation.

Kev

Offline Amos Wenger

Senior Member




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


« Reply #2 - Posted 2005-09-01 16:41:56 »

Oh, I see.
Thanks for your advice.

But I can design the system, displaying with the scenegraph, and then switch to JOGL/LWJGL code to display faster ?

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline endolf

JGO Coder


Medals: 7


Current project release date: sometime in 3003


« Reply #3 - Posted 2005-09-01 17:21:06 »

The whole picking thing is exactly what I did in Java3D, it's not bad at performance, but it really does suck being in the scene graph. I've tried porting my hud and hit a number of issues with picking in xith close to the frontclip plane. Ranging from it picking nothing, to it picking values that make no sence at all. I gave up. You are welcome to the J3D code and the bit of porting I had done if you after, just patch up the picking code and it should automagically work Smiley.

The best way would be to stick the post render glOrtho stuff in Smiley

Endolf

Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #4 - Posted 2005-09-02 02:02:57 »

Can we avoid using picking by using the Foreground node? That is a feature that is already in Xith3D.

Will.

Offline arne

Senior Member




money is the worst drug- we should not let it rule


« Reply #5 - Posted 2005-09-02 05:55:46 »

Can we avoid using picking by using the Foreground node? That is a feature that is already in Xith3D.

Will.

Yeah, but we'll need picking then also. The foreground node only makes the objects to be relative to the view, so we'll still have perspective there. Or am I wrong here?

Arne

:: JOODE :: Xith3d :: OdeJava ::
Offline Goliat

Junior Member





« Reply #6 - Posted 2005-09-02 06:03:51 »

couldn't one use a transform group and some math magic to add a coordinate space too a foreground node where the top/left corner is always 0/0 and the bottom/right 1/1 ... or based on the resolution?

guess this would avoid picking too ...

just my thinkin'
Offline arne

Senior Member




money is the worst drug- we should not let it rule


« Reply #7 - Posted 2005-09-02 06:43:18 »

couldn't one use a transform group and some math magic to add a coordinate space too a foreground node where the top/left corner is always 0/0 and the bottom/right 1/1 ... or based on the resolution?

guess this would avoid picking too ...

just my thinkin'

If you can do that magic Smiley
I really think we should do this Parallel/Perspective swapping and then simply rendering it in parallel on top of the perspective stuff, like kev said. Then we can also quarantee, that the positions really have a linear relationship. And we wouldn't have to do that kind of magic Wink

:: JOODE :: Xith3d :: OdeJava ::
Offline Amos Wenger

Senior Member




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


« Reply #8 - Posted 2005-09-02 10:29:32 »

Yes, so who is in charge of implementing these special features to Xith (multi-pass rendering.., direct access to underlying API, and so on..) ?

"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 endolf

JGO Coder


Medals: 7


Current project release date: sometime in 3003


« Reply #9 - Posted 2005-09-04 20:25:38 »

Using foreground node and Transform.ortho method, we might be able to get round it and avoid picking at all

Currently plaing in Java3D with my old hud code. If I get it working, i'll be able to port it to xith easily (I think).

Endolf

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

JGO Coder


Projects: 2


Fire at will


« Reply #10 - Posted 2005-09-05 04:47:24 »

Can we avoid using picking by using the Foreground node? That is a feature that is already in Xith3D.

Will.

Yeah, but we'll need picking then also. The foreground node only makes the objects to be relative to the view, so we'll still have perspective there. Or am I wrong here?

Arne

That is correct.  It does currently work quite well for hud's in its present state though.

Will.

Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #11 - Posted 2005-09-05 04:49:23 »

Yes, so who is in charge of implementing these special features to Xith (multi-pass rendering.., direct access to underlying API, and so on..) ?

Currently no-one, it is just the seed of an idea.  This is a large and important feature to Xith3D, I believe the priority should be getting it right the first time.

Will.

Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #12 - Posted 2005-09-05 04:53:18 »

couldn't one use a transform group and some math magic to add a coordinate space too a foreground node where the top/left corner is always 0/0 and the bottom/right 1/1 ... or based on the resolution?

guess this would avoid picking too ...

just my thinkin'

Indeed, I too seek this magic forumla.  Recently  I was creating a top-down game, and I was able to match the coordinates for a 1024x768 ground texture to the screen coordinates by using a FOV of 90 degrees and placing the camera at a Y value of half the texture height (IIRC).  I wanted to be able to match the coordinates with an arbituary FOV, but could not find/devise the forumla (as I had it working with FOV-90 though I didn't worry too much).  I am sure this must be possible.

Will.

Offline endolf

JGO Coder


Medals: 7


Current project release date: sometime in 3003


« Reply #13 - Posted 2005-09-05 06:15:56 »

couldn't one use a transform group and some math magic to add a coordinate space too a foreground node where the top/left corner is always 0/0 and the bottom/right 1/1 ... or based on the resolution?

Isn't this what Transform3D's ortho method is for?

(Currently playing to find out)

I've seen it used in a tutorial for Agency9's scene graph.

Endolf

Offline Goliat

Junior Member





« Reply #14 - Posted 2005-09-06 18:55:50 »

can anyone explain me what how the planes in the view frustum are to be understood?

1  
2  
3  
4  
Frustum f = new Frustum();
      view.extractFrustum( f, canvas );
     
      System.out.println( f );

gives me:
1  
Frustum[Left:Plane[A:-0.7187723 B:0.0 C:-0.6952455 D:0.0] Right:Plane[A:0.7187723 B:0.0 C:-0.6952455 D:0.0] Bottom:Plane[A:0.0 B:0.8193296 C:-0.5733228 D:0.0] Top:Plane[A:0.0 B:-0.8193296 C:-0.5733228 D:0.0] Far:Plane[A:0.0 B:0.0 C:1.0 D:1999.9532] Near:Plane[A:0.0 B:0.0 C:-1.0 D:-1.0]]

those are the planes of the view frustum ... but how can i construct a frustum from these values?
specially the -1.0 nearplane confuses me ...

Offline arne

Senior Member




money is the worst drug- we should not let it rule


« Reply #15 - Posted 2005-09-06 19:22:19 »

can anyone explain me what how the planes in the view frustum are to be understood?

1  
2  
3  
4  
Frustum f = new Frustum();
      view.extractFrustum( f, canvas );
     
      System.out.println( f );

gives me:
1  
Frustum[Left:Plane[A:-0.7187723 B:0.0 C:-0.6952455 D:0.0] Right:Plane[A:0.7187723 B:0.0 C:-0.6952455 D:0.0] Bottom:Plane[A:0.0 B:0.8193296 C:-0.5733228 D:0.0] Top:Plane[A:0.0 B:-0.8193296 C:-0.5733228 D:0.0] Far:Plane[A:0.0 B:0.0 C:1.0 D:1999.9532] Near:Plane[A:0.0 B:0.0 C:-1.0 D:-1.0]]

those are the planes of the view frustum ... but how can i construct a frustum from these values?
specially the -1.0 nearplane confuses me ...


[size=8pt]This is maybe a bit OT, but I'll try to answer it anyways. A moderator can move it later if he thinks this would be necessary.[/size]

It returns the Area in which things get rendered. And where they are rendered. The nearplane simply specifies, that things that are too close don't get rendered.

Arne

:: JOODE :: Xith3d :: OdeJava ::
Offline Goliat

Junior Member





« Reply #16 - Posted 2005-09-07 07:14:15 »

it's not OT as i try to get those 'magic math' thingy from this ... should be possible ... or am i mistaken there?

Offline arne

Senior Member




money is the worst drug- we should not let it rule


« Reply #17 - Posted 2005-09-07 14:10:50 »

it's not OT as i try to get those 'magic math' thingy from this ... should be possible ... or am i mistaken there?



Ok then I have misunderstood you, sorry  Undecided

It should be possible. But don't ask me how Wink

:: JOODE :: Xith3d :: OdeJava ::
Offline Goliat

Junior Member





« Reply #18 - Posted 2005-09-07 19:37:01 »

it's just that i can't guess how to construct a frustum form those values
the standard values for front and back clipping plane are 1 ( unit from camera if i'm not mistaken ) and 2000
so the backclipping plane is represented by Far:Plane[A:0.0 B:0.0 C:1.0 D:1999.9532] where i find the distance in field D ... but what is C:1.0? ... and A and B?
nevertheless that could be right ... what i can't understand is the two -1 values in the frontplane ...
and how to puzzle the other values into the whole thing is some kind of riddle for me Smiley
Offline Niwak

Senior Member


Medals: 1
Projects: 1



« Reply #19 - Posted 2005-09-08 06:42:38 »

I don't know for sure, but it looks like you are facing plane equations of the form ;

Ax + By + Cz + D = 0

Or under another form : N.OM = -D with N the normal of the plane (A,B,C) and OM the vector to your point (x,y,z).

Therefore, your near plane if facing backward along z axis (N = (0,0,-1)) and is placed at z = -1 (D=-1), and your far plane has N=(0,0,1) and is placed at z = 1999.9532.

Hope it helps

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

Grunnt (21 views)
2014-09-23 14:38:19

radar3301 (14 views)
2014-09-21 23:33:17

BurntPizza (31 views)
2014-09-21 02:42:18

BurntPizza (22 views)
2014-09-21 01:30:30

moogie (20 views)
2014-09-21 00:26:15

UprightPath (29 views)
2014-09-20 20:14:06

BurntPizza (33 views)
2014-09-19 03:14:18

Dwinin (48 views)
2014-09-12 09:08:26

Norakomi (75 views)
2014-09-10 13:57:51

TehJavaDev (108 views)
2014-09-10 06:39:09
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!