JogAmp IRC Chat Logs

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

20150716 05:06:25 -jogamp- Previous @ http://jogamp.org/log/irc/jogamp_20150715050625.html
20150716 05:06:25 -jogamp- This channel is logged @ http://jogamp.org/log/irc/jogamp_20150716050625.html
20150716 05:55:31 * doev (~doev@anon) has joined #jogamp
20150716 06:09:17 * doev (~doev@anon) Quit (Ping timeout: 240 seconds)
20150716 06:23:44 * monsieur_max (~maxime@anon) has joined #jogamp
20150716 06:23:58 <monsieur_max> hello
20150716 06:24:52 * doev (~doev@anon) has joined #jogamp
20150716 06:25:42 * elect_ (~elect@anon) has joined #jogamp
20150716 06:26:06 * elect_ (~elect@anon) Quit (Read error: Connection reset by peer)
20150716 06:38:30 * jvanek (jvanek@anon) has joined #jogamp
20150716 06:54:37 * elect (~elect@anon) has joined #jogamp
20150716 06:54:46 <elect> hi
20150716 07:38:48 * eclesia (~husky@anon) has joined #jogamp
20150716 09:48:28 * rmk0 (~rmk0@anon) Quit (Quit: Lost terminal)
20150716 09:49:23 * rmk0 (~rmk0@anon) has joined #jogamp
20150716 09:49:23 * rmk0 (~rmk0@anon) Quit (Changing host)
20150716 09:49:23 * rmk0 (~rmk0@anon) has joined #jogamp
20150716 10:07:22 * doev (~doev@anon) Quit (Ping timeout: 244 seconds)
20150716 10:17:44 * doev (~doev@anon) has joined #jogamp
20150716 11:54:55 <doev> hi
20150716 11:55:35 <doev> Is it possible that the windowSizeCallback is called during rendering?
20150716 11:55:47 <elect> reshape?
20150716 11:56:03 <doev> when I resize the window
20150716 11:56:33 <elect> it is automatic
20150716 11:56:35 <doev> the callback is called from a different thread?
20150716 11:56:52 <elect> ah, I dont know that
20150716 11:56:58 <elect> better ask to xe
20150716 11:57:00 <elect> xranby,
20150716 11:57:25 <doev> in the callback I change the projection matrix, but if it can happen during rendering, thats bad.
20150716 11:58:04 <doev> on the other side, there is no error if I call open-gl stuff in the callback.
20150716 11:58:31 <doev> must be the same thread, that is used for rendering.
20150716 11:58:51 <elect> no wait
20150716 11:59:05 <elect> reshape will not interfeer with display()
20150716 11:59:16 <elect> I never had problem
20150716 11:59:23 <doev> display? I am using lwjgl 3.0.0a
20150716 11:59:34 <elect> ah
20150716 11:59:47 <elect> better asking on their irc then
20150716 12:00:06 <elect> you can use a sync variable btw
20150716 12:00:15 <doev> oh, sorry
20150716 12:00:19 <elect> nope
20150716 12:00:24 <doev> I am in #jogamp :)
20150716 12:00:26 <xranby> doev: jogamp jogl provides opengl support on both desktop and mobile
20150716 12:00:30 <elect> we are all java
20150716 12:01:00 <xranby> doev: you may want to try it if you want your code to run on both desktop and mobile systems using a unified codebase
20150716 12:01:06 <elect> anyway, has anyone here ever investigated over efficient scenegraph/scenetree?
20150716 12:01:16 <elect> I found these stuff
20150716 12:01:17 <elect> https://devtalk.nvidia.com/default/topic/777618/announcing-nvpro-pipeline-a-research-rendering-pipeline/
20150716 12:01:30 <elect> http://on-demand.gputechconf.com/gtc/2013/presentations/S3032-Advanced-Scenegraph-Rendering-Pipeline.pdf
20150716 12:01:34 <elect> very interesting
20150716 12:02:02 <elect> here the C code https://github.com/nvpro-pipeline/pipeline
20150716 12:40:14 * gouessej (5ee4b442@anon) has joined #jogamp
20150716 12:40:38 <gouessej> Hi
20150716 12:41:00 <gouessej> elect: It's interesting as a source of inspiration, not as is in my humble opinion
20150716 12:41:15 <elect> what you mean?
20150716 12:41:50 <gouessej> elect: there are already several scenegraph APIs in Java but they don't all use ARB_multi_draw_indirect
20150716 12:42:20 <gouessej> elect: it's an interesting project usable to improve some aspects in existing scenegraph APIs
20150716 12:43:21 <gouessej> elect: the batching and the use of TBO could be implemented in some APIs
20150716 12:44:01 <gouessej> elect: but Eclesia's framework already uses UBO and TBO, doesn't it?
20150716 12:44:21 <elect> are you asking me? ^^
20150716 12:45:03 <gouessej> eclesia: You can answer, it's your baby
20150716 12:45:21 <gouessej> elect: You should look at existing solutions, don't reinvent the wheel
20150716 12:45:34 <elect> I didnt find anything
20150716 12:45:43 <elect> everything seems C-only or java-outdated
20150716 12:45:48 <elect> do you have any link about?
20150716 12:47:06 <gouessej> What do you mean by java-outdated???? Don't you know JMonkeyEngine 3, Unlicense, LibGDX 3D API, ...?
20150716 12:48:22 <gouessej> NV_bindless_multidraw_indirect seems to be very efficient to draw the entire scene with one call :)
20150716 12:49:01 <elect> I mean, they are just simple sceneTree
20150716 12:49:03 <elect> nothing more
20150716 12:51:13 <gouessej> Lol
20150716 12:52:00 <gouessej> You should read their source code
20150716 12:52:43 <xranby> gouessej: hi! is the libgdx tree stable again?
20150716 12:53:14 <gouessej> xranby: Yes, except a few scripts
20150716 12:53:21 <xranby> good!
20150716 12:53:30 <xranby> i will check out your new branch and test it
20150716 12:53:50 <xranby> i have recived some raspberry pi integrated tft screen that work *very well*
20150716 12:53:59 <gouessej> I had some troubles after moving gdx-tests-jogl to gdx-tests-jogamp
20150716 12:54:09 <gouessej> The rest should work
20150716 12:54:14 <elect> there is a wiki somewhere, where they explain how does it work? gouessej
20150716 12:55:19 <gouessej> elect: It's open source. The best way of understanding how it works consists in reading the code. JMonkeyEngine 3 is entirely shader based
20150716 12:55:58 <gouessej> elect: https://github.com/jMonkeyEngine/jmonkeyengine/tree/master/jme3-core/src/main/java/com/jme3/shader
20150716 12:56:40 <xranby> if someone want to use a raspberry pi with an integrated TFT screen utilitizing full hardware acceleration using broadcoms OpenGL ES 2 driver -> a setup that only consume 3W then i do recommend that you take a look at the adafruit kippah https://learn.adafruit.com/adafruit-dpi-display-kippah-ttl-tft/overview
20150716 12:59:59 <elect> can you sum up in a couple of rows what does shader based mean?
20150716 13:01:08 <gouessej> elect: They don't use the fixed pipeline to manage the matrices, model/view, etc... All effects use the shaders too
20150716 13:03:18 <gouessej> elect: this is the most important class to understand how it works: https://github.com/jMonkeyEngine/jmonkeyengine/blob/master/jme3-jogl/src/main/java/com/jme3/renderer/jogl/JoglRenderer.java
20150716 13:04:01 <elect> I think that should be a basic requirement of a modern engine
20150716 13:04:09 <gouessej> elect: Those APIs aren't just scenegraphs. Typically, they do a lot more than JUNG for example
20150716 13:04:11 <elect> shader-based i mean
20150716 13:04:19 <elect> JUNG?
20150716 13:04:34 <gouessej> http://jung.sourceforge.net/
20150716 13:05:33 <elect> I dont see any update after January 2010
20150716 13:05:35 <elect> is it dead?
20150716 13:06:04 <gouessej> You don't really know those APIs, you shouldn't peremptory write that there are nothing more than scenegraphs. JUNG is an example of API which is nothing more than a scenegraph/network/tree API
20150716 13:06:44 <gouessej> "peremptorily"
20150716 13:07:08 <elect> you are right, but I tried to get info about that
20150716 13:07:24 <elect> for example the only thing I found about JM3 were these
20150716 13:07:25 <elect> http://wiki.jmonkeyengine.org/doku.php/jme3:scenegraph_for_dummies
20150716 13:07:30 <elect> http://wiki.jmonkeyengine.org/doku.php/jme3:advanced:traverse_scenegraphhttp://wiki.jmonkeyengine.org/doku.php/jme3:advanced:traverse_scenegraph
20150716 13:07:44 <elect> http://wiki.jmonkeyengine.org/doku.php/jme3:the_scene_graph
20150716 13:07:51 <gouessej> It doesn't mean that you know those APIs
20150716 13:07:59 <elect> true
20150716 13:08:24 <gouessej> JMonkeyEngine doesn't have the worst documentation by the way
20150716 13:08:28 <elect> but I think that if they had some optimizations they would have written out there
20150716 13:08:36 <elect> I can image
20150716 13:09:11 <gouessej> No, the documentation is incomplete and you miss something important
20150716 13:09:45 <gouessej> Actually, there are some optimizations that aren't correctly managed in those APIs and not related to OpenGL
20150716 13:09:46 <elect> you know the sceneGraph under JM3?
20150716 13:10:19 <gouessej> I am responsible for engine support, I ported this code to JogAmp
20150716 13:10:35 <elect> you know someone who knows it?
20150716 13:11:02 <gouessej> normen and others can answer your questions
20150716 13:11:19 <elect> how can I contact him?
20150716 13:11:36 <elect> shall I write directly on the JM3 forum?
20150716 13:11:59 <gouessej> Yes or you can use its IRC channel
20150716 13:12:09 <gouessej> http://hub.jmonkeyengine.org/t/jme-irc-channel/1166/10
20150716 13:12:41 <gouessej> http://hub.jmonkeyengine.org/t/jme-irc-channel/15723/2
20150716 13:13:47 <gouessej> I advise you to read that too: http://wiki.jmonkeyengine.org/doku.php/jme3#documentation_for_advanced_users
20150716 13:14:43 <elect> I cant find it on the channel list
20150716 13:15:37 <gouessej> Have you tried both jme and jmonkeyengine?
20150716 13:16:16 <gouessej> "jme" seems to work
20150716 13:17:12 <gouessej> "jmonkeyengine" too
20150716 13:17:30 <gouessej> Just enter "/join #jmonkeyengine"
20150716 13:17:47 <elect> strange
20150716 13:17:56 <elect> you are right, I couldnt find them in the channel list
20150716 13:18:01 <gouessej> What is strange?
20150716 13:18:05 <elect> but trying to join them, it works
20150716 13:19:11 <gouessej> elect: Why are you focused on OpenGL "optimizations"?
20150716 13:19:51 <elect> I have to push our program faster
20150716 13:20:23 <elect> we are hitting more and more often performances limit
20150716 13:20:29 <elect> with complex models
20150716 13:21:02 <elect> anyway, I saw from the JoglRenderer.java no GL 4.x
20150716 13:21:15 <elect> and also the jogl wiki page still lack that too
20150716 13:22:03 <elect> I suggest someone to update it, as somebody may find jogl outdated
20150716 13:28:36 <gouessej> In the real world, the developers don't target only the latest version of OpenGL
20150716 13:29:05 <elect> I know, but you can find GL 4.4 since GTX 4xx and Amd 5xxx
20150716 13:29:08 <gouessej> Most of the hardware out there doesn't support it
20150716 13:29:11 <elect> with updated drivers
20150716 13:29:56 <gouessej> I have nothing against adding some examples using OpenGL 4 into jogl-demos
20150716 13:30:10 <elect> :)
20150716 13:30:43 <gouessej> Beware, some code uses some very recent features as extensions
20150716 13:30:52 <gouessej> even though you don't see "GL4"
20150716 13:31:21 <elect> uhm, ok
20150716 13:32:07 <gouessej> We can't show only trendy things but a demo using VBUM would be nice, feel free to contribute
20150716 13:36:18 <elect> I tried, but I got those perf issue :o
20150716 13:36:50 <elect> btw the whole market is moving in that direction, with DX12 and Vulkan
20150716 13:40:10 <elect> I guess it is important that people learn the modern way
20150716 13:40:19 <elect> I started with fixed pipeline and I regret
20150716 13:40:54 <elect> I moved to shaders and then now I see the modern way is totally different
20150716 13:41:15 <elect> bindless vbo/vao, multi_indirect_draw
20150716 13:41:21 <elect> sparse bindless textures
20150716 13:48:28 <rmk0> opengl... having an irrelevant abstraction and then having to provide extensions to poke holes in the abstraction
20150716 13:48:41 <rmk0> am looking forward to using an API that doesn't have all those silly things
20150716 13:48:58 <elect> I know
20150716 13:49:03 <elect> but this is what we have today
20150716 13:49:09 <rmk0> i'm painfully aware
20150716 13:49:26 <rmk0> i'm still targeting opengl 3.3!
20150716 13:49:31 <elect> ^^
20150716 13:50:02 <rmk0> to be fair, 3.3 is bad but at least there isn't much of it
20150716 13:50:20 <elect> what do you mean by is bad?
20150716 13:50:28 <rmk0> i mean it's not a good API
20150716 13:50:34 * doev (~doev@anon) Quit (Ping timeout: 265 seconds)
20150716 13:50:35 <rmk0> but ... at least it's small
20150716 13:50:43 <elect> got it
20150716 13:51:04 <elect> do you also know DX?
20150716 13:51:16 <rmk0> i can read it, i've never developed with it
20150716 13:51:29 <rmk0> being able to only target one platform means it's no use to me
20150716 13:51:35 <elect> what is your opinion about it?
20150716 13:52:02 <elect> in terms of API I mean
20150716 13:52:15 <rmk0> i think it's more type-safe than opengl
20150716 13:52:45 <elect> have you got also a look on Metal?
20150716 13:52:57 <rmk0> nope... not intending to either
20150716 13:53:05 <rmk0> being able to only target one platform means it's no use to me!
20150716 13:53:13 <elect> :D
20150716 13:53:26 <elect> so you look forward to vulkan?
20150716 13:53:31 <rmk0> yeah, should be good
20150716 13:53:33 <xranby> YES
20150716 13:53:39 <elect> xranby!
20150716 13:54:02 <elect> I took a look to an hello triangle
20150716 13:54:14 <elect> it looks damn complex :/
20150716 13:54:43 <rmk0> the setup no doubt takes a lot
20150716 13:54:45 <xranby> elect: thats the point! the driver should not have to worry about memory allocation
20150716 13:54:58 <rmk0> is very similar device and context management to opencl
20150716 13:55:16 <elect> https://medium.com/@Overv/implementing-hello-triangle-in-mantle-4302450fbcd2
20150716 13:55:37 <rmk0> one thing i really, really like about it: you have to opt-in to use extensions
20150716 13:55:46 <rmk0> they don't just get exposed whether you want them or not, like in opengl
20150716 13:57:16 <xranby> with the driver having to deal with as little as possible will enable vulkan drivers to be opensource and implement the full specification
20150716 13:58:08 <xranby> the driver can be public domain as well, or free software
20150716 13:58:34 <xranby> the point is that we will finally have something that will work on all os and platforms,, that is easy engough to implement on a new platform
20150716 13:58:55 <rmk0> i wish the mesa people were given membership
20150716 13:59:22 <xranby> i think the intel vulkan driver is built using the mesa codebase
20150716 14:00:54 <xranby> http://www.phoronix.com/scan.php?page=news_item&px=LunarG-Vulkan-AMA
20150716 14:00:59 * juank_prada (~juank_pra@anon) has joined #jogamp
20150716 14:07:35 * doev (~doev@anon) has joined #jogamp
20150716 14:30:11 <gouessej> elect: We don't talk the same language. Even on the "market" there are still numerous machines not supporting OpenGL 4
20150716 14:34:27 <gouessej> elect: In my humble opinion, approaching near zero driver overhead will be possible without Vulkan/Metal/Mantle/Direct3D with OpenGL, it will be ok for me :)
20150716 14:36:34 * gouessej (5ee4b442@anon) Quit (Quit: Page closed)
20150716 14:42:03 * juank_prada (~juank_pra@anon) Quit (Read error: No route to host)
20150716 14:46:49 * juank_prada (~juank_pra@anon) has joined #jogamp