#jogamp @ irc.freenode.net - 20150111 05:05:06 (UTC)

20150111 05:05:06 -jogamp- Previous @ http://jogamp.org/log/irc/jogamp_20150110050505.html
20150111 05:05:06 -jogamp- This channel is logged @ http://jogamp.org/log/irc/jogamp_20150111050506.html
20150111 08:01:29 * monsieur_max (~maxime@anon) has joined #jogamp
20150111 09:25:23 * monsieur_max (~maxime@anon) Quit (Ping timeout: 240 seconds)
20150111 09:30:59 * GiGurra (~GiGurra@anon) has joined #jogamp
20150111 09:32:37 <GiGurra> Hi. I spoke to goussej on the forums (http://forum.jogamp.org/Help-How-to-Build-an-executable-JAR-with-SBT-JOGL-Scala-td4033830.html#none) about a jar loading/packaging problem and he told me to come here and see if anyone knew how to solve my problem
20150111 09:33:12 <GiGurra> In particular he told me to contact someone named Mark, not sure if Mark is here atm but I dont see his name on the right
20150111 09:42:02 * monsieur_max (~maxime@anon) has joined #jogamp
20150111 10:03:05 * gouessej (52794ad6@anon) has joined #jogamp
20150111 10:03:08 <gouessej> Hi
20150111 10:03:36 <gouessej> GiGurra: Please read my reply
20150111 10:04:31 <gouessej> GiGurra: rmk0 knows Maven far better than me
20150111 10:09:22 <GiGurra> Thanks, I'll try to figure out some solution. Do you know if the question has come up before?
20150111 10:09:51 <GiGurra> Or are there too few people interested in both JOGL and scala
20150111 10:21:06 <gouessej> I don't think that the question has been asked before
20150111 10:21:56 <gouessej> Why not contacting the sbt maintainers to see what they suggest?
20150111 10:37:24 <GiGurra> Yes I'm thinking about that too
20150111 10:37:51 <GiGurra> but I'm not sure. Assembly is not part of sbt
20150111 10:37:53 <GiGurra> it's justa plugin
20150111 10:38:08 <GiGurra> sbt does not provide any ways for building an executable jar afaik, so you need to use one of the packaging tools
20150111 10:38:51 <GiGurra> First id need to figure out how the file structure inside my jar should work for JOGL to run. Then once I know that, Ican contact the sbt assembly, pack or one-jar people and see if they want to support it
20150111 10:39:53 * monsieur_max1 (~maxime@anon) has joined #jogamp
20150111 10:44:07 * monsieur_max (~maxime@anon) Quit (Ping timeout: 264 seconds)
20150111 10:54:21 <gouessej> Then, you should look at the paragraph I quoted
20150111 10:55:09 <gouessej> It shows in which location you must put the native libraries to allow GlueGen to find them, extract them and load them
20150111 10:55:11 <GiGurra> yes, thats the page Ive been studying mroe hehe
20150111 10:56:07 <GiGurra> The simplest might be multi jar, even though it's discouraged
20150111 10:56:08 <gouessej> Then, what is wrong??? /natives/<os.and.arch>/
20150111 10:56:39 <gouessej> I have an idea...
20150111 10:57:18 <gouessej> This should help: http://forum.jogamp.org/Fat-jar-deployment-method-ant-recipe-tp4032213p4032229.html
20150111 10:57:37 <gouessej> Look at the prefixes
20150111 10:58:04 <gouessej> Now don't tell me that you don't know where to put the native libraries :)
20150111 11:01:09 <gouessej> https://jogamp.org/jogl/doc/deployment/JOGL-DEPLOYMENT.html#NativeJARFiles
20150111 11:01:46 <GiGurra> Goussej, yes thx. Thats not the problem. I know there are many places to put them. Here's the problem:
20150111 11:02:48 <GiGurra> I need to come up with a simple enough suggestion for proposing a new build setting to the assembly/pack/one-jar plugin createors, good enough for them to accept. Otherwise we'll just run into "you're doing it wrong" -> "no you are"
20150111 11:03:28 <GiGurra> maven/sbt/gradle, all being fairly high level declarative build tools compared to ant, you're not supposed to work on details in them
20150111 11:03:51 <GiGurra> so I may just end up with a custom script to build my jar file, and just use SBT for development
20150111 11:03:55 <gouessej> Gradle allows to call Ant
20150111 11:03:57 <gouessej> Maven too
20150111 11:04:07 <GiGurra> I'm sure it does that is not the point
20150111 11:04:14 <GiGurra> sbt can all any console command too
20150111 11:04:51 <GiGurra> I may just end up calling ant to produce my jar in the end
20150111 11:04:59 <GiGurra> just because I cannot get it to work with sbt for example
20150111 11:05:30 <gouessej> There is already a limitation with One-JAR
20150111 11:05:32 <GiGurra> but then id need to define the dependencies again... The point of sbt/maven/etc is to be able to define deps once and be done with it, let the tool figure out the rest :)
20150111 11:05:39 <GiGurra> yeah, I dont care about one-jar tbh
20150111 11:06:07 <GiGurra> getting assembly to work would be the best, and I think the subfolder naming scheme is the best solution for that
20150111 11:06:54 <gouessej> Do you think that you have a chance to make it work with assembly then?
20150111 11:06:58 <GiGurra> yes
20150111 11:08:38 <GiGurra> assembly just merges everything in the dir structure given by the original jars. I'll just need to have them implement some retarget-filter
20150111 11:08:53 <gouessej> Good idea
20150111 11:10:51 <gouessej> In my humble opinion, the only helpful thing that could be done in JogAmp consists in providing a JAR with all native libraries respecting the naming convention
20150111 11:11:03 <GiGurra> YES
20150111 11:11:07 <GiGurra> if that is possible
20150111 11:11:14 <GiGurra> :)
20150111 11:11:29 <GiGurra> that would be great. I have to leave now. Good talking to you, I'll leave irc on
20150111 11:11:31 <gouessej> It breaks nothing :) You can make a bug report and mark it as a RFE
20150111 11:11:37 <gouessej> Ok bye
20150111 11:11:43 <GiGurra> bye, thx
20150111 11:11:48 <gouessej> you're welcome
20150111 11:13:08 * gouessej (52794ad6@anon) Quit (Quit: Page closed)
20150111 13:56:57 * zzuegg_ is now known as zzuegg
20150111 14:25:49 * monsieur_max1 (~maxime@anon) Quit (Quit: Leaving.)
20150111 14:26:40 * monsieur_max (~maxime@anon) has joined #jogamp
20150111 14:35:02 <zzuegg> loading/using textures is strange...
20150111 15:26:02 * GiGurra (~GiGurra@anon) Quit (Quit: Leaving)
20150111 16:20:03 * psyko (52ee7a7a@anon) has joined #jogamp
20150111 16:20:15 <psyko> Hello folkds
20150111 16:20:17 <psyko> folks
20150111 16:20:59 <psyko> Anyone's having a good tutorial for setting up a scene with Jogl using opengl4 ?
20150111 16:21:24 <psyko> I had it working with glBegin and glEnd... But I need to use the CG to improve performances
20150111 16:22:51 <psyko> s'il y a des francais, ca m'arrange aussi :)
20150111 16:24:09 <rmk0> psyko: that's kind of a massive subject
20150111 16:24:15 <rmk0> modern opengl is really a whole new API
20150111 16:24:17 <psyko> I know :)
20150111 16:24:34 <psyko> I know the basics
20150111 16:24:51 <psyko> mostly shader oriented, with vertex and fragment shaders
20150111 16:25:00 <rmk0> right
20150111 16:25:03 <psyko> but
20150111 16:25:13 <psyko> I'm following this tutorial
20150111 16:25:16 <psyko> http://www.opengl-tutorial.org/beginners-tutorials/tutorial-2-the-first-triangle/#Screen_Coordinates
20150111 16:25:29 <psyko> which basically, as opengl101 draw a triangle in screen coordinate
20150111 16:25:37 <rmk0> yeah, am quite familiar with that one
20150111 16:25:43 <psyko> but the fact is
20150111 16:25:50 <psyko> I can't see my triangle in the screen coordinate
20150111 16:26:02 <psyko> I'm not even using shader for vertex attributes or so on
20150111 16:26:33 <rmk0> how are you opening the opengl context?
20150111 16:26:34 <psyko> my vao and vbo is populated for sure
20150111 16:26:56 <psyko> that's a thing I'm pretty sure I don't do :p
20150111 16:27:10 <rmk0> depending on what opengl profile you're being given, you likely won't see anything but errors if you try rendering without a shader
20150111 16:27:22 <rmk0> and you won't even get the errors if you don't ask for them
20150111 16:27:48 <psyko> I perform a gl.glGetError();
20150111 16:27:51 <psyko> but no error
20150111 16:27:55 <rmk0> hm
20150111 16:28:14 <rmk0> you... are creating an opengl context somehow, but it happens as part of something else
20150111 16:28:25 <rmk0> are you using NEWT? creating a GLWindow, for example
20150111 16:28:34 <psyko> nope, I'm not using newt
20150111 16:28:58 <psyko> I'm using jogampl GLCanvas
20150111 16:29:01 <psyko> for swt
20150111 16:29:12 <rmk0> ok
20150111 16:29:23 <psyko> I guess the context is created here, right ?
20150111 16:29:27 <rmk0> yep
20150111 16:29:46 <rmk0> it's worth knowing what sort of context is being created on your system... i assume you're doing something like:
20150111 16:29:49 <psyko> I remember trying to display the opengl version in use
20150111 16:30:12 <psyko> it was 4.4 or 4.5 if i remember correctly
20150111 16:30:13 <rmk0> GLProfile profile = GLProfile.getDefault(); GLCapabilities caps = new GLCapabilities(profile); GLCanvas canvas = new GLCanvas(caps);
20150111 16:30:28 <psyko> Sounds like a good idea in the first place
20150111 16:31:46 <psyko> Isn't that the default implementattion in the creation of GlCanvas ?
20150111 16:32:01 <rmk0> it could be, i'm not familiar with the SWT GLCanvas
20150111 16:32:05 <psyko> ok
20150111 16:32:18 <rmk0> thing is, if you try to render without an active shader, it'd traditionally fall back to the "fixed function" pipeline
20150111 16:32:25 <rmk0> but that hasn't existed since opengl 3.1
20150111 16:32:37 <psyko> ok
20150111 16:32:47 <rmk0> i'd expect an error, but maybe you don't even get one of those these days... possibly just a black screen
20150111 16:32:57 <psyko> the thing is until yesterday I was rendering everything with fixed function pipeline
20150111 16:33:05 <psyko> glbegin.... glend and so on
20150111 16:33:16 <rmk0> yeah, you can still use it if you ask for a compatibility context
20150111 16:33:29 <rmk0> depending on your system, you may get a core context by default, you may get a compatibility context
20150111 16:33:39 <psyko> I even managed to render vao/vbo at the same time
20150111 16:33:52 <psyko> but I figure out it was clean at all
20150111 16:34:11 <psyko> ok I see
20150111 16:34:23 <rmk0> the version string will indicate which you've got
20150111 16:34:32 <psyko> Let me check that again
20150111 16:34:48 <rmk0> "3.3 (Core Profile) Mesa 10.3.5" is what i get when i ask specificaly for a core context
20150111 16:34:57 <rmk0> otherwise i get "3.0 Mesa 10.3.5"
20150111 16:36:15 <psyko> I have
20150111 16:36:17 <psyko> 4.4.0 NVIDIA 344.65
20150111 16:36:33 <rmk0> likely a compatibility context
20150111 16:37:08 <psyko> This means I can still use the "old rendering pipeline style" ?
20150111 16:37:21 <psyko> (which I don't want :) )
20150111 16:37:23 <rmk0> yep
20150111 16:37:35 <rmk0> in my experience the compatibility contexts are a bit rough
20150111 16:37:40 <rmk0> tons of legacy stuff and usually bugs
20150111 16:37:51 <psyko> I'm rendering something line 400k points
20150111 16:38:12 <rmk0> as one big vbo?
20150111 16:38:26 <psyko> basically, what you're saying is that I'm in trouble :)
20150111 16:38:42 <psyko> It might be one big VBO yes
20150111 16:38:45 <rmk0> hehe, you're probably in trouble if that translates to 400k function calls
20150111 16:39:07 <psyko> for now, it is 400k call...
20150111 16:39:08 <rmk0> if you can smash that into one vbo and draw it in a single call, you're at an advantage
20150111 16:39:17 <psyko> I already did
20150111 16:39:24 <rmk0> \o/
20150111 16:39:30 <psyko> I went from 2fps to something like 50fps
20150111 16:39:36 <rmk0> that's basically the optimal case for current drivers
20150111 16:39:46 <psyko> but it was by mixing old and new pipeline... really nasty
20150111 16:39:56 <psyko> I4d like to go to full modern opengl
20150111 16:40:17 <psyko> but even rendering a single triangle fails
20150111 16:40:18 <psyko> :'(
20150111 16:40:26 <zzuegg> i am quite sure that you need a shader
20150111 16:41:00 <zzuegg> but i can check quickly
20150111 16:41:12 <psyko> I tried to add a shader
20150111 16:41:17 <psyko> loaded it
20150111 16:41:28 <psyko> source, compile, link, validate and use
20150111 16:42:03 <psyko> like the one here : http://www.opengl-tutorial.org/beginners-tutorials/tutorial-2-the-first-triangle/#Screen_Coordinates
20150111 16:42:17 <psyko> but I only have red square in the upper right corner of the screen
20150111 16:42:30 <psyko> which means, the fragment shader does something. But I'm not sure what...
20150111 16:42:31 <rmk0> better than nothing, at least
20150111 16:42:38 <rmk0> nothing is what you'll usually get
20150111 16:42:38 <psyko> yep ;)
20150111 16:42:50 <rmk0> it sounds like an issue with the data in the vbo
20150111 16:43:15 <zzuegg> fun enough it actually draws if you don't bind a shader. even in core profile
20150111 16:43:20 <rmk0> either that, or you're getting a triangle, but it's so large that it looks like a rectangle onscreen
20150111 16:43:28 <rmk0> zzuegg: ?!
20150111 16:43:29 <psyko> and since I'm rendering only line strip, I don't expect to have a triangle
20150111 16:44:04 <psyko> zzuegg: ??
20150111 16:44:22 * rmk0 eyes the spec suspiciously
20150111 16:44:28 <zzuegg> don't know, i just tried to render a quad without any shaders bound. and i get the quad onscreen with the texCoord vbo as color output
20150111 16:44:33 <psyko> there is the need to bind a shader ?
20150111 16:45:00 <rmk0> that sounds deeply suspicious
20150111 16:45:28 <zzuegg> indeed. was surprised to see anything but an error
20150111 16:46:05 <psyko> you're losing me :)
20150111 16:46:29 <zzuegg> what data have you put into your vbo?
20150111 16:46:49 <psyko> hard coded triangle coordinates for now
20150111 16:47:04 <zzuegg> correct range? -1 to 1?
20150111 16:47:13 <psyko> Float g_vertex_buffer_data[] = { -1.0f, -1.0f, 0.0f,1f , 1.0f, -1.0f, 0.0f,1f, 0.0f, 1.0f, 0.0f,1f, };
20150111 16:47:23 <psyko> it's a 12 length array
20150111 16:47:45 <psyko> my array buffer is set to use 4 coordinates per vertice
20150111 16:47:50 <psyko> Float g_vertex_buffer_data[] = { -1.0f, -1.0f, 0.0f,1f , 1.0f, -1.0f, 0.0f,1f, 0.0f, 1.0f, 0.0f,1f, };
20150111 16:48:02 <psyko> gl.glVertexAttribPointer(0,4, GL.GL_FLOAT, false, 0, 0);
20150111 16:48:07 <psyko> copy/paste issue, sorry
20150111 16:48:27 <psyko> and my vertex shader use
20150111 16:48:29 <psyko> layout(location = 0)in vec4 vertexPosition_modelspace;
20150111 16:49:41 <psyko> and simply outputs
20150111 16:49:43 <psyko> gl_Position = vertexPosition_modelspace;
20150111 16:51:20 <zzuegg> data looks valid for a triangle
20150111 16:51:39 <psyko> it looks yes
20150111 16:52:10 <zzuegg> drawArrays(TRIANGLE,0,3);?
20150111 16:53:20 <psyko> damn no !
20150111 16:53:28 <psyko> drawArrays(TRIANGLE,0, myVar );?
20150111 16:53:35 <psyko> with myVar =0 (in debug)
20150111 16:53:45 <psyko> *so ashamed...*
20150111 16:53:59 <rmk0> impressive that you still get something onscreen
20150111 16:54:52 <psyko> hmmm
20150111 16:54:54 <psyko> it was better
20150111 16:54:58 <psyko> now my apps just crashes :)
20150111 16:55:03 <psyko> "Javam stopped working"
20150111 16:55:54 <zzuegg> oh :( forgot to enable the vertex attribute array?
20150111 16:56:18 <psyko> nop
20150111 16:56:25 <psyko> gl.glEnableVertexAttribArray(0); ?
20150111 16:56:29 <zzuegg> yeah
20150111 16:56:49 <psyko> nop, got it right before the drawArrays
20150111 16:56:55 <psyko> gl.glEnableVertexAttribArray(0); gl.glEnableVertexAttribArray(1); gl.glBindBuffer(GL.GL_ARRAY_BUFFER, vbo[0]); gl.glVertexAttribPointer(0,4, GL.GL_FLOAT, false, 0, 0); gl.glBindBuffer(GL.GL_ARRAY_BUFFER, vbo[1]); gl.glVertexAttribPointer(1,3, GL.GL_FLOAT, false, 0, 0); gl.glDrawArrays(GL.GL_TRIANGLES, 0,3);
20150111 16:57:32 <psyko> I'm checking my color array
20150111 16:57:38 <psyko> probably something wrong in it
20150111 16:58:10 <zzuegg> i only had native crashed when i populated my buffers wrong
20150111 16:58:45 <psyko> yeah I thing that's it
20150111 16:58:56 <psyko> i replaced myVar only in the render loop
20150111 16:59:07 <psyko> I replaced it everywhere now, and got the black screen again :)
20150111 16:59:12 <psyko> but no crash at least
20150111 17:01:38 <psyko> activating the sahder produce the same result as before. Colored square in the upper right corner
20150111 17:01:55 <psyko> where I'm expecting a centered triangle :)
20150111 17:01:58 <zzuegg> the colored square is strange..
20150111 17:02:07 <psyko> I agree
20150111 17:02:29 <psyko> it's actually the complete upper right quadrant that is colored
20150111 17:02:37 <psyko> with the color specified in the fragment shader
20150111 17:03:10 <psyko> Since I'm using 4.4 GL context
20150111 17:03:17 <psyko> what is the version of GLSL I should use ?
20150111 17:03:21 <psyko> in the glsl file ?
20150111 17:03:31 <psyko> I have #version 330 core
20150111 17:03:35 <psyko> but not sure if it's right
20150111 17:03:49 <rmk0> you're only guaranteed to get #version 440 with opengl 4.4
20150111 17:04:00 <rmk0> but... in practice you'll get almost all versions
20150111 17:04:15 <rmk0> you'll get a hard error on trying to compile a shader if the version is wrong
20150111 17:04:21 <psyko> ok
20150111 17:04:26 <psyko> good to know
20150111 17:05:45 <psyko> I may have another lead
20150111 17:06:05 <psyko> my glValidateProgram call raise the invalid enumerant glError
20150111 17:06:32 <psyko> which is not documented in glValidateProgram
20150111 17:07:42 <psyko> and gl.glGetProgramiv(program, GL4.GL_VALIDATE_STATUS) doesn't give anything
20150111 17:08:57 * hija (~hija@anon) Quit (Quit: hija)
20150111 17:09:03 <rmk0> at some point, you request a GL4 from a drawable, yes?
20150111 17:09:11 <rmk0> GL4 gl = (GL4) drawable.getGL();
20150111 17:09:14 <rmk0> something along those lines
20150111 17:09:23 <psyko> yes
20150111 17:09:38 <psyko> GL4 gl4 = gLAutoDrawable.getGL().getGL4();
20150111 17:09:40 <rmk0> try: GL4 gl = new DebugGL4((GL4) drawable.getGL());
20150111 17:10:03 <rmk0> it'll check glGetError after every call and raise an exception the first time an error appears
20150111 17:10:19 <psyko> wow that's cool
20150111 17:10:38 * hija (~hija@anon) has joined #jogamp
20150111 17:13:07 <psyko> glGetError() returned the following error codes after a call to glGetShaderiv(<int> 0x1, <int> 0x8B82, <java.nio.IntBuffer> java.nio.HeapIntBuffer[pos=0 lim=10 cap=10]): GL_INVALID_ENUM ( 1280 0x500), on thread main-AWTAnimator
20150111 17:13:15 <psyko> error from DebugGL4
20150111 17:13:20 <zzuegg> GetProgramiv works only if you use separate shader objects
20150111 17:13:33 <zzuegg> if not it should be getShaderiv i think
20150111 17:14:05 <psyko> I'm actually passing my program to it
20150111 17:16:02 <rmk0> the GL_INVALID_ENUM suggests you're using glGetShaderiv where glGetProgramiv is required
20150111 17:16:06 <psyko> will DebugGL4 throw an exception if compiling shader fails ?
20150111 17:16:08 <rmk0> are you checking the link status, by any chance?
20150111 17:16:21 <rmk0> it won't throw an exception there, no
20150111 17:16:31 <psyko> ok, so I do have to check it
20150111 17:16:57 <rmk0> the kind of errors returned by glGetError are unrecoverable as a rule
20150111 17:17:05 <rmk0> program compilation errors are arguably recoverable
20150111 17:17:26 <psyko> ok
20150111 17:17:51 <psyko> gl.glGetProgramiv(program, GL4.GL_LINK_STATUS, b); gives no error
20150111 17:18:08 <rmk0> right
20150111 17:19:31 <psyko> ok I found the wrong ENUM
20150111 17:19:53 <psyko> it's the kind of error you do, when you don't exactly know what you do :p
20150111 17:20:25 <rmk0> i've said this a lot in this channel, but opengl is a minefield
20150111 17:20:34 <psyko> it is exactly
20150111 17:20:45 <rmk0> almost every possible way of using it is the wrong way, and there are only a couple of correct ways, and the compiler can't help you at all because of the weak types
20150111 17:20:55 <rmk0> it's not a well designed API
20150111 17:20:57 <psyko> yep agreed
20150111 17:21:03 <psyko> ok so now
20150111 17:21:27 <psyko> shaders are source, compiled, attached to a program, the program is linked and validated
20150111 17:21:48 <psyko> but I still do have the upper right quad
20150111 17:21:50 <psyko> :'(
20150111 17:22:28 <rmk0> ... what happens if you replace all of the -1.0 with -0.1 and 1.0 with 0.1?
20150111 17:22:39 <psyko> I perform the glUseProgram in the init
20150111 17:22:44 <psyko> is that ok ?I do not use any other program
20150111 17:23:02 <zzuegg> here is a minimal example using gl4 core. i use the program pipeline instead but it should come down to the same: https://gist.github.com/zzuegg/a8469b317e5db3f0a86b
20150111 17:23:02 <rmk0> hm... i'm not sure it is
20150111 17:23:19 <rmk0> GLCanvas might change shaders underneath to do the work it does
20150111 17:24:50 <psyko> ok changing values from 1 to 0.1 do change
20150111 17:25:04 <psyko> let me experiment a little bit more
20150111 17:25:17 <psyko> when creating a float array for vertices
20150111 17:25:33 <psyko> is { x1, y1, z1, x2, y2, z2}
20150111 17:25:48 <psyko> or { x1,x2,y1,y2,z1,z2 } ?
20150111 17:25:57 <rmk0> the former
20150111 17:26:09 <psyko> the former ? (excuse me, not english)
20150111 17:26:13 <rmk0> first one
20150111 17:26:16 <psyko> ok
20150111 17:29:09 <psyko> Ok I do see the triangle now
20150111 17:29:22 <psyko> but still have the big square too :)
20150111 17:29:29 <psyko> let me make sure I4m note rendering anything else
20150111 17:31:05 <psyko> zzuegg: thanks for the snippet
20150111 17:31:08 <psyko> I4ll watch it soon
20150111 17:31:37 <psyko> what's gl4.glGenProgramPipelines(1, pipeline, 0); ?
20150111 17:32:37 <zzuegg> i use separate programs. in theory i can only change the fragment shader and leave the vertex shader as it is
20150111 17:32:53 <zzuegg> not tested yet.. just copied out stuff of my project to create this
20150111 17:33:15 <psyko> ok. Thats for more experienced users :)
20150111 17:33:33 <psyko> It looks like the upper/right square is produced by my overlay rendering
20150111 17:33:49 <psyko> when disabling it
20150111 17:33:55 <psyko> the square goes away
20150111 17:34:00 <zzuegg> ah that would explain why you got something visible :)
20150111 17:34:06 <psyko> yeah
20150111 17:34:10 <psyko> but I don't know why
20150111 17:34:24 <psyko> it means somehow the overlya is intercepted by the shader
20150111 17:34:50 <zzuegg> depends how you render your overlay
20150111 17:34:58 <psyko> using jogamp Overlay object
20150111 17:35:33 <zzuegg> never used any higher level jogamp objects since i wanted to learn gl from the base
20150111 17:35:50 <zzuegg> but it seems that it uses the shader you have currently bound
20150111 17:36:58 <psyko> well I guess I'll have to find another way
20150111 17:37:05 <psyko> or a way to exclude it from being shaded
20150111 17:38:34 <psyko> wouhou I even got the color working
20150111 17:38:50 <psyko> zzuegg: and rmk0 a BIG BIG BIG thank to both of you
20150111 17:39:04 <rmk0> no problem
20150111 17:39:22 <psyko> I still have to play with the matrices now :) but I'll try before asking for your help :p
20150111 17:39:34 <zzuegg> np at all
20150111 17:39:51 <psyko> damn opengl is a jungle
20150111 17:40:06 <psyko> so happy to find the beginning of the way through it :)
20150111 17:40:23 <zzuegg> i find it actually nicer then i tough. until texturing.. which i cannot get to work :(
20150111 17:40:59 <psyko> it's kind of disturbing to lose all the old fashion way
20150111 17:41:10 <psyko> and make sure not to use it anymore :)
20150111 17:41:49 <psyko> I need a cigaret :) brb
20150111 18:01:45 <zzuegg> how do you guys use apitrace with jogl? if i launch the executable created by grade, it does only start the app, but doesnt show anything
20150111 18:03:30 <rmk0> i have apitrace installed in /opt/apitrace, and use LD_PRELOAD=/opt/apitrace/lib/apitrace/wrappers/glxtrace.so java -jar ...
20150111 18:03:55 <rmk0> can also set TRACE_FILE to set the output trace file
20150111 18:05:24 <rmk0> ... not exactly sure that's what you were asking
20150111 18:06:01 <zzuegg> dont know, never used any tools like that, but i was able to create a trace file. but the retracer crashes when i load the trace
20150111 18:06:09 <rmk0> erk
20150111 18:06:27 <rmk0> how did you create the trace?
20150111 18:06:37 <rmk0> and... would keep that trace around
20150111 18:06:42 <rmk0> they fix reported bugs very quickly
20150111 18:06:48 <rmk0> last one i reported was fixed within an hour
20150111 18:06:59 <zzuegg> started retracer, and selected the application i wanted to debug
20150111 18:07:40 <rmk0> ... not sure what retracer is
20150111 18:07:46 <rmk0> i have qapitrace and glretrace
20150111 18:07:56 <rmk0> neither of them let you interactively select a program to trace
20150111 18:08:13 <zzuegg> qApiTrace.. its in the menu as retracer
20150111 18:08:25 <rmk0> is this on windows?
20150111 18:08:32 <zzuegg> no, ubuntu
20150111 18:08:40 <rmk0> hm
20150111 18:09:37 <zzuegg> ah ok, so now i can go trough the frames and see what has been called
20150111 18:12:53 <rmk0> would send them the trace that causes a crash
20150111 18:13:04 <rmk0> is all they need, typically
20150111 18:15:00 * hija (~hija@anon) Quit (Quit: hija)
20150111 18:16:38 * hija (~hija@anon) has joined #jogamp
20150111 18:59:30 <zzuegg> is it just me or is gl sometimes strange? screen coordiantes -1,-1 == bottom left, textureCoordinates, 0,1 see,s tp be bottom left
20150111 18:59:48 <zzuegg> seems to be*
20150111 19:01:05 <psyko> never went into texture coordinate yet
20150111 19:01:54 <psyko> anyone knows how to you PMVMatrix object ?
20150111 19:04:07 <zzuegg> nope, sorry. not yet at this point
20150111 19:06:33 <psyko> ok :)
20150111 19:06:39 <psyko> I will go with standard float array then
20150111 19:12:40 <rmk0> psyko: http://seanmiddleditch.com/matrices-handedness-pre-and-post-multiplication-row-vs-column-major-and-notations/
20150111 19:12:44 <rmk0> "how not to screw it up"!
20150111 19:13:58 <zzuegg> going to bookmark that too for later
20150111 19:14:17 <rmk0> is a good one to keep around, i'm not aware of any document that covers all the issues
20150111 19:14:21 <rmk0> they generally miss one or more
20150111 19:15:32 <zzuegg> just found out after ~1 day that glGenerateMipmap(GL_TEXTURE_2D) is not a optional call :(
20150111 19:15:51 <rmk0> nope
20150111 19:16:20 <zzuegg> it kind of sounds like, if you dont want mipmaps, then you are good without it
20150111 19:16:35 <rmk0> did you see the spec?
20150111 19:17:07 <rmk0> opengl doesn't consider a texture "complete" until all required calls have been made on creation
20150111 19:17:25 <rmk0> if you use a minification mode that involves mipmaps, the texture's not complete until to generate or upload all mipmap levels
20150111 19:17:31 <zzuegg> yeah i did. but i guess i was not aware that min filter is GL_LINEAR_MIPMAP_NEAREST as default
20150111 19:17:43 <rmk0> in the best opengl style, using an incomplete texture isn't even an error \o/
20150111 19:18:05 <zzuegg> if you change the min filter to LINEAR, it would work without glGenerateMips
20150111 19:18:10 <rmk0> yeah
20150111 19:18:18 <rmk0> .. didn't they replace the texture api with something less awful in 4.*?
20150111 19:18:47 <zzuegg> i assume bindless is the new way.. but its 4.4 only i think
20150111 19:19:25 <zzuegg> gl just offers too many ways to do it wrong :)
20150111 19:19:59 <zzuegg> i was kind of surprised that a texture is actually not a Buffer like everything else
20150111 19:20:52 <rmk0> they do exist, but they're 1D only
20150111 19:21:38 <zzuegg> i would not know a usage of a 1d texture, but there probably is one
20150111 19:22:30 <rmk0> don't know
20150111 19:22:33 <rmk0> 4.* seems pretty insane
20150111 19:22:49 <rmk0> layers and layers of stuff
20150111 19:23:00 <zzuegg> some stuff like direct state access sounds nice
20150111 19:23:17 <rmk0> yeah, the most bleeding edge possible extensions seem nice
20150111 19:23:30 <rmk0> assume they're the way the replacement api will work
20150111 19:23:46 <rmk0> 4.* feels like 2.1 all over again
20150111 19:23:59 <rmk0> ever increasing complexity, of questionable relevance
20150111 19:24:25 <rmk0> would prefer they just got on with the clean break and replacement api
20150111 19:24:50 <zzuegg> he, well. you dont have to use the new stuff :) isnt something like that planned for "opengl next"
20150111 19:24:56 <rmk0> yeah
20150111 19:25:18 <rmk0> my main problem is that if you are actually targetting 4.*, you generally have to program in a really abusive way to get maximum performance
20150111 19:25:36 <rmk0> someone at nvidia did a slideshow on "programming with zero driver overhead"
20150111 19:25:51 <zzuegg> hehe, yeah have seen that one
20150111 19:26:01 <rmk0> it sounds like you more or less get to write your own virtual memory system with giant VBOs
20150111 19:26:05 <rmk0> and they act like this is a good idea
20150111 19:26:19 <rmk0> like they see no problem with requiring that at all!
20150111 19:26:45 <zzuegg> hehe. but they sure target large AAA studios and not guys like me
20150111 19:27:01 <zzuegg> i probably dont need that extra microsecond
20150111 19:27:13 <rmk0> think it's just draw calls, really
20150111 19:27:28 <rmk0> supposedly no matter what you're writing, you won't get more than about 50k draw calls out of any hardware now
20150111 19:27:30 <zzuegg> but having seen that presentation i designed my api to support stuff like shared vbos at some time
20150111 19:28:04 <zzuegg> oh, well i probably can do lots of stuff with 50k draws
20150111 19:28:13 <rmk0> it's quite a lot, yeah
20150111 19:28:54 <rmk0> i did a bit of poking around in the deus-ex human revolution renderer a while back
20150111 19:29:15 <rmk0> the visuals in that game still impress me, but i think they're only making a few thousand draw calls per frame
20150111 19:29:24 <rmk0> it looks like it should be a lot more
20150111 19:29:53 <rmk0> http://waste.io7m.com/2014/10/06/dxhr/dxhr.html
20150111 19:30:47 <rmk0> i took samples from the internal buffers every ten draw calls or so to give a bit of timelapse
20150111 19:31:13 <zzuegg> ha, thats a very good idea to get an idea on how they do that..
20150111 19:31:51 <rmk0> i couldn't get apitrace to play nicely with the half life 2 renderer, annoyingly
20150111 19:31:59 <rmk0> they're still using a traditional forward renderer
20150111 19:34:48 <zzuegg> like how they did the emissive light
20150111 19:36:29 <zzuegg> and also the big visual impact of colour correction
20150111 19:39:15 <rmk0> yep
20150111 21:55:02 * void256 (~void@anon) has joined #jogamp
20150111 22:39:40 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20150111 22:43:48 * psyko (52ee7a7a@anon) Quit (Quit: Page closed)
20150111 23:10:43 * void256 (~void@anon) Quit (Remote host closed the connection)
20150112 05:05:06 -jogamp- Continue @ http://jogamp.org/log/irc/jogamp_20150112050506.html