#jogamp @ irc.freenode.net - 20130923 05:05:28 (UTC)

20130923 05:05:28 -jogamp- Previous @ http://jogamp.org/log/irc/jogamp_20130922050528.html
20130923 05:05:28 -jogamp- This channel is logged @ http://jogamp.org/log/irc/jogamp_20130923050528.html
20130923 06:38:30 * monsieur_max (~maxime@anon) has joined #jogamp
20130923 09:58:03 * xranby (~xranby@anon) Quit (Ping timeout: 252 seconds)
20130923 10:09:36 * xranby (~xranby@anon) has joined #jogamp
20130923 10:22:48 * xranby (~xranby@anon) Quit (Ping timeout: 252 seconds)
20130923 10:26:54 * xranby (~xranby@anon) has joined #jogamp
20130923 12:36:26 * xranby (~xranby@anon) has left #jogamp
20130923 15:52:49 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20130923 16:26:07 * hharrison (~chatzilla@anon) has joined #jogamp
20130923 16:26:42 <hharrison> sgothel: I wonder if this is/could be a better alternative to JOGL's PCPP
20130923 16:26:44 <hharrison> http://lists.freedesktop.org/archives/mesa-dev/2013-September/045110.html
20130923 16:30:01 * monsieur_max (~maxime@anon) has joined #jogamp
20130923 20:04:34 * b6 (~b@anon) has joined #jogamp
20130923 20:06:08 <b6> i'm trying to use jogl in a maven project. i'm getting "Catched ZipException: error in opening zip file". what is it trying to do there?
20130923 20:25:11 <sgothel> @Harvey: I checked the Khronos XML DB .. (i.e. new GL spec file replacement) .. well, it's not satisfactory for now .. we still include the old GL header to get proper GL profile/extension association :(
20130923 20:25:43 <sgothel> so yeah .. I eyeballed it ..
20130923 20:26:25 <sgothel> Re OSX CALayer .. I created a good test case reproducing bugs .. behavior _is_ different w/ diff. OSX AWT versions, yes.
20130923 20:26:41 <sgothel> since 1.7.0_40, no more position error, but still a size error
20130923 20:27:18 <sgothel> currently I introduce quirk bit values for that, so we can extend that later on (when other bugs are fixed .. or introduced)
20130923 20:40:14 * Eclesia (~eclesia@anon) has joined #jogamp
20130923 20:40:21 <Eclesia> hi
20130923 20:43:29 <sgothel> hi
20130923 21:20:30 * void256 (~void@anon) has joined #jogamp
20130923 21:20:45 <Eclesia> hi void256
20130923 21:20:57 <void256> hi there
20130923 21:24:30 <Eclesia> performance question : is there a difference using a float[3] or a vec3 , if I don't use any vector functions ?
20130923 21:26:09 <void256> in GLSL?
20130923 21:26:59 <Eclesia> yes
20130923 21:27:26 <void256> don't no :)
20130923 21:27:32 <void256> guess not
20130923 21:28:39 <Eclesia> I transfer the bone indexes in various types : vec2/vec3/vec4 but I wonder if i'm just wasting my time for nothing. better remain with a good old float array.
20130923 21:37:37 * monsieur_max (~maxime@anon) has left #jogamp
20130923 21:44:00 <sgothel> depends _how_ you xfer data
20130923 21:44:07 <sgothel> i.e. unitform or per vertex ?
20130923 21:44:31 <sgothel> per vertex .. i.e. interpolated by vertex shader -> fragment position ..
20130923 21:44:45 <sgothel> assuming uniform, float[] is the only way right ?
20130923 21:48:40 <Eclesia> sgothel: in uniforms
20130923 21:49:21 <Eclesia> based on the number of weights per bone I used vecN types
20130923 21:49:27 <sgothel> I am a bit rusty .. if you perform vec math vec types might be better suited .. if you can pass vec via uniforms ..
20130923 21:50:01 <sgothel> but it should not matter regarding the memory transfer .. i.e. both are packed tight (float[] / vecN)
20130923 21:50:46 <Eclesia> the thing I don't use any vec maths
20130923 21:51:06 <sgothel> IMHO it doesn't matter than
20130923 21:51:28 <Eclesia> so I'm just making the code more complex to map different types... for nothing
20130923 21:52:25 <sgothel> it all depends on the impl. of GLSL for the GPU .. AFAIK .. i.e. array-offset versus vec component
20130923 21:52:48 <sgothel> assuming array offset is static, it should not matter here either :)
20130923 21:53:18 <Eclesia> I just checked my shader. I use layouts :D
20130923 21:53:40 <void256> [23:53:23] foobaz the vec version will never be slower
20130923 21:53:42 <void256> [23:53:29] foobaz but they might often be the same speed
20130923 21:53:43 <void256> [23:53:33] foobaz depends on the implementation of course
20130923 21:53:47 <void256> ;)
20130923 21:53:56 <Eclesia> http://pastebin.com/GP8hvumu
20130923 21:55:19 <sgothel> :)
20130923 21:56:21 <void256> http://i.imgur.com/a00LWwG.png
20130923 21:56:34 <void256> perfectly antialiased low alpha wide line :D
20130923 21:56:42 <sgothel> KUDOS
20130923 21:56:48 <Eclesia> who ! great
20130923 21:56:49 <void256> using an alpha mask and two pass rendering using a FBO tho :/
20130923 21:56:49 <sgothel> MRT and alpha test ?
20130923 21:57:01 <sgothel> MRT not possible ?
20130923 21:57:12 <void256> not possible according to glYoda
20130923 21:57:27 <sgothel> well .. as long it's not in parallel ..
20130923 21:57:34 <void256> or using some funky NV_texture_barrier extension but probably not for my use case at all :/
20130923 21:57:54 <sgothel> i.e. split the draw command in non intersecting part ?
20130923 21:58:00 <sgothel> *parts*
20130923 21:58:10 <void256> so the plan is to offer two versions: one for alpha 1 lines and one pass and one for alpha < 1 with two passes ;)
20130923 21:58:15 <void256> nah
20130923 21:58:19 <void256> that's too much math ;)
20130923 21:58:22 <sgothel> hehe
20130923 21:58:25 <void256> glBlendEquationSeparate(GL_MAX, GL_MAX);
20130923 21:58:31 <void256> that was helpful for generating the mask
20130923 21:58:37 <sgothel> yeah .. sounds great and feasible
20130923 21:58:38 <void256> which is GL_RED mask
20130923 21:58:59 <sgothel> hmm .. > ES2
20130923 21:59:07 <void256> why?
20130923 21:59:20 <sgothel> oh you use that math, but not that function ?
20130923 21:59:32 <void256> ah, I use that function :/
20130923 21:59:45 <sgothel> or is it avail on ES2 .... dunno would need to look
20130923 21:59:47 <void256> GL_MAX is > ES2? damn
20130923 21:59:54 <void256> I look
20130923 21:59:56 <void256> :>
20130923 22:00:20 <void256> Core since version 2.0
20130923 22:00:28 <void256> not sure about ES yet
20130923 22:00:33 <sgothel> Eclesia: for(int i=0;i<NBJOINT;i++){ - that might be expensive!
20130923 22:00:44 <sgothel> mouse over .. tells you :)
20130923 22:00:54 <sgothel> (if you have the sources attached to the jogl jar)
20130923 22:01:00 <sgothel> (i.e. w/ eclipse)
20130923 22:01:41 <Eclesia> sgothel> I'm still a gl newbie ^^ less then a year
20130923 22:02:04 <sgothel> loops and branches are expensive
20130923 22:02:16 <Eclesia> why that ?
20130923 22:02:23 <sgothel> if loops cannot be unrolled thx to static knowledge .. extreme expensive
20130923 22:02:38 <sgothel> b/c the GPU usually is SIMD
20130923 22:02:41 <hharrison> sgothel: thanks for looking at the OSX stuff, when a new snapshot pops out, let me know and I'll get the 3-4 reliable Java3d testers I'm in contact with have a run at it
20130923 22:02:52 <sgothel> sometimes sort of MIMD .. but command prefect is limited ..
20130923 22:03:06 <sgothel> @Harvey: yup ..
20130923 22:03:30 <sgothel> i.e. if one fp branches .. it may needs to wait until the new commands are available .. oops
20130923 22:03:33 <Eclesia> sgothel: so I should unroll my loops in the shader before ?
20130923 22:03:42 <sgothel> if that is possible .. yes
20130923 22:04:11 <sgothel> even using n shaders for diff. static values is faster .. even when switching
20130923 22:04:16 <Eclesia> I can but that might make my app rebuild the shader program more often
20130923 22:04:33 <sgothel> you can build n shader upfront once .. and switch
20130923 22:05:05 <sgothel> switching shader and maintaining the state (uniform / attributes) was one reason for our ShaderState class
20130923 22:05:09 <Eclesia> I use somekind of template system, merging pieces of shaders. I haven't made the cache yet
20130923 22:05:30 <sgothel> lazy doing so and caching .. will do
20130923 22:05:41 <sgothel> similar thing we do in our FFP emul.
20130923 22:05:50 <Eclesia> ffp ?
20130923 22:05:52 <sgothel> i.e. w/ lighting (number of lights)
20130923 22:05:57 <sgothel> fixed function pipeline
20130923 22:06:40 <sgothel> FFMPEGMediaPlayer:721: " y = mix( y1, y2, mod(gl_FragCoord.x, 2) ); /* avoid branching! */\n"+
20130923 22:06:54 <sgothel> ^^ is one trick to avoid branching, i.e. use some float math
20130923 22:07:20 <sgothel> so it's better to produce more fpu cycles than integer branches ..
20130923 22:07:31 <sgothel> since fpu is cheap .. the other not so much
20130923 22:08:17 <sgothel> /** Part of <code>GL_ES_VERSION_3_0</code>, <code>GL_ARB_imaging</code> */
20130923 22:08:17 <sgothel> public static final int GL_MAX = 0x8008;
20130923 22:08:20 * Eclesia will hack performances when the full engine will work properly
20130923 22:08:30 <sgothel> ^^ that is what MOUSE_OVER would tell you in an IDE :)
20130923 22:08:40 * Eclesia nothing goods come from early performance hacks
20130923 22:09:00 <sgothel> well .. split decision here - sometimes it's good to know where to modularize ..
20130923 22:09:12 <sgothel> ok .. boss calls me .. later dinner - laters :)
20130923 22:09:21 <Eclesia> bye
20130923 22:11:03 <void256> crap
20130923 22:20:57 <Eclesia> going to bed ++
20130923 22:21:03 * Eclesia (~eclesia@anon) has left #jogamp
20130923 22:44:06 * void256 (~void@anon) Quit (Quit: ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812])
20130924 00:08:56 * sgothel (~sven@anon) Quit (Ping timeout: 256 seconds)
20130924 00:19:51 * jk4 (~jk4@anon) Quit (Ping timeout: 260 seconds)
20130924 00:23:01 * sgothel (~sven@anon) has joined #jogamp
20130924 00:23:01 * ChanServ sets mode +v sgothel
20130924 00:27:33 * jk4 (~jk4@anon) has joined #jogamp
20130924 00:43:47 * jk4 (~jk4@anon) Quit (Ping timeout: 240 seconds)
20130924 00:44:23 * jk4 (~jk4@anon) has joined #jogamp
20130924 05:05:29 -jogamp- Continue @ http://jogamp.org/log/irc/jogamp_20130924050529.html