This post was updated on .
Hi Everyone,
I've run into a problem that I've not been able to figure out after over a week of searching around, including this forum. I have a simple (i.e. draw-a-triangle -on-screen-type demo app) that has a vertex and a fragment shader (using version 4.4 core profile) that does not behave as intended in several details. The shaders compile and the program links just fine --i.e. OpenGL reports no errors when checking glGetError. Some information about my system: * Ubuntu 14.04 LTS GNU/Linux 64-bit (I've also tried in Windows 7 64-bit --using dual-boot desktop) * "java -version" command on shell shows: java version "1.7.0_55" OpenJDK Runtime Environment (IcedTea 2.4.7) (7u55-2.4.7-1ubuntu1) OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode) * NVIDIA GTX 770 card with driver 331.79 I'm currently using JOGL 2.1.5 built on March 11, 2014 (http://jogamp.org/deployment/jogamp-current/archive/) The sample code I'm trying to work with, as some of you might anticipate, is from the OpenGL Super Bible 6th Ed. (Yes, I know that is C++ and this is Java.. I've translated the code.) Please note that this is *not* the first time I use JOGL; I've used it before with the fixed pipeline (it was a legacy code-base). This is, however, the first time trying to use shaders with JOGL. I've verified several things in my troubleshooting attempts, trying to rule out possible issues. A few of them include: 1. Re-checked that my graphics card does support OpenGL/GLSL features I'm trying to use (which it does) 2. Checked for errors calling glGetError() in loops after each gl* call, but no errors are reported. 3. Checked OpenGL information reported by the system/driver (it supports OpenGL 4.4 and GLSL 4.4) a. I even tried installing the proprietary driver to at least check if it was an issue with the open implementation, but I've found no noticeable difference 4. I've checked this info with glxinfo, nvidia-settings, and by querying the GLContext and GLProfile objects with JOGL itself: // [...] gl = (GL4) drawable.getGL(); System.out.println("[debug] GL Profile : " + gl.getGLProfile().toString()); System.out.println("[debug] Version Number: " + gl.getContext().getGLSLVersionNumber().toString()); System.out.println("[debug] Version String: " + gl.getContext().getGLSLVersionString().trim()); // // -- shows the following output -- // [debug] GL Profile : GLProfile[GL4bc/GL4bc.hw] [debug] Version Number: 4.40.0 [debug] Version String: #version 440 5. Checked different versions of JOGL, but the behavior was the same. a. Checked if the behavior was specific to GNU/Linux, but I noticed the same behavior on Windows 7) b. Checked that the shader source code that I think is being processed is the code that's actually being submitted to the pipeline (which it is)) 6. Checked driver version 331.79 (OpenGL/GLSL 4.4 made available with 326.29 (see https://developer.nvidia.com/opengl-driver) 7. Verified that I'm sending expected arguments to the JVM (e.g. -Dsun.java2d.d3d=false), though I'm not sure this would make a difference under GNU/Linux I can build and run the C++ demos from the OpenGL SB 6 repository (check github). When I try to draw vertices, I can get a black pixel... but it's always centered and black regardless of what I hard-code into the shader itself. I cannot get the triangle to show up. You only see the color used to clear the background. I've provided what seems to be the more important pieces of source code. Unfortunately, it seems there's no way to nicely format the code, so I'll try my best here.. the overriden init/display methods are up first, and the shaders being used are at the bottom. I have removed most print statements for your sake. Expected Result: A single white triangle with a blue-colored background. Actual Result: The blue-colored background only. There's no triangle. Any and all help troubleshooting this will be appreciated. Please let me know if you need any additional information. I'll check back frequently, but in general it'll be after I return from work (evening US Pacific time zone). Thanks in advance, -xghost PSone: As for IDEs, I've tried both Eclipse Kepler and NetBeans 8.0 PS2: If you'd like to see all the code, I can put it on pastebin or something similar --assuming I can't upload here. -------- java code start -------- @Override public void init(GLAutoDrawable drawable) { gl = (GL4) drawable.getGL(); int vertexShader = gl.glCreateShader(GL4.GL_VERTEX_SHADER); gl.glShaderSource(vertexShader, 1, vertexShaderSource, null); gl.glCompileShader(vertexShader); if(gl.glGetError() != GL.GL_NO_ERROR) System.err.println("[error] Vertex shader compilation failed."); int fragmentShader = gl.glCreateShader(GL4.GL_FRAGMENT_SHADER); gl.glShaderSource(fragmentShader, 1, fragmentShaderSource, null); gl.glCompileShader(fragmentShader); if(gl.glGetError() != GL.GL_NO_ERROR) System.err.println("[error] Fragment shader compilation failed."); program = gl.glCreateProgram(); gl.glAttachShader(program, vertexShader); gl.glAttachShader(program, fragmentShader); gl.glLinkProgram(program); if(gl.glGetError() != GL.GL_NO_ERROR) System.err.println("[error] Program linking failed."); gl.glGenVertexArrays(vertexArray.length, vertexArray, 0); gl.glBindVertexArray(vertexArray[0]); gl.glDeleteShader(vertexShader); gl.glDeleteShader(fragmentShader); } @Override public void display(GLAutoDrawable drawable) { gl = (GL4) drawable.getGL(); gl.glClearBufferfv(GL4.GL_COLOR, 0, bufferClearColor); gl.glUseProgram(program); gl.glPointSize(30.0f); double value = System.currentTimeMillis()/300.0; vertexAttribute.put(0, (float)(Math.sin(value) * 0.5f)); vertexAttribute.put(1, (float)(Math.cos(value) * 0.6f)); gl.glVertexAttrib4fv(0, vertexAttribute); gl.glDrawArrays(GL4.GL_TRIANGLES, 0, 3); }-------- java code end -------- -------- vertex shader start -------- #version 440 core // input vertex attribute layout (location = 0) in vec4 offset; void main(void) { const vec4 v1 = vec4( 0.25, 0.25, 0.5, 1.0); const vec4 v2 = vec4(-0.25, -0.25, 0.5, 1.0); const vec4 v3 = vec4( 0.25, -0.25, 0.5, 1.0); const vec4 vertices[3] = vec4[3](v1, v2, v3); gl_Position = vertices[gl_VertexID] + offset; }-------- vertex shader end -------- -------- fragment shader start -------- #version 440 core out vec4 color; void main(void) { color = vec4(1.0, 1.0, 1.0, 1.0); }-------- fragment shader end -------- |
Administrator
|
Hi
Please try to use a core profile without backward compatibility and try to use this example too: https://github.com/sgothel/jogl/blob/master/src/test/com/jogamp/opengl/test/junit/jogl/demos/es2/RedSquareES2.java
Julien Gouesse | Personal blog | Website
|
Administrator
|
In reply to this post by xghost
I don't see where you clear the
depth buffer via GL_DEPTH_BUFFER_BIT .. <https://www.opengl.org/wiki/Depth_Test> Note on coordinate system: ==================== You use the device default coordinates, which are in normalized device coordinates (NDC) [-1..1] for the x- and y-axis. The z-buffer semantics depend on the depth range, which defaults to [0..1] <https://stackoverflow.com/a/7770714> <https://www.opengl.org/wiki/GLAPI/glDepthRange> |
This post was updated on .
I've enabled GL_DEPTH_TEST in the init(GLAutoDrawable drawable) method: gl = (GL4) drawable.getGL(); gl.glEnable(GL4.GL_DEPTH_TEST); gl.glClearColor(0.0f, 0.0f, 1.0f, 1.0f); // added to replace gl.glClearBufferfv(...) belowI then added the clear in the display(GLAutoDrawable) method, trying a few different things: gl = (GL4) drawable.getGL(); gl.glClear(GL4.GL_DEPTH_BUFFER_BIT | GL4.GL_COLOR_BUFFER_BIT); // gl.glClearBufferfv(GL4.GL_COLOR, 0, bufferClearColor); gl.glUseProgram(program);I'm still getting the same result as before --the blue-cleared background w/ no triangle. This is even if I don't use glClearColor() on init and instead keep using glClearBufferfv() that's currently commented out and only clearing the depth buffer bit, not the color buffer bit. Also, looking at the C++ code from the OpenGL SB 6 (movingtri application), which builds/works fine, the render code is as follows: virtual void render(double currentTime) { static const GLfloat green[] = { 0.0f, 0.25f, 0.0f, 1.0f }; glClearBufferfv(GL_COLOR, 0, green); glUseProgram(program); GLfloat attrib[] = { (float)sin(currentTime) * 0.5f, (float)cos(currentTime) * 0.6f, 0.0f, 0.0f }; glVertexAttrib4fv(0, attrib); glDrawArrays(GL_TRIANGLES, 0, 3); }This is equivalent to the Java code I included.
On the coords topic, perhaps I'm missing something, but the range of the NDC and depth range values seems to be within the valid/accepted range (i.e. within [-1,1] and [0, 1] respectively) in my application. I ran into a few problems trying to build/launch it at first... maybe due to a long day/night. If you could please include what you think is the simplest set of steps to get what you need, I'd appreciate it :) Thanks. |
Administrator
|
On 07/15/2014 01:45 PM, xghost [via jogamp] wrote:
> I've enabled GL_DEPTH_TEST in the init(GLAutoDrawable drawable) method: > > gl = (GL4) drawable.getGL(); > gl.glEnable(GL4.GL_DEPTH_TEST); > gl.glClearColor(0.0f, 0.0f, 1.0f, 1.0f); // added to replace > gl.glClearBufferfv(...) below > > I then added the clear in the display(GLAutoDrawable) method, trying a few > different things: > > gl = (GL4) drawable.getGL(); > gl.glClear(GL4.GL_DEPTH_BUFFER_BIT | GL4.GL_COLOR_BUFFER_BIT); > // gl.glClearBufferfv(GL4.GL_COLOR, 0, bufferClearColor); > gl.glUseProgram(program); > > I'm still getting the same result as before --the blue-cleared background w/ > no triangle. This is even if I don't use glClearColor() on init and instead > keep using glClearBufferfv() that's currently commented out and only clearing > the depth buffer bit, not the color buffer bit. > > Also, looking at the C++ code from the OpenGL SB 6 (movingtri application), > which builds/works fine, the render code is as follows: > > virtual void render(double currentTime) > { > static const GLfloat green[] = { 0.0f, 0.25f, 0.0f, 1.0f }; > glClearBufferfv(GL_COLOR, 0, green); > glUseProgram(program); > > GLfloat attrib[] = { (float)sin(currentTime) * 0.5f, > (float)cos(currentTime) * 0.6f, > 0.0f, 0.0f }; > > glVertexAttrib4fv(0, attrib); > glDrawArrays(GL_TRIANGLES, 0, 3); > } > > This is equivalent to the Java code I included. > > On the coords topic, perhaps I'm missing something, but the range of the NDC > and depth range values seems to be within the valid/accepted range (i.e. > within [-1,1] and [0, 1] respectively) in my application. Can you please provide a complete tar ball w/ your latest test code ? Best ofc if you would add a unit test for JOGL, provided as a git-patch or accessible via a public git repository. Then I would not need to do it :) I will test you code then .. surely interesting. ~Sven > > Thanks. > > ------------------------------------------------------------------------------ > If you reply to this email, your message will be added to the discussion below: > http://forum.jogamp.org/Need-Help-Solving-OpenGL-GLSL-4-4-Issues-tp4032557p4032573.html > > To start a new topic under jogl, email [hidden email] > To unsubscribe from jogl, click here > < > NAML > <http://forum.jogamp.org/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> > -- health & wealth mailto:[hidden email] ; http://jausoft.com land : +49 (471) 4707742 ; fax : +49 (471) 4707741 Timezone CET: PST+9, EST+6, UTC+1 signature.asc (894 bytes) Download Attachment |
Hi Sven, I've made the archive available at: https://filetea.me/t1sezrPxDIlSQKYjjVhMV7OmQ I added a few screenshots so that you can see what I see first hand when comparing between JOGL and C++ Super Bible 6. The relevant Java code will be Demo3, Demo4, and Project1. Note that there's some library code included, but most of it is not being used in the branch that I've provided. If you have any questions, please be sure to let me know. I'd have to be able to successfully build/run unit tests locally first. I'm actually going through some material because I'm preparing for a masters project where I'll need to use OpenGL/GLSL 4.4, but I'd be happy to help out with something if I can get it going. I'd need to get some time to more carefully go through the build steps in the Wiki. Who knows, maybe both projects could benefit ;) Thanks. |
Try this sample, I chucked it together from code I had (so it isn't well documented and you need to fix package name et c) but it works.
Edit: oh and you probably need to fix the version line in the shader, I'm on Mac which only supports OpenGL 4.1 --------------------- package nu.zoom.corridors.client; import com.jogamp.common.nio.Buffers; import com.jogamp.newt.event.WindowAdapter; import com.jogamp.newt.event.WindowEvent; import com.jogamp.newt.opengl.GLWindow; import com.jogamp.opengl.util.Animator; import com.jogamp.opengl.util.glsl.ShaderCode; import com.jogamp.opengl.util.glsl.ShaderProgram; import java.io.ByteArrayOutputStream; import java.io.IOException; import java.nio.FloatBuffer; import javax.media.nativewindow.WindowClosingProtocol; import javax.media.opengl.DebugGL4; import javax.media.opengl.GL; import javax.media.opengl.GL4; import javax.media.opengl.GLAutoDrawable; import javax.media.opengl.GLCapabilities; import javax.media.opengl.GLEventListener; import javax.media.opengl.GLException; import javax.media.opengl.GLProfile; import javax.media.opengl.TraceGL4; /** * * @author Johan Maasing <johan@zoom.nu> */ public class TriangleSample { // http://www.opengl.org/wiki/Vertex_Specification final int[] vas = new int[1]; final int[] vbos = new int[1]; private int shaderPosition; private int flatColorShaderProgram = 0; private Animator animator; private GLWindow glWindow; private boolean windowDestroyed = false; private static final float[] triangle = new float[]{ 0.0f, -1.0f, 0.7f, 1.0f, 1.0f, 0.7f, -1.0f, 1.0f, 0.7f }; private final String vertShader = "#version 410 core\n" + "in vec3 position;\n" + "out vec2 uv ;\n" + "void main(void)\n" + "{" + " uv = (position.xy + 1.0f)/2.0f;" + " gl_Position = vec4(position, 1.0f) ; \n" + "}"; private final String flatColorfragShader = "#version 410 core\n" + "in vec2 uv;\n" + "layout(location = 0) out vec4 fragColor ;\n" + "void main(void)\n" + "{" + " fragColor = vec4(uv.y, uv.y, uv.y, uv.x) ; \n" + "}"; public static void main(String[] args) throws Exception { TriangleSample app = new TriangleSample(); app.run(); } private void stop(String msg) { if (this.animator != null) { this.animator.stop(); } if (this.glWindow != null) { this.windowDestroyed = true; this.glWindow.destroy(); } System.out.println(msg); } private void run() throws Exception { final GLCapabilities caps = new GLCapabilities(GLProfile.get(GLProfile.GL4)); caps.setBackgroundOpaque(true); caps.setDoubleBuffered(true); caps.setDepthBits(8); caps.setSampleBuffers(false); this.glWindow = GLWindow.create(caps); this.glWindow.setTitle("FBO Test"); this.glWindow.setSize(640, 480); this.glWindow.setUndecorated(false); this.glWindow.setPointerVisible(true); this.glWindow.setVisible(true); this.glWindow.setFullscreen(false); this.glWindow.setDefaultCloseOperation(WindowClosingProtocol.WindowClosingMode.DISPOSE_ON_CLOSE); this.glWindow.addWindowListener(new WindowAdapter() { @Override public void windowDestroyNotify(WindowEvent we) { if (!windowDestroyed) { stop("Window destroyed"); } } }); this.glWindow.addGLEventListener(new GLEventListener() { @Override public void reshape(GLAutoDrawable drawable, int x, int y, int width, int height) { GL gl = drawable.getGL(); gl.glViewport(x, y, width, height); } @Override public void init(GLAutoDrawable drawable) { GL gl = drawable.getGL(); if (gl.isGL4core()) { drawable.setGL(new TraceGL4(new DebugGL4(gl.getGL4()), System.out)); GL4 gL4 = drawable.getGL().getGL4(); try { TriangleSample.this.init(gL4); } catch (IOException ex) { stop(ex.getLocalizedMessage()); } } else { stop("Not a GL4 core context"); } } @Override public void dispose(GLAutoDrawable drawable) { } @Override public void display(GLAutoDrawable drawable) { GL4 gL4 = drawable.getGL().getGL4(); TriangleSample.this.display(gL4); } }); this.animator = new Animator(glWindow); this.animator.start(); } private void init(GL4 gl) throws IOException { gl.glClearColor(1.0f, 0.0f, 1.0f, 1.0f); gl.glClearDepthf(1.0f); gl.glEnable(GL4.GL_CULL_FACE); gl.glCullFace(GL4.GL_BACK); gl.glFrontFace(GL4.GL_CCW); // Compile and link the shader then query the shader for the location of the vertex input variable final ShaderCode vertexShader = compileShader(gl, vertShader, GL4.GL_VERTEX_SHADER); final ShaderCode flatColorFragmentShader = compileShader(gl, flatColorfragShader, GL4.GL_FRAGMENT_SHADER); this.flatColorShaderProgram = linkShader(gl, vertexShader, flatColorFragmentShader); this.shaderPosition = gl.glGetAttribLocation(this.flatColorShaderProgram, "position"); // Create the mesh createBuffer(gl, shaderPosition, triangle, 3); } public ShaderCode compileShader(final GL4 gl4, final String source, final int shaderType) throws IOException { final String[][] sources = new String[1][1]; sources[0] = new String[]{source}; ShaderCode shaderCode = new ShaderCode(shaderType, sources.length, sources); final ByteArrayOutputStream baos = new ByteArrayOutputStream(); final boolean compiled = shaderCode.compile(gl4, System.err); if (!compiled) { System.err.println("Unable to compile " + source); System.exit(1); } return shaderCode; } private int linkShader(GL4 gl, final ShaderCode vertexShader, final ShaderCode textureFragmentShader) throws GLException { ShaderProgram program = new ShaderProgram(); program.init(gl); program.add(vertexShader); program.add(textureFragmentShader); program.link(gl, System.out); final boolean validateProgram = program.validateProgram(gl, System.out); if (!validateProgram) { System.err.println("Unable to link shader"); System.exit(1); } return program.program(); } private void display(GL4 gl) { // Clear the default framebuffer gl.glBindFramebuffer(GL4.GL_DRAW_FRAMEBUFFER, 0); gl.glClear(GL4.GL_COLOR_BUFFER_BIT | GL4.GL_DEPTH_BUFFER_BIT); gl.glUseProgram(this.flatColorShaderProgram); gl.glBindVertexArray(this.vas[0]); gl.glEnableVertexAttribArray(this.shaderPosition); gl.glDrawArrays(GL4.GL_TRIANGLES, 0, 3); } public void createBuffer(final GL4 gl, final int shaderAttribute, float[] values, final int valuesPerVertex) { gl.glGenVertexArrays(this.vas.length, this.vas, 0); gl.glBindVertexArray(this.vas[0]); gl.glGenBuffers(this.vbos.length, this.vbos, 0); gl.glBindBuffer(GL4.GL_ARRAY_BUFFER, this.vbos[0]); FloatBuffer fbVertices = Buffers.newDirectFloatBuffer(values); final int bufferSizeInBytes = values.length * Buffers.SIZEOF_FLOAT; gl.glBufferData(GL4.GL_ARRAY_BUFFER, bufferSizeInBytes, fbVertices, GL4.GL_STATIC_DRAW); gl.glVertexAttribPointer(shaderAttribute, valuesPerVertex, GL4.GL_FLOAT, false, 0, 0); } } |
This post was updated on .
I tried your sample and it seems to work just fine 'as is'. I've uploaded a picture of the output while it runs here for confirmation: The code also works after changing the shaders to use version 440 from 410. I did, however, notice that when you exit, an exception is thrown and a significant amount of output is produced. Thanks for the help. I'm including the console output during its last moments below, triggered by closing the window. EDIT: The application works regardless of whether the -Dsun.java2d.d3d=false argument is sent to the JVM or not. I expected this to be the case at least under GNU/Linux. ---------- glDrawArrays(<int> 0x4, <int> 0x0, <int> 0x3) glBindFramebuffer(<int> 0x8CA9, <int> 0x0) glClear(<int> 0x4100) glUseProgram(<int> 0x3) glBindVertexArray(<int> 0x2) glEnableVertexAttribArray(<int> 0x0) glDrawArrays(<int> 0x4, <int> 0x0, <int> 0x3) Catched Exception on thread main-Display-.x11_:0-1-EDT-1 javax.media.opengl.GLException: Surface not ready to lock: X11OnscreenGLXDrawable[Realized true, Factory jogamp.opengl.x11.glx.X11GLXDrawableFactory@7de69f2, Handle 0x0, Surface jogamp.newt.driver.x11.WindowDriver[Config X11GLXGraphicsConfiguration[X11GraphicsScreen[X11GraphicsDevice[type .x11, connection :0, unitID 0, handle 0x7f1824019be0, owner true, ResourceToolkitLock[obj 0x1afd92e7, isOwner false, <7db78988, 1ca68033>[count 0, qsz 0, owner <NULL>]]], idx 0], visualID 0x27, fbConfigID 0x10d, requested GLCaps[rgba 8/8/8/0, opaque, accum-rgba 0/0/0/0, dp/st/ms 8/0/0, dbl, mono , hw, GLProfile[GL4/GL4.hw], on-scr[.]], chosen GLCaps[glx vid 0x27, fbc 0x10d: rgba 8/8/8/0, opaque, accum-rgba 16/16/16/16, dp/st/ms 24/0/0, dbl, mono , hw, GLProfile[GL4/GL4.hw], on-scr[.]]] , NEWT-Screen[.x11_:0-1-s0, idx 0, refCount 1, vsize [ 0 / 0 1920 x 1080 ], X11GraphicsScreen[X11GraphicsDevice[type .x11, connection :0, unitID 0, handle 0x7f1824001040, owner true, ResourceToolkitLock[obj 0x772aa2f6, isOwner true, <10310199, 15fec1d>[count 1, qsz 0, owner <main-Display-.x11_:0-1-EDT-1>]]], idx 0], NEWT-Display[.x11_:0-1, excl false, refCount 0, hasEDT true, edtRunning true, null], monitors: null] , ParentWindow null , ParentWindowHandle 0x0 (false) , WindowHandle 0x0 , SurfaceHandle 0x0 (lockedExt window false, surface false) , Pos 456/232 (auto false), size 640x480 , Visible false, focus false , Undecorated false (false) , AlwaysOnTop false, Fullscreen false , WrappedSurface null , ChildWindows 0, SurfaceUpdatedListeners num 0 [], WindowListeners num 2 [com.jogamp.newt.opengl.GLWindow$2@4086649f, ray.cg.demos.demo5.Demo5$1@373823d1, ], MouseListeners num 0 [], PointerGestures default true, custom 0 [], KeyListeners num 0 [], windowLock <46b78aa9, 3bf08184>[count 2, qsz 0, owner <main-Display-.x11_:0-1-EDT-1>], surfaceLockCount 0]] at jogamp.opengl.GLContextImpl.destroy(GLContextImpl.java:386) at jogamp.opengl.GLDrawableHelper.disposeGL(GLDrawableHelper.java:1042) at jogamp.opengl.GLAutoDrawableBase.destroyImplInLock(GLAutoDrawableBase.java:350) at com.jogamp.newt.opengl.GLWindow.access$300(GLWindow.java:111) at com.jogamp.newt.opengl.GLWindow$GLLifecycleHook.destroyActionInLock(GLWindow.java:490) at jogamp.newt.WindowImpl$DestroyAction.run(WindowImpl.java:1107) at jogamp.newt.WindowImpl.runOnEDTIfAvail(WindowImpl.java:2006) at jogamp.newt.WindowImpl.destroy(WindowImpl.java:1170) at com.jogamp.newt.opengl.GLWindow.destroy(GLWindow.java:431) at ray.cg.demos.demo5.Demo5.stop(Demo5.java:94) at ray.cg.demos.demo5.Demo5.access$1(Demo5.java:88) at ray.cg.demos.demo5.Demo5$1.windowDestroyNotify(Demo5.java:117) at jogamp.newt.WindowImpl.consumeWindowEvent(WindowImpl.java:3520) at jogamp.newt.WindowImpl.sendWindowEvent(WindowImpl.java:3452) at jogamp.newt.WindowImpl$DestroyAction.run(WindowImpl.java:1086) at jogamp.newt.DisplayImpl.runOnEDTIfAvail(DisplayImpl.java:434) at jogamp.newt.WindowImpl.runOnEDTIfAvail(WindowImpl.java:2008) at jogamp.newt.WindowImpl.destroy(WindowImpl.java:1170) at com.jogamp.newt.opengl.GLWindow.destroy(GLWindow.java:431) at jogamp.opengl.GLAutoDrawableBase.destroyAvoidAwareOfLocking(GLAutoDrawableBase.java:300) at jogamp.opengl.GLAutoDrawableBase.defaultWindowDestroyNotifyOp(GLAutoDrawableBase.java:268) at com.jogamp.newt.opengl.GLWindow.access$000(GLWindow.java:111) at com.jogamp.newt.opengl.GLWindow$1.run(GLWindow.java:123) at jogamp.newt.WindowImpl.windowDestroyNotify(WindowImpl.java:3747) at jogamp.newt.driver.x11.DisplayDriver.DispatchMessages0(Native Method) at jogamp.newt.driver.x11.DisplayDriver.dispatchMessagesNative(DisplayDriver.java:113) at jogamp.newt.DisplayImpl.dispatchMessages(DisplayImpl.java:733) at jogamp.newt.DisplayImpl$7.run(DisplayImpl.java:656) at jogamp.newt.DefaultEDTUtil$NEDT.run(DefaultEDTUtil.java:341) javax.media.opengl.GLException: Error making context 0x7f18240314e0 current on Thread main-Display-.x11_:0-1-EDT-1 with display 0x7f1824019be0, drawableWrite 0x0, drawableRead 0x0 - X11GLXContext [Version 4.4 (Core profile, arb, ES2 compat, ES3 compat, FBO, hardware) - 4.4.0 NVIDIA 331.79 [GL 4.4.0, vendor 331.79.0 (NVIDIA 331.79)], options 0x1c05, this 0x6e16ffd, handle 0x7f18240314e0, isShared false, TraceGL4bc [this 0x6819f939 implementing javax.media.opengl.GL4bc, downstream: DebugGL4bc [this 0x1394294 implementing javax.media.opengl.GL4bc, downstream: jogamp.opengl.gl4.GL4bcImpl@5642032c ] ], quirks: [NoDoubleBufferedPBuffer, NoSetSwapIntervalPostRetarget], Drawable: X11OnscreenGLXDrawable[Realized true, Factory jogamp.opengl.x11.glx.X11GLXDrawableFactory@7de69f2, Handle 0x0, Surface jogamp.newt.driver.x11.WindowDriver[Config X11GLXGraphicsConfiguration[X11GraphicsScreen[X11GraphicsDevice[type .x11, connection :0, unitID 0, handle 0x7f1824019be0, owner true, ResourceToolkitLock[obj 0x1afd92e7, isOwner true, <7db78988, 1ca68033>[count 1, qsz 0, owner <main-Display-.x11_:0-1-EDT-1>]]], idx 0], visualID 0x27, fbConfigID 0x10d, requested GLCaps[rgba 8/8/8/0, opaque, accum-rgba 0/0/0/0, dp/st/ms 8/0/0, dbl, mono , hw, GLProfile[GL4/GL4.hw], on-scr[.]], chosen GLCaps[glx vid 0x27, fbc 0x10d: rgba 8/8/8/0, opaque, accum-rgba 16/16/16/16, dp/st/ms 24/0/0, dbl, mono , hw, GLProfile[GL4/GL4.hw], on-scr[.]]] , NEWT-Screen[.x11_:0-1-s0, idx 0, refCount 1, vsize [ 0 / 0 1920 x 1080 ], X11GraphicsScreen[X11GraphicsDevice[type .x11, connection :0, unitID 0, handle 0x7f1824001040, owner true, ResourceToolkitLock[obj 0x772aa2f6, isOwner true, <10310199, 15fec1d>[count 1, qsz 0, owner <main-Display-.x11_:0-1-EDT-1>]]], idx 0], NEWT-Display[.x11_:0-1, excl false, refCount 0, hasEDT true, edtRunning true, null], monitors: null] , ParentWindow null , ParentWindowHandle 0x0 (false) , WindowHandle 0x0 , SurfaceHandle 0x0 (lockedExt window false, surface false) , Pos 456/232 (auto false), size 640x480 , Visible false, focus false , Undecorated false (false) , AlwaysOnTop false, Fullscreen false , WrappedSurface null , ChildWindows 0, SurfaceUpdatedListeners num 0 [], WindowListeners num 2 [com.jogamp.newt.opengl.GLWindow$2@4086649f, ray.cg.demos.demo5.Demo5$1@373823d1, ], MouseListeners num 0 [], PointerGestures default true, custom 0 [], KeyListeners num 0 [], windowLock <46b78aa9, 3bf08184>[count 3, qsz 0, owner <main-Display-.x11_:0-1-EDT-1>], surfaceLockCount 1]], direct true] at jogamp.opengl.x11.glx.X11GLXContext.makeCurrentImpl(X11GLXContext.java:417) at jogamp.opengl.GLContextImpl.makeCurrentWithinLock(GLContextImpl.java:723) at jogamp.opengl.GLContextImpl.makeCurrent(GLContextImpl.java:561) at jogamp.opengl.GLContextImpl.makeCurrent(GLContextImpl.java:518) at jogamp.opengl.GLDrawableHelper.disposeGL(GLDrawableHelper.java:1030) at jogamp.opengl.GLAutoDrawableBase.destroyImplInLock(GLAutoDrawableBase.java:350) at com.jogamp.newt.opengl.GLWindow.access$300(GLWindow.java:111) at com.jogamp.newt.opengl.GLWindow$GLLifecycleHook.destroyActionInLock(GLWindow.java:490) at jogamp.newt.WindowImpl$DestroyAction.run(WindowImpl.java:1107) at jogamp.newt.WindowImpl.runOnEDTIfAvail(WindowImpl.java:2006) at jogamp.newt.WindowImpl.destroy(WindowImpl.java:1170) at com.jogamp.newt.opengl.GLWindow.destroy(GLWindow.java:431) at ray.cg.demos.demo5.Demo5.stop(Demo5.java:94) at ray.cg.demos.demo5.Demo5.access$1(Demo5.java:88) at ray.cg.demos.demo5.Demo5$1.windowDestroyNotify(Demo5.java:117) at jogamp.newt.WindowImpl.consumeWindowEvent(WindowImpl.java:3520) at jogamp.newt.WindowImpl.sendWindowEvent(WindowImpl.java:3452) at jogamp.newt.WindowImpl$DestroyAction.run(WindowImpl.java:1086) at jogamp.newt.DisplayImpl.runOnEDTIfAvail(DisplayImpl.java:434) at jogamp.newt.WindowImpl.runOnEDTIfAvail(WindowImpl.java:2008) at jogamp.newt.WindowImpl.destroy(WindowImpl.java:1170) at com.jogamp.newt.opengl.GLWindow.destroy(GLWindow.java:431) at jogamp.opengl.GLAutoDrawableBase.destroyAvoidAwareOfLocking(GLAutoDrawableBase.java:300) at jogamp.opengl.GLAutoDrawableBase.defaultWindowDestroyNotifyOp(GLAutoDrawableBase.java:268) at com.jogamp.newt.opengl.GLWindow.access$000(GLWindow.java:111) at com.jogamp.newt.opengl.GLWindow$1.run(GLWindow.java:123) at jogamp.newt.WindowImpl.windowDestroyNotify(WindowImpl.java:3747) at jogamp.newt.driver.x11.DisplayDriver.DispatchMessages0(Native Method) at jogamp.newt.driver.x11.DisplayDriver.dispatchMessagesNative(DisplayDriver.java:113) at jogamp.newt.DisplayImpl.dispatchMessages(DisplayImpl.java:733) at jogamp.newt.DisplayImpl$7.run(DisplayImpl.java:656) at jogamp.newt.DefaultEDTUtil$NEDT.run(DefaultEDTUtil.java:341) Thread[main-Display-.x11_:0-1-EDT-1,5,main]: Warning: Default-EDT about (2) to stop, task executed. Remaining tasks: 1 - Thread[main-Display-.x11_:0-1-EDT-1,5,main] Window destroyed X11Util.Display: Shutdown (JVM shutdown: true, open (no close attempt): 2/2, reusable (open, marked uncloseable): 0, pending (open in creation order): 2) X11Util: Open X11 Display Connections: 2 X11Util: Open[0]: NamedX11Display[:0, 0x7f1824001040, refCount 1, unCloseable false] X11Util: Open[1]: NamedX11Display[:0, 0x7f1824019be0, refCount 1, unCloseable false] |
This post was updated on .
Hey all,
It's been a few days. I've tried a few other things, but have not been successful yet. I'm posting the code of a simple demo below. It displays a large pixel on the center using a vertex and fragment shader. The background's color alternates, but the large pixel's position and color are hardcoded in the fragment shader. Here's the thing: No matter what values I enter into the shaders, I cannot alter the pixel's position on screen and I cannot alter the pixel's color. Note that the pixel's black color does NOT match the fragment's RGB component values. (See picture below.) If you think I'm missing something on the OpenGL side of things (i.e. not in the shader code), I'm open to suggestions. I'd appreciate if someone else could take a few minutes to try this code and report results. Of particular interest is tweaking the hard-coded shader values to see if you can actually manipulate the pixel's color by editing fragment shader values and also its position on the vertex shader. Note that the shaders seem to be working to some extent because removing the shader program causes the pixel to go away. Thanks in advance. PS: Note that there're 2 classes and that you'll also need to update package names, etc. -------------- /** * * This program is free software: you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation, either version 3 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program. If not, see <http://www.gnu.org/licenses/>. */ package ray.cg.demos.demo3; import java.nio.FloatBuffer; import javax.media.opengl.GL4; import javax.media.opengl.GLAutoDrawable; import ray.cg.lib.DemoFrame; import com.jogamp.opengl.util.Animator; public class Demo3 extends DemoFrame { private static final long serialVersionUID = 1L; private int renderingProgram; private final int[] vertexArray; public Demo3() { super("Ch2 Pg18"); super.initOpenGL(); setVisible(true); vertexArray = new int[1]; Animator animator = new Animator(canvas); animator.start(); } @Override public void init(GLAutoDrawable drawable) { GL4 gl = (GL4) drawable.getGL(); renderingProgram = createRenderingProgram(gl); gl.glGenVertexArrays(vertexArray.length, vertexArray, 0); gl.glBindVertexArray(vertexArray[0]); } @Override public void display(GLAutoDrawable drawable) { GL4 gl = (GL4) drawable.getGL(); FloatBuffer color = FloatBuffer.allocate(4); color.put(0, (float) (Math.sin(System.currentTimeMillis()/100.0)*0.5 + 0.5)); color.put(1, (float) (Math.cos(System.currentTimeMillis()/100.0)*0.5 + 0.5)); color.put(2, 0.0f); color.put(3, 1.0f); gl.glClearBufferfv(GL4.GL_COLOR, 0, color); gl.glUseProgram(renderingProgram); gl.glPointSize(60.0f); gl.glDrawArrays(GL4.GL_POINTS, 0, 1); } private int createRenderingProgram(GL4 gl) { String[] vertexShaderSource = new String[] { "#version 440 core \n", " \n", "void main(void) \n", "{ \n", " gl_Position = vec4(0.0, 0.0, 0.5, 1.0); \n", "} \n" }; String[] fragmentShaderSource = new String[] { "#version 440 core \n", " \n", "out vec4 color; \n", " \n", "void main(void) \n", "{ \n", " color = vec4(0.0, 0.8, 1.0, 1.0); \n", "} \n" }; int vertexShader = gl.glCreateShader(GL4.GL_VERTEX_SHADER); gl.glShaderSource(vertexShader, 1, vertexShaderSource, null); gl.glCompileShader(vertexShader); int fragmentShader = gl.glCreateShader(GL4.GL_FRAGMENT_SHADER); gl.glShaderSource(fragmentShader, 1, fragmentShaderSource, null); gl.glCompileShader(fragmentShader); int program = gl.glCreateProgram(); gl.glAttachShader(program, vertexShader); gl.glAttachShader(program, fragmentShader); gl.glLinkProgram(program); gl.glDeleteShader(vertexShader); gl.glDeleteShader(fragmentShader); return program; } public static void main(String[] args) { new Demo3(); } @Override public void dispose(GLAutoDrawable drawable) {} @Override public void reshape(GLAutoDrawable drawable, int x, int y, int width, int height) {} }--------------- /** * * This program is free software: you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation, either version 3 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program. If not, see <http://www.gnu.org/licenses/>. */ package ray.cg.lib; import javax.media.opengl.GLEventListener; import javax.media.opengl.awt.GLCanvas; import javax.swing.JFrame; import javax.swing.WindowConstants; public abstract class DemoFrame extends JFrame implements GLEventListener { private static final long serialVersionUID = 1L; protected GLCanvas canvas; public DemoFrame(String title) { // XXX: Do NOT setup the GLCanvas in the ctor. See below. setTitle(title); setSize(450, 300); setResizable(true); setLocationRelativeTo(null); setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE); } public void initOpenGL() { // XXX: Client class should control when OpenGL gets initialized. // Client may need to setup things OpenGL needs (e.g. read shader // source) before it can get initialized to avoid crashes. canvas = new GLCanvas(); canvas.addGLEventListener(this); getContentPane().add(canvas); } } |
That's not how shader based OpenGL works. You have to do everything yourself in the shader code, right now your shader hardcodes both position and color so that's what you get.
On the OpenGL side you must set up input data that your shader reads. There are many ways to do so but usually it involves creating vertex buffers with data that is different for each vertex. Or by using shader uniforms for data that is the same for all vertices. Here is a good tutorial I used when learning modern OpenGL: http://www.arcsynthesis.org/gltut/ |
Administrator
|
This ported examples are worth a look too:
https://github.com/elect86/modern-jogl-examples
Julien Gouesse | Personal blog | Website
|
This post was updated on .
In reply to this post by jmaasing
Sorry, but I'm not sure I'm correctly following what you're referring to by simply saying 'that' here. Which part, specifically, were you referring to? Perhaps there's a misunderstanding here. For this specific demo, I want the values in the shaders to be hard-coded. The problem is that, when you edit the hard-coded data and set it to other values and re-build/re-launch the application, contrary to expectations, there is no visible difference. This is why I pointed out that the black color being displayed does not match the hard-coded values being used in the fragment shader (note that they're not all 0.0's in RGB, so it shouldn't be black). For example, if you edit the fragment shader RGB component values to all be 1.0's, then you'd expect the output to be white, correct? Well, I don't see that happening when I'm using JOGL, though in C++ it works fine (see bottom). When you say that's not how it works, are you trying to suggest that the behaviour I'm seeing in JOGL is actually correct and that my expectations for this demo are wrong, despite the fact that the OpenGL SB6 C++ demo doing the same thing works just fine? As I've mentioned previously, the OpenGL SB 6 book reference code has this sample as a simple introductory application and it works as I'd expect --i.e. change hard-coded shader values, rebuild, and it looks different. This is what I expected to see with JOGL, but I'm not and you seem to suggest that I'm getting what I should be getting. Please let me know if I've misunderstood what you're trying to say. I think I'm aware of this, but the goal of this demo is different, as I attempted to explain above. There's also no point in building something more complex if the simple things are not behaving as expected.
Thanks for the additional reference and samples. I was already using the OpenGL Super Bible 6, but I'll certainly take a look. Currently though, I'm trying to find a more immediate/specific explanation for what I've described. Thanks again for the help. ----------------- Below is a small diff of a hard-coded fragment shader I modified and the actual output, which is consistent with expectations in the C++ based application, but not the result I get in the JOGL equivalent. diff --git a/src/singletri/singletri.cpp b/src/singletri/singletri.cpp index 54160df..792170f 100644 --- a/src/singletri/singletri.cpp +++ b/src/singletri/singletri.cpp @@ -58,7 +58,7 @@ class singlepoint_app : public sb6::application " \n" "void main(void) \n" "{ \n" - " color = vec4(0.0, 0.8, 1.0, 1.0); \n" + " color = vec4(1.0, 1.0, 1.0, 1.0); \n" "} \n" }; |
Oh yeah, now I see, I jumped to conclusions there and got it wrong, sorry to confuse the issue.
|
No problem. Were you able to try the sample code I posted above and, if so, what are your thoughts on it? So far, no one has pointed out any obvious problem in my code... I was hoping that another set of eyes would be beneficial. I'd appreciate any help here. I'm not currently aware of what my Java code might be missing, but I'm assuming that it must be missing something, because otherwise the alternative conclusion is that there's a bug in JOGL, and that seems unlikely right now. Thanks in advance. |
Administrator
|
Hi
I can't run your code at home as my hardware isn't capable enough. However, why do you expect to see a triangle whereas you use GL_POINTS with glDrawArrays (and you ask it to draw a single primitive)? Why do you put no vertex data into the VAO? I don't see how this code could draw a triangle.
Julien Gouesse | Personal blog | Website
|
I've been using different examples as part of my posts to make different points or point out different details. I am not expecting a call using GL_POINTS to draw triangles.. I've simply posted code from different demos to illustrate different things and I thought I had been clear enough on these details. I suppose this could be easier to miss by speed-reading(?) To be more precise, the Java code I posted that specifically tries to draw a pixel was to show the problem of being unable to alter fragment colors or vertex positions with hard-coded shaders and I used a simple triangle drawing application from the OpenGL Super Bible 6 codebase to illustrate the point I was making --that it works fine when I'm not using JOGL. I could've chosen some other sample to illustrate the same thing (e.g. the one that draws a single pixel), but the choice does not make a difference on what I'm trying to point out... The code I posted about the triangle which, if you look in one of my earlier posts, does use GL_TRIANGLES in the call to glDrawArrays and specifies 3 vertices should be used.. I did not place data in a VAO because it is not a requirement for the samples to do what I need them to do in their current form. (If you think this understanding is wrong, please do point it out, but please look at the examples below first.) To illustrate, consider the following code (in C++) that draws the primitives by hard-coding the values in the shader because, again, these are supposed to be simple demos. 1. https://github.com/openglsuperbible/sb6code/blob/master/src/singlepoint/singlepoint.cpp 2. https://github.com/openglsuperbible/sb6code/blob/master/src/singletri/singletri.cpp Yes, a VAO is created/destroyed, but data is never put into it. The shaders also do not take inputs from the C++ code (or the Java code in my case) because the data for the primitives is hard-coded in the shader for these demos. Again, this is intentional. When I compare the working C++ code to the JOGL-based code that I wrote, I fail to see a difference when we compare equivalent examples, and I certainly do not see why the C++ sample works fine while the JOGL-based analogue does not. I hope this clarifies what seems to be a misunderstanding here. Please let me know if you still have unanswered questions or if the questions I've already addressed are not as clear as I had hoped. Thanks. |
Administrator
|
Ok, it's crystal clear now, I understand what you're trying to achieve. Your triangle isn't displayed when using JOGL whereas each vertex has a correct position set in the vertex shader. Please use a PMVMatrix and ShaderCode/ShaderProgram/ShaderState like in the example I quoted in order to eliminate some sources of mistakes. I don't know why it doesn't work as is.
Julien Gouesse | Personal blog | Website
|
In reply to this post by xghost
Vacation today so I had some time to test your code :-)
I haven't fixed it yet but there are two problems I saw right away, if you add public void init(GLAutoDrawable drawable) { drawable.setGL(new DebugGL4((GL4) drawable.getGL())); GL4 gl = (GL4) drawable.getGL(); You will see that OpenGL complains about invalid operation (at least on my platform): Exception in thread "main-AWTAnimator" java.lang.RuntimeException: javax.media.opengl.GLException: Thread[AWT-EventQueue-0,6,main] glGetError() returned the following error codes after a call to glGenVertexArrays(<int> 0x1, <[I>, <int> 0x0): GL_INVALID_OPERATION ( 1282 0x502), Also, your shaders are not correct (on strict drivers they would not even compile I guess) since you use doubles when they should be floats, this is how it ought to be written: gl_Position = vec4(0.0f, 0.0f, 0.5f, 1.0f); If you look at the sample code I posted I use JOGL classes (ShaderProgram et c) to compile the shaders, they can help in presenting the compilation/linking errors. If you want to use glCompileShader straight up you really should check for GL errors after each step to verify that the shader compiled/linked. Note that there is a large difference in how "forgiving" drivers are with these kinds of errors, maybe your driver understands and compiles even though it strictly isn't correct. (another disclaimer; I'm stuck on Mac OpenGL 4.1 so maybe these things have changed in later versions). |
Administrator
|
Yes, he should call glGetShaderInfoLog after compiling and glGetProgramInfoLog after linking, am I wrong?
Julien Gouesse | Personal blog | Website
|
Yeah, and also "Each shader object has a boolean status, COMPILE_STATUS, that is modified as a result of compilation. This status can be queried with GetShaderiv" Or simply use the very convenient JOGL classes |
Free forum by Nabble | Edit this page |