 Show Posts
|
|
Pages: [1] 2 3 4
|
|
1
|
Java Game APIs & Engines / Java 3D / Re: How to get a Sphere's constituent triangles?
|
on: 2007-06-06 21:29:14
|
|
Well, I guess that you could grab the Shape3D from the Sphere, and then the GeometryArray (probably a TriangleStripArray) from that Shape3D to get the triangles. IIRC, the current version of Sphere in J3D does something extra to attempt optimal discretization for a given resolution - look at the source code for Sphere in the utils. To dynamically alter the vertex positions, look at the BY_REFERENCE option in the GeometryArray API.
--Vaidya
|
|
|
|
|
2
|
Java Game APIs & Engines / Java 3D / Re: SciDelik: Java 3D Based Application Demo @ JavaOne 2007
|
on: 2007-05-08 20:05:55
|
Very cool screenshots!
Coming from a Java 3D Maestro, that's a compliment indeed ! Thanks  ! Is it a commercial product? Or OpenSource? I cannot find it on the webpage ....
Actually neither at the present time ! The code base is just simply closed because I wanted to have full control over the design and evolution of the application until at least it looked like a finished product. I have sunk a lot of $$$ and time into it. That said, however, the product has in some sense already served its utility for my research work and, more importantly, developing it has been an exceptionally fun experience. And as a valuable spinoff, especially because of the objective to deal with large geometries, it has helped to identify some nagging memory issues in Java 3D and bring about both implementation changes and new API enhancement. Many thanks to Kevin in particular. Thanks --Vaidya |
|
|
|
|
3
|
Java Game APIs & Engines / Java 3D / SciDelik: Java 3D Based Application Demo @ JavaOne 2007
|
on: 2007-05-05 09:35:53
|
shameless plug....  SciDelik, my magnum opus which has been under development for several years, is an advanced scientific visualization and animation package based on 100% Java and Java 3D, and is scheduled to be on demo at the Java 3D pod at the JavaOne 2007 Conference next week. SciDelik is a fairly large application based on more than 120K LOC and has a fairly nice and comprehensive GUI front end. Though not a game, it has several eye-candy rendering and animation features such as GLSL based particle sprites, view dependent dynamic texturing of line primitives to mimic hair-like Phong lighting, haloing for depth cueing, frame and view dependent dynamic offscreen rendering to simulate texture advection for vivid vector field visualization, and interactive particle seeding and tracking based on high order numerical integration schemes. The grid topology is arbitrary and can be composed of any combination of triangles, quadrilaterals, tetrahedrons, prisms, pyramids, and hexahedrons. SciDelik is based on the popular data flow paradigm with improvisations to mitigate data copy and storage. All the visualization primitives are computed on-the-fly and rendered at interactive rates even with very large grids. The application not only showcases many features of Java 3D, but also attests to the speed of Java for large scale computations  . If you're planning to attend JavaOne 2007, and if you have the time, take a look at some of the demos especially the one on particle tracking and animation in a one million grid node Space Shuttle Launch Vehicle. Thanks --Dr. N. Vaidya SciDelik Website: http://scidelik.googlepages.com/home |
|
|
|
|
5
|
Java Game APIs & Engines / Java 3D / Re: Constant frame rate problem
|
on: 2006-06-12 17:06:05
|
Only place that i didnot use behavour is when a new object should be added to the scene graph. In that case, i am creating the 3d object in another thread and adding it directly to scene graph. Is this a wrong implementation. Do i need to store the commands to be handled in a behaviour class later?
Thanks
And how do you "add" that new object to the scenegraph ? By "attaching" a BranchGroup at runtime ? If so, then you should most certainly be doing that on a Behavior callback since, as per the API contract, attach/detach of a BranchGroup isn't MT safe. |
|
|
|
|
6
|
Java Game APIs & Engines / Java 3D / Re: Constant frame rate problem
|
on: 2006-06-12 16:57:11
|
...
...
Second, sometimes application gets an exception (from Awt Event Queue Thread), and Java3D crashes. Canvas3D does not render anything after this point. Is this a bug of Java3D. Becouse exception and Java3D are not related to each other.
Are you saying that an exception in EDT causes the Canvas to freeze ? That shouldn't really happen with Java 3D 1.4.0 and later. If you're using a pre-1.4.0 version, I've a workaround here: https://java3d.dev.java.net/issues/show_bug.cgi?id=78 |
|
|
|
|
7
|
Java Game APIs & Engines / Java 2D / Re: AffineTransform#createTransformedShape(GeneralPath)
|
on: 2006-06-02 00:20:47
|
|
Thanks for the quick help guys ! alright, I get the big picture now after reading that Bug Fix.
After looking at the 1.5 docs again, I think I could actually get away with clobbering the input data with an in-place transform by doing inputGeneralPath.transform( affineTransform ) since I really didn't need to keep the original data around. I'm using the GeneralPath to build a couple of hand-crafted icons to display in the ToolBar, and the application was crashing right at the start-up.
Thanks again !
|
|
|
|
|
8
|
Java Game APIs & Engines / Java 2D / AffineTransform#createTransformedShape(GeneralPath)
|
on: 2006-05-31 20:31:25
|
Would appreciate some help with the following please: My application which works correctly with jdk1.5.0_06 fails with the following ClassCastException with Mustang b85 (-source 1.5): 1
| java.lang.ClassCastException: java.awt.geom.Path2D$Double cannot be cast to java.awt.geom.GeneralPath |
when I try to retrieve a transformed GeneralPath as follows: 1
| GeneralPath outputGeneralPath = (GeneralPath)affineTransform.createTransformedShape( inputGeneralPath ); |
From a quick look at the source code for 1.5 and 1.6 for the method createTransformedShape(...), it appears that 1.5 can conditionally return a GeneralPath, while 1.6 unconditionally returns a Path2D.Double, and the exception occurs because GeneralPath extends Path2D.Float. Am I missing anythin' obvious ? Thanks in advance |
|
|
|
|
10
|
Java Game APIs & Engines / JOGL Development / Re: IndexedTriangleStripArray
|
on: 2006-02-07 21:29:41
|
Thanks for investigating this further. I can not reproduce your findings with the VertexArrayRange demo. On my machine I get a speedup from some 46 FPS to 49 FPS with checkElementVBODisabled commented out. That's a 6% speedup compared to an 18% speedup you saw with that demo. Since that demo is more or less an extreme test case anyway and uses an obsolete extension I'm not too concerned about it.
A plausible explanation is the speed of the gfx card. I'm using a 6600GT pcie. My guess, possibly not well researched, is that the faster the card, the more amplified will be the differences, as we are evaluating fixed CPU cost against rendering cost. Anyways, the snapshots of the numbers that I quoted earlier for vertexArrayRange demo are attached. It sounds to me like your profiler is skewing the time spent in small methods.
And my profiler is Netbeans ! Probably again the same rationale ? The profiler is more CPU intensive than GPU intensive and, consequently, amplifies the non-rendering overhead. Attached are 2 profiler snapshots of my own testcase. The original version of jogl indicates an FPS of 217 *1000 / 7180 = 30, while the modified version with the checkElementVBODisabled call removed seems to give an FPS of 309 * 1000 / 8052 = 38. But as I mentioned earlier, the FPS is expectedly higher BUT virtually identical when I launch my testcase from the console. At this point if you want to file a low-priority issue about the cost of the various VBO/PBO checking routines please feel free and we'll try to tune them further. Please include all of your findings to date and a pointer to this thread. Thanks.
I guess the reason why it may be worthwhile to look into this is because the differences seem to manifest themselves even in nominal FPS ranges of 40 - 90. So, I'll go ahead and make myself a jogl observer and file an issue ! And I haven't still figured why there is a speed diff between jogl and Java3D.       |
|
|
|
|
11
|
Java Game APIs & Engines / JOGL Development / Re: IndexedTriangleStripArray
|
on: 2006-02-06 16:04:45
|
It's possible; do you have a self-contained test case for this? Alternatively, can you set up a build of the JOGL source tree locally? If you comment out the body of that method in make/gl-impl-CustomJavaCode.java, rebuild, and find that your application is significantly faster, please file a bug using the JOGL Issue Tracker.
OK ! got myself a new build by commenting out the contents of "private void checkElementVBODisabled" in make / gl-impl-CustomJavaCode.java. Tested the original and modded builds against demos/vertexArrayRange/VertexArrayRange.java since it does seem to make glDrawElement calls. The results are: 1. with -slow flag: 50 FPS (original) and 56 FPS (modded) 2. w/o any flag 70 FPS (original) and 83 FPS (modded) So, the modification w.r.t that testcase does seem to make an impact. However, I can't help but wonder if the comparisons are with regard to the fixed cost of checkElementVBODisabled against the variable cost (and which in many cases could be possibly higher) of glDrawElements calls. And as for my own testcase, the modification seems to have no impact when the application is launched from a console. While profiling, however, there does seem to be a fairly significant difference in FPS. The testcase consists of the first 3 files posted here with a few modifications noted later. I'll post the testcase as an issue if it is worth investigating. Thanks -- Vaidya |
|
|
|
|
12
|
Java Game APIs & Engines / JOGL Development / Re: IndexedTriangleStripArray
|
on: 2006-01-31 18:32:13
|
Ken, Can this function checkElementVBODisabled(), which is invoked in the glDrawElements wrapper, turn out to be a time sucker ? May be a chance to speed-up things effectively by 50%, or, may be I have it all wrong ! OK ! Attached is a netbeans profiler report for call tree times. This report is for the parameters in ITSA.java specified as follows: ni = 512, nj = 12, nk = 50, i.e., for numVertices = ni * nj * nk = 307,200. Topologically, the config can be likened to a bunch of 50 tubes, with 11 strips per tube, and 512 vertices per strip. Thus, the number of strips = (12 - 1) x 50 = 550 and, consequently, requires that many number of glDrawElements calls. The profiler snapshot was taken after sufficient warm-up and by resetting the counter to time 25 calls to display() and, thus, 25 x 550 = 13,750 calls to glDrawElements. I see nearly 30% of time being spent in checkElementVBODisabled() and specifically a big chunk in HashMap. -- Vaidya  |
|
|
|
|
13
|
Java Game APIs & Engines / JOGL Development / Re: IndexedTriangleStripArray
|
on: 2006-01-26 12:11:10
|
OK ! in the ITSAEventHandler.java file above, it appears that the position of the index buffer needs to be reset to zero before the loop of glDrawElements. The (apparent) error due to this doesn't show up for the parameters used in ITSA.java above, but it does result in an EA violation when I change the number of planes to 1, i.e., nk = 1. Now, even with the fix above, with the CPU at stock speed of 1.8GHz, I get the following numbers: jogl: ~40 FPS Java 3D: ~80 FPS. So, possibly I could still be missing something  !. I'm using Fraps to get the FPS, BTW. The test were performed with the Vsync off. System config same as in my first post. The Java 3D equivalent of the jogl testcase above is the following files: GeomPerf.java, ITSAVisual.java, and ITSA.java. GeomPerf.java: 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
|
import java.awt.*;
import javax.swing.*;
import java.util.*;
import javax.media.j3d.*;
import javax.vecmath.*;
import com.sun.j3d.utils.universe.*;
import com.sun.j3d.utils.behaviors.vp.*;
public class GeomPerf {
private TransformGroup socketTG;
private Canvas3D canvas3D;
private BoundingSphere bounds;
public GeomPerf() {
bounds = new BoundingSphere( new Point3d(), Double.POSITIVE_INFINITY );
setupSceneGraph();
createGUI();
}
private BranchGroup createSceneGraph() {
BranchGroup rootBG = new BranchGroup();
rootBG.setCapability( TransformGroup.ALLOW_CHILDREN_WRITE );
rootBG.setCapability( TransformGroup.ALLOW_CHILDREN_READ );
rootBG.setCapability( Group.ALLOW_CHILDREN_EXTEND );
TransformGroup scaleTG = new TransformGroup();
Transform3D t3d = new Transform3D();
t3d.setScale( 0.5 );
scaleTG.setTransform( t3d );
scaleTG.setCapability( TransformGroup.ALLOW_CHILDREN_WRITE );
scaleTG.setCapability( TransformGroup.ALLOW_CHILDREN_READ );
scaleTG.setCapability( Group.ALLOW_CHILDREN_EXTEND );
rootBG.addChild( scaleTG );
scaleTG.addChild( ( new ITSAVisual() ).getPlugBG() );
FrameReporter fr = new FrameReporter();
fr.setSchedulingBounds( bounds );
rootBG.addChild( fr );
return rootBG;
}
private void setupSceneGraph() {
GraphicsConfiguration config =
SimpleUniverse.getPreferredConfiguration();
canvas3D = new Canvas3D( config );
SimpleUniverse u = new SimpleUniverse( canvas3D );
ViewingPlatform viewingPlatform = u.getViewingPlatform();
PlatformGeometry pg = new PlatformGeometry();
Color3f ambientColor = new Color3f( 0.3f, 0.3f, 0.3f );
AmbientLight ambientLightNode = new AmbientLight( ambientColor );
ambientLightNode.setInfluencingBounds( bounds );
pg.addChild( ambientLightNode );
Color3f lightColor = new Color3f( 0.3f, 0.3f, 0.3f );
Vector3f lightDirection = new Vector3f( 0.0f, 0.0f, -1.0f );
DirectionalLight light
= new DirectionalLight( lightColor, lightDirection );
light.setInfluencingBounds( bounds );
pg.addChild( light );
viewingPlatform.setPlatformGeometry( pg );
viewingPlatform.setNominalViewingTransform();
OrbitBehavior orbit =
new OrbitBehavior( canvas3D,
OrbitBehavior.REVERSE_ALL );
orbit.setSchedulingBounds( bounds );
viewingPlatform.setViewPlatformBehavior( orbit );
u.addBranchGraph( createSceneGraph() );
}
private void createGUI() {
JFrame mainFrame = new JFrame();
canvas3D.setSize( 400, 400 );
JPanel cp = new JPanel();
cp.setLayout( new BorderLayout() );
cp.add( canvas3D, BorderLayout.CENTER );
mainFrame.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE );
mainFrame.getContentPane().add( cp );
mainFrame.pack();
mainFrame.setVisible( true );
}
public void frameChanged( int frameCount ) {
}
private class FrameReporter extends Behavior {
private int frameCount;
private WakeupCriterion wc;
public void initialize() {
frameCount = 0;
wc = new WakeupOnElapsedFrames(0);
wakeupOn( wc );
}
public void processStimulus( Enumeration criteria ) {
frameChanged( frameCount++ );
wakeupOn( wc );
}
}
public static void main( String[] args ) {
new GeomPerf();
}
}
|
ITSAVisual.java 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
| import java.awt.image.*;
import java.util.*;
import javax.media.j3d.*;
import javax.vecmath.*;
public class ITSAVisual {
private BranchGroup m_plugBG;
public ITSAVisual(
) {
createSubGraph();
}
public BranchGroup getPlugBG () {
return m_plugBG ;
}
public void detachSelf() {
if ( m_plugBG != null ) {
if ( m_plugBG.isLive() ) m_plugBG.detach();
m_plugBG = null;
}
}
private void createSubGraph() {
m_plugBG = new BranchGroup();
m_plugBG.setCapability( Group.ALLOW_CHILDREN_READ );
m_plugBG.setCapability( Group.ALLOW_CHILDREN_WRITE );
m_plugBG.setCapability( BranchGroup.ALLOW_DETACH );
m_plugBG.setUserData( this );
Shape3D shape = new Shape3D();
shape.setPickable( false );
shape.setAppearance( createAppearance() );
shape.setGeometry( createByRefGeometry() );
m_plugBG.addChild( shape );
}
private Appearance createAppearance() {
Appearance app = new Appearance();
ColoringAttributes ca = new ColoringAttributes();
Color3f color = new Color3f( 1.f, 1.f, 1.f );
ca.setColor( color );
PolygonAttributes pa = new PolygonAttributes();
pa.setPolygonMode( PolygonAttributes.POLYGON_FILL );
pa.setCullFace( PolygonAttributes.CULL_NONE );
Material mat = new Material();
mat.setLightingEnable( true );
mat.setAmbientColor( color );
mat.setDiffuseColor( color );
mat.setSpecularColor( new Color3f( 0.3f, 0.3f, 0.3f ) );
mat.setShininess( 64 );
mat.setColorTarget( Material.AMBIENT_AND_DIFFUSE );
app.setPolygonAttributes( pa );
app.setColoringAttributes( ca );
app.setMaterial( mat );
return app;
}
private IndexedTriangleStripArray createByRefGeometry(
) {
ITSA geom = new ITSA();
int vertexKnt = geom.vertexKnt;
float[] vcoords = geom.vcoords;
float[] vcolors = geom.vcolors;
float[] vnormals = geom.vnormals;
int[] vids = geom.vids;
int[] stripIC = geom.stripIC;
IndexedTriangleStripArray ga =
new IndexedTriangleStripArray(
vertexKnt,
IndexedTriangleStripArray.COORDINATES |
IndexedTriangleStripArray.COLOR_3 |
IndexedTriangleStripArray.NORMALS |
IndexedTriangleStripArray.USE_COORD_INDEX_ONLY |
IndexedTriangleStripArray.BY_REFERENCE,
vids.length,
stripIC
);
ga.setCoordRefFloat( vcoords );
ga.setColorRefFloat( vcolors );
ga.setNormalRefFloat( vnormals );
ga.setCoordinateIndices( 0, vids );
ga.setCapability( GeometryArray.ALLOW_REF_DATA_READ );
ga.setCapability( GeometryArray.ALLOW_REF_DATA_WRITE );
return ga;
}
} |
ITSA.java: This is exactly the same as the one posted as part of the jogl testcase bundle earlier. |
|
|
|
|
16
|
Java Game APIs & Engines / JOGL Development / Re: IndexedTriangleStripArray
|
on: 2006-01-23 17:09:01
|
ITSA.java 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
| import java.nio.*;
import java.util.*;
public class ITSA {
int vertexKnt;
float[] vcoords;
float[] vcolors;
float[] vnormals;
float[] vtcoords;
int[] vids;
int[] stripIC;
ITSA() {
int ni = 51;
int nj = 51;
int nk = 101;
int ninj = ni * nj;
int nic = ni - 1;
int njc = nj - 1;
int nkc = nk == 1 ? 1 : nk - 1;
int nicnjc = nic * njc;
int nVerts = ninj * nk;
int nQuads = nicnjc * nk;
int nTrias = 2 * nQuads;
float rni = 1.f / ( ni - 1.f );
float rnj = 1.f / ( nj - 1.f );
float rnk;
if ( nk == 1 ) {
rnk = 0.f;
} else {
rnk = 1.f / ( nk - 1.f );
}
vertexKnt = nVerts;
vcoords = new float[3 * nVerts];
vcolors = new float[3 * nVerts];
vnormals = new float[3 * nVerts];
vtcoords = new float[2 * nVerts];
vids = new int[2 * ni * njc * nk];
int nvknt = 0;
for ( int k = 0; k < nk; k++ ) {
for ( int j = 0; j < nj; j++ ) {
for ( int i = 0; i < ni; i++ ) {
vcoords[nvknt++] = -0.5f + i * rni;
vcoords[nvknt++] = -0.5f + j * rnj;
vcoords[nvknt++] = -0.5f + k * rnk;
}
}
}
stripIC = new int[njc * nk];
Arrays.fill( stripIC, 2 * ni );
int knt = 0;
for ( int k = 0; k < nk; k++ ) {
int kvoff = k * ninj;
for ( int j = 0; j < nj - 1; j++ ) {
int jvoff = j * ni;
for ( int i = 0; i < ni; i++ ) {
int nv = i + jvoff + kvoff;
vids[knt++] = nv + ni;
vids[knt++] = nv;
}
}
}
for ( int n = 0, n3 = 0; n < nVerts; n++ ) {
vcolors[n3++] = 1.0f;
vcolors[n3++] = 0.0f;
vcolors[n3++] = 0.5f;
}
for ( int n = 0, n3 = 0; n < nVerts; n++ ) {
vnormals[n3++] = 0.0f;
vnormals[n3++] = 0.0f;
vnormals[n3++] = 1.0f;
}
}
} |
|
|
|
|
|
17
|
Java Game APIs & Engines / JOGL Development / IndexedTriangleStripArray
|
on: 2006-01-23 17:07:48
|
Just been fiddling with a JOGL testcase that uses glLockArraysEXT and glDrawElements for a geometry discretized by indexed triangle strips. On a AMD 3000+, 6600GT 128MB, 2x512 MB PDP XBLK rig I get about 40FPS with the CPU at stock 1.8GHz and 50FPS with the CPU oc-ed to 2.2GHz. Based on the corresponding numbers using Java 3D (though it actually picks up glMultiDrawElementsEXT in my gfx config), something appears awry...may be with my jogl code ! Would like someone to check it out if possible, please. I'm looking at per-frame performance and not at the initial cost of setting up the buffers etc. The geometry consists of nk = 101 square planes in the k-/z-dir. Each square plane is discretized by square cells with ni = 51 vertices in the i-/x-dir and nj = 51 vertices in the j-/y-dir. The strips are oriented along the i-dir, i.e., each j = constant row is a strip. There are (51 - 1) x 101 strips; each strip has 2 x ni = 102 vertices comprising 100 tris. Hope I got these right...! The JOGL version that I used is one of the recent jsr231 daily builds I believe...! The files Main.java, ITSAEventHandler.java, and ITSA.java are below: Main.java 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
|
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
import javax.swing.event.*;
import javax.media.opengl.*;
import com.sun.opengl.utils.*;
public class Main {
public static void main( String[] args ) {
GLCanvas canvas = new GLCanvas();
canvas.addGLEventListener( new ITSAEventHandler() );
final Animator animator = new Animator( canvas );
JFrame frame = new JFrame( "ITSA" );
frame.add( canvas );
frame.addWindowListener( new WindowAdapter() {
public void windowClosing( WindowEvent e ) {
new Thread( new Runnable() {
public void run() {
animator.stop();
System.exit(0);
}
}).start();
}
});
frame.pack();
frame.setSize( 400, 400 );
frame.setVisible( true );
animator.start();
}
}
|
ITSAEventHandler.java 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
| import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
import javax.swing.event.*;
import java.nio.*;
import java.util.*;
import javax.media.opengl.*;
import com.sun.opengl.utils.*;
public class ITSAEventHandler implements GLEventListener {
private GeomBuffers geomBufs;
public ITSAEventHandler() {
ITSA geom = new ITSA();
geomBufs = new GeomBuffers( geom );
}
public void init( GLAutoDrawable drawable ) {
GL gl = drawable.getGL();
System.err.println( "INIT GL IS: " + gl.getClass().getName() );
gl.setSwapInterval(0);
gl.glEnable( GL.GL_DEPTH_TEST );
gl.glShadeModel( GL.GL_SMOOTH );
float pos[] = { 0.0f, 0.0f, 10.0f, 0.0f };
float yellow[] = { 1.0f, 1.0f, 0.0f, 1.0f };
float white[] = { 1.0f, 1.0f, 1.0f, 1.0f };
float gray[] = { 0.3f, 0.3f, 0.3f, 1.0f };
float shininess[] = { 64.f };
gl.glLightfv( GL.GL_LIGHT0, GL.GL_POSITION, pos, 0 );
gl.glLightfv( GL.GL_LIGHT0, GL.GL_DIFFUSE, gray, 0 );
gl.glLightfv( GL.GL_LIGHT0, GL.GL_AMBIENT, gray, 0 );
gl.glLightfv( GL.GL_LIGHT0, GL.GL_SPECULAR, gray, 0 );
gl.glEnable( GL.GL_LIGHTING );
gl.glEnable( GL.GL_LIGHT0 );
gl.glPolygonMode( GL.GL_FRONT_AND_BACK, GL.GL_FILL );
gl.glMaterialfv( GL.GL_FRONT_AND_BACK,
GL.GL_AMBIENT_AND_DIFFUSE, white, 0 );
gl.glMaterialfv( GL.GL_FRONT_AND_BACK,
GL.GL_SPECULAR, gray, 0 );
gl.glMaterialfv( GL.GL_FRONT_AND_BACK,
GL.GL_SHININESS, shininess, 0 );
gl.glColorMaterial( GL.GL_FRONT_AND_BACK,
GL.GL_AMBIENT_AND_DIFFUSE );
gl.glEnable( GL.GL_COLOR_MATERIAL );
}
public void reshape(
GLAutoDrawable drawable,
int x,
int y,
int width,
int height
) {
GL gl = drawable.getGL();
System.err.println( "GL_VENDOR: " +
gl.glGetString( GL.GL_VENDOR ) );
System.err.println( "GL_RENDERER: " +
gl.glGetString( GL.GL_RENDERER ) );
System.err.println( "GL_VERSION: " +
gl.glGetString( GL.GL_VERSION ) );
float h = (float)height / (float)width;
gl.glMatrixMode( GL.GL_PROJECTION );
gl.glLoadIdentity();
gl.glFrustum( -1.0f, 1.0f, -h, h, 5.0f, 60.0f );
gl.glMatrixMode( GL.GL_MODELVIEW );
gl.glLoadIdentity();
gl.glTranslatef( 0.0f, 0.0f, -10.0f );
}
public void display( GLAutoDrawable drawable ) {
GL gl = drawable.getGL();
if ( ( drawable instanceof GLJPanel ) &&
!( (GLJPanel) drawable ).isOpaque() &&
( (GLJPanel) drawable ).shouldPreserveColorBufferIfTranslucent() ) {
gl.glClear( GL.GL_DEPTH_BUFFER_BIT );
} else {
gl.glClear( GL.GL_COLOR_BUFFER_BIT | GL.GL_DEPTH_BUFFER_BIT );
}
renderGeometry( gl );
}
public void displayChanged(
GLAutoDrawable drawable,
boolean modeChanged,
boolean deviceChanged
) {
}
private void renderGeometry( GL gl ) {
gl.glEnableClientState( gl.GL_COLOR_ARRAY );
gl.glEnableClientState( gl.GL_NORMAL_ARRAY );
gl.glEnableClientState( gl.GL_VERTEX_ARRAY );
gl.glVertexPointer( 3, gl.GL_FLOAT, 0, geomBufs.vcoordBuf );
gl.glNormalPointer( gl.GL_FLOAT, 0, geomBufs.vnormalBuf );
gl.glColorPointer( 3, gl.GL_FLOAT, 0, geomBufs.vcolorBuf );
gl.glLockArraysEXT( 0, geomBufs.vertexKnt );
int[] stripIC = geomBufs.stripIC;
IntBuffer vidBuf = geomBufs.vidBuf;
int offset = 0;
for ( int i = 0, imax = stripIC.length; i < imax; i++ ) {
gl.glDrawElements( gl.GL_TRIANGLE_STRIP,
stripIC[i],
gl.GL_UNSIGNED_INT,
vidBuf );
offset += stripIC[i];
vidBuf.position( offset );
}
gl.glUnlockArraysEXT();
gl.glDisableClientState( gl.GL_COLOR_ARRAY );
gl.glDisableClientState( gl.GL_NORMAL_ARRAY );
gl.glDisableClientState( gl.GL_VERTEX_ARRAY );
}
private class GeomBuffers {
int vertexKnt;
FloatBuffer vcoordBuf;
FloatBuffer vnormalBuf;
FloatBuffer vcolorBuf;
IntBuffer vidBuf;
int[] stripIC;
GeomBuffers( ITSA geom ) {
vertexKnt = geom.vertexKnt;
vcoordBuf = BufferUtils.newFloatBuffer( geom.vcoords.length );
vcoordBuf.put( geom.vcoords );
vcoordBuf.rewind();
vcolorBuf = BufferUtils.newFloatBuffer( geom.vcolors.length );
vcolorBuf.put( geom.vcolors );
vcolorBuf.rewind();
vnormalBuf = BufferUtils.newFloatBuffer( geom.vnormals.length );
vnormalBuf.put( geom.vnormals );
vnormalBuf.rewind();
vidBuf = BufferUtils.newIntBuffer( geom.vids.length );
vidBuf.put( geom.vids );
vidBuf.rewind();
stripIC = geom.stripIC;
}
}
} |
|
|
|
|
|
19
|
Discussions / General Discussions / Re: New 3D card- broken?
|
on: 2006-01-03 16:47:25
|
One other thing - you say your card came with its own power cable. So I assume that means there's no slot for the PS to plug in to? No it came with a socket for a power cable but between two hard drives and two CD drives I didn't have a cable to attach to it, so I had to get a cable splitter. When I got my new PSU it had loads of leads so the card is now on it's own power line. Since my 6600GT PCIE doesn't have a molex slot, I suppose yours is an AGP. IIRC, there were many issues when the AGP debuted, especially with the XFX make. I'd check the +12V rating of your power supply. And if you can, try to boot with a single HDD and no CD drives (bcoz they also suck some from the +12V line) and see what happens. A few other options would be: the mobo bios, AGP aperture settings, and the card bios. Check also the nvidia forums. This one for example: http://forums.nvidia.com/index.php?showtopic=4758 |
|
|
|
|
20
|
Game Development / Newbie & Debugging Questions / Re: Looking for JDK 1.5.0_05
|
on: 2005-12-04 10:21:06
|
Someone should put a firecracker up the backside of the people that do the webpage editing for java.sun.com - maybe introduce them to HttpUnit, JWebUnit, Jmeter, etc. Yeah, considering all the work that goes into getting a JDK ready for the release at the back end, this sloppiness should certainly be avoided at the front end. |
|
|
|
|
23
|
Game Development / Newbie & Debugging Questions / Re: Looking for JDK 1.5.0_05
|
on: 2005-12-02 05:14:40
|
(no, I don't know japanese, but links are clickable).
 Yes, I could do with 1.5.0_06, but the catch is this: I'm trying to test the Jet compiler which supports 1.5.0_04 and 1.5.0_05 (with a patch). It appears that currently there is no Jet support for 1.5.0_06. And I'd prefer 1.5.0_05 over 1.5.0_04 (which I have) because, among other things, I believe support for "lock coarsening" feature debuted in 1.5.0_05. Hence, my quest for 1.5.0_05. On a side note, I'm kind of surprised about the goof with the Release Notes considering that we might just well be getting to "over a billion served" with the Java JDK ! |
|
|
|
|
24
|
Game Development / Newbie & Debugging Questions / Looking for JDK 1.5.0_05
|
on: 2005-12-01 06:16:27
|
Quite clueless here  ....and may appreciate some help ! I'm trying to get hold of jdk 1.5.0_05. The download page at java.sun.com lists jdk 5.0 update 6 as the current version. The Release Notes there, I think, seems to imply that it is 1.5.0_05 (the hyper link "changes to 1.5.0_05" takes you to "changes in 1.5.0_05"). Also, the jdk archive page lists the older ones upto only 1.5.0_04. So, where is 1.5.0_05 ? Or, is jdk 5.0 Update 6 really 1.5.0_05 ? Sorry if I'm missing something totally obvious here. Thanks -- Vaidya |
|
|
|
|
25
|
Game Development / Performance Tuning / Re: New C1 in Mustang b59
|
on: 2005-11-15 00:17:51
|
Should there be a performance enhancement with 1.6.0-rc-b60 over 1.5.0_04 for, in particular, int mult and div ? Seems quite insignificant. FWIW, the benchmarks with C version of SciMark2 (equivalent to the Java version *I suppose* and haven't checked) with VC++6.0/SP6  with the following makefile flags (AMD64 system as described earlier with CPU @ 1.8GHz): CC = cl -Za -W3 CFLAGS = -nologo -O2x /G6 $(CC) $(CFLAGS) scimark2.obj $(OBJS) are below : 1
2
3
4
5
6
7
8
9
10
11
12
13
| > scimark2.exe 10
** **
** SciMark2 Numeric Benchmark, see http:** for details. (Results can be submitted to pozo@nist.gov) **
** **
Using 10.00 seconds min time per kenel.
Composite Score: 177.35
FFT Mflops: 108.91 (N=1024)
SOR Mflops: 387.21 (100 x 100)
MonteCarlo: Mflops: 40.66
Sparse matmult Mflops: 168.28 (N=1000, nz=5000)
LU Mflops: 181.67 (M=100, N=100) |
Any ideas what will be a good compiler/flags to give a fair trial to the C version ? |
|
|
|
|
26
|
Game Development / Performance Tuning / Re: New C1 in Mustang b59
|
on: 2005-11-12 22:47:32
|
With 1.6.0-rc-build60, I'm seeing a 25% speed-up for a heavy duty number crunching module in a visualization application - particle tracking in a heterogeneous mesh. Kudos to the VM Team ! Did some SciMark2.0a benchmarking on my own with the following system: AMD 64 Venice 3000+ @ stock 1.8GHz and oc-ed 2.8GHz 2 x 512 PDP Patriot XBLK PC3200 @ stock DDR400 and oc-ed DDR560 WinXP SP2 The benches were run without the "large" flag and for a minimum period of 10 sec. A longer time, or, -Xcomp flag didn't make any significant difference. The 1.6.0 server bench was ran without the -Xcomp flag (more on that later): 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| CPU @ 1.8GHz, RAM @ 2-3-2-5, 1T, DDR400
<- 1.5.0_04 -> <- 1.6.0-rc-b60 ->
SciMark 2.0a client server client server
Composite Score 221 369 315 391
FFT (1024) 107 289 276 364
SOR (100x100) 424 591 433 585
Monte Carlo 39 79 66 110
Sparse matmult (N=1000, nz=5000) 200 236 361 210
LU (100x100) 333 650 442 687
CPU @ 2.8GHz, RAM @ 2.5-3-3-8, 1T, DDR560
<- 1.5.0_04 ->
SciMark 2.0a client server
Composite Score 344 575
FFT (1024) 166 451
SOR (100x100) 660 919
Monte Carlo 62 123
Sparse matmult (N=1000, nz=5000) 315 368
LU (100x100) 520 1011 |
Nice speed-ups with 1.6.0 ! The sparse matrix multiplication kernel with the server option turns out timings that seem awry. Don't know what the reason is - 2D arrays ?? With the system overclocked, both client and server exhibit identical speedups that match the CPU speedup. Azeem ! Is the SSE2 support for AMD64 fully complete in the compiler ? IIRC, not long ago, you said something to the effect that it wasn't (in the server compiler). And on using the -Xcomp option in conjunction with the -server option in 1.6.0, there is a gross degradation in performance as below: 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| > java -server -Xcomp -Xms256m -Xmx256m jnt/scimark2/commandline 20
SciMark 2.0a
Composite Score: 299.8784709508011
FFT (1024): 227.93827199159992
SOR (100x100): 586.2128746430392
Monte Carlo : 90.42036412631579
Sparse matmult (N=1000, nz=5000): 167.26901426400147
LU (100x100): 427.5518297290492
java.vendor: Sun Microsystems Inc.
java.version: 1.6.0-rc
os.arch: x86
os.name: Windows XP
os.version: 5.1 |
|
|
|
|
|
28
|
Java Game APIs & Engines / Java 3D / Re: MIscellaneous questions.
|
on: 2005-10-01 22:02:50
|
I'm afraid I'm using parallel projection mode, so this has no effect. Screen scale doesn't seem to do the job either, or modifying the Screen3D's physical width and physical height.
Perhaps it would be better if you saw the code. The important bits are down toward the end, in the Viewer class and camera() method.
For using screenScale, are you specifying View#setScreenScalePolicy( View.SCREEN_EXPLICIT ) ? If not, try it. As an alternative to screenScale or scaling the ViewWorld, you could also try using a scaling on the ViewPlatform Transform. |
|
|
|
|
29
|
Java Game APIs & Engines / Java 3D / Re: Problem with Transparency blending.
|
on: 2005-10-01 21:28:47
|
The MultiTexture Combine mode for blending 2 textures should be useful here I'd think - may be that's what Jeff has been suggesting. You might want to look at TextureAttributes.COMBINE and specifically TextureAttributes.COMBINE_INTERPOLATE modes or may be some variants of it. As a simple case, if you've 2 opaque textures and want to blend them in using a uniform blending factor then you could use the combine mode and set a TextureBlendColor of ( 0, 0, 0, blendFactor ). This is a snapshot (from Java 3D) showing 2 textures - colormap + advection - with a blend factor of 0.7:  And this with a blend factor of 0.92:  It runs at about 12 FPS on a 6600GT with a 2048^2 texture + continuous offscreen rendering + noise texture cycling. |
|
|
|
|
30
|
Java Game APIs & Engines / Java 3D / Re: MIscellaneous questions.
|
on: 2005-09-21 19:05:25
|
[
I'm afraid I'm using parallel projection mode, so this has no effect. Screen scale doesn't seem to do the job either, or modifying the Screen3D's physical width and physical height.
OK, then an option might be to apply a scaling factor to the Transform3D of the TransformGroup holding your ViewWorld. |
|
|
|
|
|
Add your game by posting it in the WIP section,
or publish it in Showcase.
The first screenshot will be displayed as a thumbnail.
|
|
! Dunno if the present problems are related, but my guess is that the mess started when I shifted from Win 98 to Win XP.
