Have some Java3d code I would like to try to port to Xith3d.
I would like to run some benchmarks.
I installed as recommended by xith.org
When starting the demos (CubeTest, …)
I get an empty black screen.
Huh ?
Hi
I’m assuming that if xith is failing then there would be some kind of stack trace, somewhere. On the other hand a black screen is strange, it should either be light grey like a normal swing background (meaning xith has failed), or a darker grey, meaning xith has managed to get to GL, but something has gone wrong with the boxes. Either way there should be a stack trace somewhere. How are you launching it, from a dos prompt?.
Another option is that it’s a graphics card driver problem, were you running the directX version of java3d?, does the opengl version of java3d work?, do any opengl applications work?, what OS are you on?, what graphics card and drivers do you have?
Cheers
Endolf
Thanks for the response.
Actually I have the same problem both on Linux and win2000
Here is some info from win2000:
Hit SPACE to toggle projection policy, or ESC to exit
Init GL is net.java.games.jogl.impl.windows.WindowsGLImpl
OpenGL Renderer = GLINT R3 PT + GLINT Gamma
OpenGL Version = 1.1.28 PT
OpenGL Vendor = 3Dlabs
OpenGL Extensions = GL_EXT_bgra GL_EXT_texture_object GL_EXT_polygon_offset GL_WIN_swap_hint GL_EXT_vertex_array GL_EXT_rescale_normal GL_EXT_texture_edge_clamp GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_blend_subtract GL_EXT_blend_minmax GL_EXT_paletted_texture GL_EXT_shared_texture_palette GL_HP_occlusion_test GL_KTX_buffer_region GL_Autodesk_valid_back_buffer_hint GL_EXT_multi_draw_arrays GL_EXT_separate_specular_color
But no errors.
That is cntrl-C doesn’t dump anything
I am starting from a cygwin prompt
java -cp libs/xith3d.jar com.xith3d.test.CubeTest
All opengl applications work
Java3d works just fine
Any clues ?
Linux Redhat 8.0
Starting from a bash shell
starting frame speed test
Init GL is net.java.games.jogl.impl.x11.X11GLImpl
OpenGL Renderer = Mesa DRI Radeon 20010402 AGP 1x x86/MMX/SSE
OpenGL Version = 1.2 Mesa 3.4.2
OpenGL Vendor = VA Linux Systems, Inc.
OpenGL Extensions = GL_ARB_multitexture GL_ARB_transpose_matrix GL_EXT_abgr GL_EXT_blend_func_separate GL_EXT_clip_volume_hint GL_EXT_compiled_vertex_array GL_EXT_histogram GL_EXT_packed_pixels GL_EXT_polygon_offset GL_EXT_rescale_normal GL_EXT_stencil_wrap GL_EXT_texture3D GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_object GL_EXT_texture_lod_bias GL_EXT_vertex_array GL_MESA_window_pos GL_MESA_resize_buffers GL_NV_texgen_reflection GL_PGI_misc_hints GL_SGIS_pixel_texture GL_SGIS_texture_edge_clamp
Once again exits normally Chris
OpenGL 1.2 is required. That’s one possible reason why it doesn’t run under Windows. Does the app exit automatically under Linux or do you only get a black screen? What is your java version?
I’ve noticed that OpenGL 1.3 is required, I’m afraid! :-/
In Win2k you’re using 1.1, under Linux you’ve got 1.2. Is it possible to update your OpenGL drivers? Maybe there’s a more recent version available for your hardware that will give you what’s required?
[quote]I’ve noticed that OpenGL 1.3 is required, I’m afraid! :-/
[/quote]
Where does Xith3D need OpenGL 1.3?
@cfenton: If you don’t need hardware acceleration, you can install a current version of the mesa libs, which support at least OpenGL 1.4.
[quote]Where does Xith3D need OpenGL 1.3?
[/quote]
Every transformation requires a call to glLoadTransposeMatrixf, which was only added in 1.3. It’s easy to fix, though, by pulling the data from the matrix already transposed and call glLoadMatrixf instead - that’s what I’ve done.
I don’t know of any other places where >1.2 is used, but I don’t deny the possibility. I also must state that I don’t know how JoGL handles OpenGL extensions - might it use the GL_ARB_transpose_matrix extension if it’s available?
[quote]It’s easy to fix, though, by pulling the data from the matrix already transposed and call glLoadMatrixf instead - that’s what I’ve done.
[/quote]
Do you have a patch that we can apply to Xith3D renderer classes? This is exactly what I was thinking to do, because of this also seems to be a reason for problems with SiS graphic cards. If you have a patch, can you please submit an issue with attachment?
Yuri
I will add an entension check and the transpose if it is available. It is more effiecient to use the transpose load because that is the way we store our matrices. I didn’t want to incure the overhead of matrix transpose.
Yuri, I’m afraid I can’t see any way to attach files to issues or submit an attachment at time of report. Are we talking about the dev.java.net issues page?
[quote]I will add an entension check and the transpose if it is available. It is more effiecient to use the transpose load because that is the way we store our matrices. I didn’t want to incure the overhead of matrix transpose.
[/quote]
David, in this particular case it’ll make no difference either way - the current code is this:
public static void setTransform( GL gl, Matrix4f mat ) {
int i=0;
trans[i++] = mat.m00;
trans[i++] = mat.m01;
trans[i++] = mat.m02;
trans[i++] = mat.m03;
trans[i++] = mat.m10;
trans[i++] = mat.m11;
trans[i++] = mat.m12;
trans[i++] = mat.m13;
trans[i++] = mat.m20;
trans[i++] = mat.m21;
trans[i++] = mat.m22;
trans[i++] = mat.m23;
trans[i++] = mat.m30;
trans[i++] = mat.m31;
trans[i++] = mat.m32;
trans[i++] = mat.m33;
gl.glLoadTransposeMatrixf(trans);
}
So accessing the vertices in a different order and calling the 1.1 method instead should have no performance hit.
N.B. there’s another call to glLoadTransposeMatrixf in CanvasPeerImpl.drawObjectShadow(), which is harder to cleanly remove.
Heh, yeah I saw that as soon as I looked into the problem. I have checked in a fix to remove the use of loadTransposeMatrix. Should be all set.
That reminds me. I also checked in a feature which should make it easier to diagnose problems. two new options: TRACE and ERROR_CHECK can be activated in code or via -DXITH3D_ERROR_CHECK=TRUE, etc to have the opengl error codes checked on every call. TRACE writes to a debug file every call and its parameters.
Would be nice to be able to specify where TRACE writes the debug file without having to change the Xith3D sourcecode.
Good point. Thats a bit harder to do with our current Option system though. I will think it through.
[quote]Heh, yeah I saw that as soon as I looked into the problem. I have checked in a fix to remove the use of loadTransposeMatrix. Should be all set.
[/quote]
Excellent, thanks!
The drawObjectShadow instance can’t be fixed in-place so easily. As Transform3D.get(float[]) basically does the same as the code I quoted above, could I suggest a Transform3D.getTransposed(float[]) method? This would neatly fix the problem and remove the need for yet another of these blocks in the future as well.
David,
Thanks. Great fix. Could be that this will also fix some other compatibility issues I have on my check-list.
cfmdobbie,
[quote]Yuri, I’m afraid I can’t see any way to attach files to issues or submit an attachment at time of report. Are we talking about the dev.java.net issues page?
[/quote]
Yes, we are taliking about Issuezilla on dev.java.net. It should be [hopefully] possible to add an attachment after you submit an issue - just after submitting you get a confirmation page with an option to add an attachment.
Yuri
good find - SiS support will be nice
Will.
So what is the end result.
Is xith3d dependent on opengl 1.3 ?
Is their an overview of which xith3d graphic card compatibility ?
Thanks for all your help,
Chris
So what is the final specs ?
Is opengl 1.3 required?
Chris