JogAmp IRC Chat Logs

#jogamp @ irc.freenode.net - 20150311 05:05:36 (UTC)

20150311 05:05:36 -jogamp- Previous @ http://jogamp.org/log/irc/jogamp_20150310050536.html
20150311 05:05:36 -jogamp- This channel is logged @ http://jogamp.org/log/irc/jogamp_20150311050536.html
20150311 07:37:43 * monsieur_max (~maxime@anon) has joined #jogamp
20150311 07:53:01 * doev (~doev@anon) has joined #jogamp
20150311 12:51:22 * Eclesia (~eclesia@anon) has joined #jogamp
20150311 12:51:36 <Eclesia> hi
20150311 12:52:37 <rmk0> lo
20150311 13:22:37 <Eclesia> rmk0: may I ask how looks like your 'Mesh' API ?
20150311 13:24:56 <Eclesia> Mine looks like :
20150311 13:24:56 <Eclesia> - MultiPartMesh : Skeleton
20150311 13:24:57 <Eclesia> - Mesh : 1 Vertice Buffer, 1 Normal Buffer, 1 Uv Buffer, N MorphSet(keyframes), 1 Material
20150311 13:24:57 <Eclesia> - Material : N Layers
20150311 13:24:57 <Eclesia> - Layer : Color,Texture influence diffuse/normal/specular ...etc...
20150311 13:25:22 <Eclesia> Blender makes it differently, 1 Mesh with the skeleton and N Materials
20150311 13:26:43 <rmk0> the renderer i have keeps meshes and materials separate, and doesn't know anything about skeletons:
20150311 13:26:48 <rmk0> http://mvn.io7m.com/io7m-r1/documentation/p2s8.xhtml#st200_p2s8
20150311 13:27:31 <rmk0> all it sees is static mesh data, it assumes you've performed any skeletal deformation and the like externally
20150311 13:28:28 <rmk0> i require that the user provides vertex positions, normals, UVs and tangents
20150311 13:29:49 <Eclesia> ok so you too have information for only 1 material per mesh
20150311 13:30:07 <rmk0> yeah, i think that's standard
20150311 13:30:16 <rmk0> it's pretty hard to do anything else with the constraints opengl opposes
20150311 13:30:24 <rmk0> *imposes, even
20150311 13:30:44 <rmk0> i'd expect people to be using multiple meshes per "object"
20150311 13:30:51 <rmk0> the renderer doesn't know anything about that stuff, though
20150311 13:31:06 <Eclesia> that's what I call a MultiPartMesh
20150311 13:31:13 <rmk0> right
20150311 13:34:38 <Eclesia> blender is really tricky, uses Ngons where he reuse vertices but possibly with a different UV for different materials
20150311 13:38:24 <rmk0> think their handling of UV coordinates isn't great in general
20150311 13:39:07 <rmk0> i wanted to allocate a large image, UV map a model by creating and positioning islands of vertices in that image, and then crop the image afterwards
20150311 13:39:30 <rmk0> that's the opposite to what you'd normally do... pick the final image size first and then arrange and scale islands within that image
20150311 13:39:36 <rmk0> turns out, of course, that blender can't do it
20150311 13:40:01 <rmk0> if you could decide on the image size last, you'd be able to get absolutely optimal distribution of UV coordinates
20150311 13:40:16 <rmk0> instead you have to pick the image size first and then force your coordinates into that image
20150311 13:40:31 <rmk0> means you can't use the space as efficiently
20150311 13:40:57 <Eclesia> you can always resize our imge afterward
20150311 13:41:13 <rmk0> nope, because when you resize the image, it scales all the coordinates too
20150311 13:41:33 <Eclesia> so ? you can downscale them
20150311 13:41:41 <rmk0> eh?
20150311 13:41:59 <Eclesia> S shortcut if i'm right
20150311 13:42:08 <rmk0> i'm not sure what you mean
20150311 13:42:48 <Eclesia> you can move/scale the uv on the image that's what I mean
20150311 13:43:05 <rmk0> the actual process would be: scale your image down the size you want, and scale the UV coordinates up along both axes in inverse proportion to the amount you scaled down
20150311 13:43:20 <rmk0> but it's inaccurate, and blender helpfully fights you every step of the way
20150311 13:43:56 <Eclesia> you can scale using the keyboard to have exact values
20150311 13:44:31 <rmk0> i know, and the results were always slightly wrong
20150311 13:44:43 <rmk0> actually talked about this at length with the developers
20150311 13:45:26 <rmk0> i think the traditional method of UV mapping is "wrong"
20150311 13:45:55 <Eclesia> have an alternative ?
20150311 13:45:57 <rmk0> it came about because graphics cards imposed power-of-two dimensions for images, so cropping images afterwards whilst holding coordinate positions constant wasn't an option
20150311 13:46:42 <rmk0> the alternative is to arrange islands of coordinates on a conceptually infinite-size image, and then calculate the smallest bounded rectangle that contain the islands afterwards
20150311 13:47:16 <rmk0> would give exact control over the amount of the texture allocated for each island
20150311 13:47:38 <rmk0> rather than the current method, which has people trying to force all of their islands into an image whose size was picked before the islands even existed
20150311 13:48:39 <Eclesia> you could have non-linear images like we have in netcdf files ^^
20150311 13:48:43 <sgothel> !NPOT ? thought all is NPOT by now ..
20150311 13:48:55 <Eclesia> npot ?
20150311 13:49:10 <sgothel> no power-of-two
20150311 13:49:57 <rmk0> sgothel: yeah, that was my point... in the olden days, all you got was power-of-two sized images. so you picked the largest power of two dimensioned image you could work with and then placed your UV coordinate islands into that image, usually wasting some 20-30% of the space
20150311 13:50:22 <rmk0> that restriction hasn't existed for ages, but we're still working with the same basic method (which basically involves mentally solving a bin-packing problem!)
20150311 13:50:25 <rmk0> is silly
20150311 13:51:38 <rmk0> makes more sense to get the islands arranged so that they use as much space as possible and are arranged in a manner that's convenient for artists, and THEN pick an image size by calculating a simple bounding rectangle around the islands
20150311 13:51:52 <rmk0> blender can only do the former, not the latter
20150311 13:52:47 <rmk0> you can sort of try to work around it by manually and repeatedly re-scaling both the image and coordinates, but it turns out to be hard in practice and your coordinates usually end up mangled
20150311 13:54:43 <Eclesia> rmk0: maybe I'm missing something, but you can unwrap a mesh and after add an image
20150311 13:55:25 <Eclesia> the image fits the size of the uvmap exactly this way
20150311 13:57:08 <rmk0> how do you do that? if i do these steps here: 1. create mesh. 2. unwrap mesh. 3. open uv/editor (which shows coordinates in a default square area). 4. create a new image... the uv coordinates aren't scaled, but are now stretched in appearance (because the aspect ratio of the new image doesn't match the conceptual square space blender uses internally)
20150311 13:58:06 <Eclesia> no wasted space, isn't that what you wanted ?
20150311 13:58:19 <rmk0> if i created an image that's twice as wide as the default ... empty thing ... that blender creates, i then have to scale the coordinates by 0.5 on the X axis
20150311 13:58:40 <rmk0> if i have to do any moving around of coordinates afterwards, i have to constantly re-scale each time
20150311 13:58:47 <rmk0> if i make one mistake, my coordinates are wrecked
20150311 14:29:07 <rmk0> Eclesia: are you reconstructing tangent vectors at runtime? i notice they weren't included in your data
20150311 14:29:20 <rmk0> i've heard of at least one person doing that nowadays
20150311 14:29:48 <Eclesia> I do rebuild tangent at runtime.
20150311 14:29:53 <rmk0> right
20150311 14:30:03 <Eclesia> both tangent and bitangent are stored in a single vec4
20150311 14:30:37 <rmk0> as in... tangent = v.xyz * v.w, bitangent = cross (normal, tangent)?
20150311 14:30:44 <Eclesia> that's it
20150311 14:30:48 <rmk0> right, same here
20150311 14:31:09 <rmk0> i've seen someone actually not storing that four element vector at all
20150311 14:31:15 <rmk0> basically run-time bump mapping
20150311 14:32:03 <rmk0> hrm, can't seem to find it now
20150311 14:32:21 <Eclesia> I guess that's possible with a geometry shader knowing the uv and adjaent triangles
20150311 14:33:06 <bruce-> http://www.terathon.com/code/tangent.html ?
20150311 14:33:59 <rmk0> bruce-: on the gpu during rendering, i mean
20150311 14:34:04 <bruce-> ah ok
20150311 14:34:17 <sgothel> trying a 2.3.0 build .. puhh
20150311 14:35:24 * rmk0 prepares to assault sonatype with uploads
20150311 14:40:43 <Eclesia> rmk0: do you know if there is somewhere an information about face culling in blender ?
20150311 14:41:40 <rmk0> what sort of information?
20150311 14:41:58 <Eclesia> usual , front/back/both
20150311 14:42:35 <rmk0> what... how face culling is performed during rendering?
20150311 14:44:21 <Eclesia> nop, I'm searching on the interface where the information is set. for example I have a plan and I want to have only front and not back
20150311 14:45:04 <rmk0> hm, not sure
20150311 14:47:03 <rmk0> i was under the impression that it only stored a normal vector and vertices and that if you wanted triangles to act two-sided, the plugin that was exporting the mesh had to emit more triangles
20150311 14:47:17 <rmk0> not sure why it'd be giving you both
20150311 14:48:29 <Eclesia> ha found it
20150311 14:49:08 <Eclesia> in the tools (N shortcut) > shading > backface culling
20150311 14:50:08 <rmk0> that's just for display though, yes?
20150311 14:50:49 <Eclesia> it reduces the number of triangles processed anyway
20150311 14:51:16 <Eclesia> for indoor scenes it's useless to have the outside triangles rendered
20150311 14:51:53 <rmk0> what i mean is... it only affects the display of meshes inside blender, not what data comes out of the program (which is the bit i assumed you cared about)
20150311 14:52:44 <Eclesia> well I will take it in account
20150311 14:53:08 <Eclesia> a Mesh has a culling property in my api
20150311 14:53:58 <rmk0> might not be such a good idea to let display properties affect extracted data
20150311 14:54:29 <rmk0> i could imagine artists turning those settings on and off frequently to make it easier to work on meshes
20150311 14:54:41 <rmk0> getting different data out because i forgot to reset my display settings sounds bad
20150311 14:55:01 <Eclesia> I consider it part of the model definition.
20150311 14:55:21 <rmk0> that's sort of blender's problem
20150311 14:55:28 <rmk0> the entire contents of the blend are the model definition
20150311 14:55:50 <rmk0> is why it's so hard for them to manage assets
20150311 14:59:15 <Eclesia> so you suggest, no culling ? render both faces always ?
20150311 15:00:55 <rmk0> "it depends"
20150311 15:01:09 <Eclesia> on what ? :D
20150311 15:01:22 <rmk0> i don't store culling information at all... meshes are a pile of triangles, i leave it up to the user to decide which should be culled upon rendering
20150311 15:01:46 <rmk0> but you actually want that information in the data, based on the last thing picked during editing in blender
20150311 15:01:54 <rmk0> i don't have a good answer
20150311 15:05:37 <Eclesia> hm.. information is stored on a Panel object in the blender file. let's say it's an editor view mode not part of the mesh itself. so no face culling at all by default.
20150311 15:06:06 <rmk0> i think i assume back-face culling by default, if the user doesn't specify otherwise when a mesh instance is created
20150311 15:06:12 <rmk0> is the opengl default
20150311 15:06:22 * doev (~doev@anon) Quit (Quit: Verlassend)
20150311 15:08:58 * Eclesia will think about it. rebuilding blender normal mapping in the mean time
20150311 16:54:40 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20150311 17:05:38 <sgothel> @Mark, Eclesia: there will be 2 blender import tools then?
20150311 17:06:24 <rmk0> sgothel: importing what?
20150311 17:07:25 <sgothel> importing certain blender data ?
20150311 17:07:45 <rmk0> unlikely, from me
20150311 17:11:26 <rmk0> i'm intending to start work on an inverse kinematics package
20150311 17:11:42 <sgothel> sweet
20150311 17:11:44 <rmk0> currently i get mesh data out of blender via collada
20150311 17:11:50 <sgothel> ah
20150311 17:11:56 <sgothel> _the_ format :)
20150311 17:12:03 <rmk0> will produce a program for doing skeletal animation and the like, rather than suffer through blender's animation tools
20150311 17:12:41 <rmk0> my calculus knowledge isn't sufficient yet!
20150311 17:12:52 <sgothel> https://jogamp.org/bugzilla/show_bug.cgi?id=1095 <- I don't like javascript as a client requirement for a 'forum' .. maybe you here can share your opinion
20150311 17:13:11 <sgothel> oh
20150311 17:13:22 <sgothel> IK would be nice for UI as well :)
20150311 17:13:59 <sgothel> dragging things along .. I played w/ that ole ragdoll .. w/ that java impl .. forgot name, its in jogl-demos
20150311 17:14:27 <sgothel> jbullet .. duh :)
20150311 17:16:56 * Eclesia has some ik if needed : https://bitbucket.org/Eclesia/unlicense/src/tip/api/api-physics/src/main/java/un/api/physic/skeleton/?at=default
20150311 17:22:00 * rmk0 inserts bile into bug tracker
20150311 17:22:43 <sgothel> those young folks .. next requirement for simple email is .. I don't know :)
20150311 17:22:46 * rmk0 eyes IK
20150311 17:23:02 <sgothel> why not use facebook? :)
20150311 17:23:29 <rmk0> Eclesia: hehe... i see your jacobian implementation is as complete as mine is
20150311 17:23:40 <Eclesia> XD
20150311 17:23:49 <rmk0> that's really what i was intending to do
20150311 17:23:56 <rmk0> jacobian seems to be the "best" method
20150311 17:24:03 <rmk0> just don't understand enough of the theory to implement it
20150311 17:24:07 <Eclesia> the CCD works well anyway for my needs so far
20150311 17:24:42 <Eclesia> Anddd finished !
20150311 17:24:50 <Eclesia> blender normal mapping done
20150311 17:25:53 <Eclesia> I guess I have all usual stuffs read. mesh,uvs, diffuse/normal, keyframes, skeleton, animations.
20150311 17:26:24 <Eclesia> and instancing
20150311 17:58:11 <bruce-> TextureData.getInternalFormat() returns 0 for some of my .dds files
20150311 17:58:25 <bruce-> is this intended behaviour?
20150311 18:03:46 * monsieur_max (~maxime@anon) has joined #jogamp
20150311 18:07:19 <sgothel> @bruce: I doubt .. I know we had some poor (no unit tests) patches lately .. hmm
20150311 18:08:03 <bruce-> I also seem to have problems with dds files that are in BGR8
20150311 18:08:09 <sgothel> maybe you can provide some small dds and even enhance our unit tests
20150311 18:08:19 <sgothel> (to test dds via TextureIO ..)
20150311 18:08:20 <bruce-> it seems that the pixelFormat is RGB8 for those
20150311 18:09:02 <sgothel> we have good coverage of PNG and JPEG .. (incl. tests) .. maybe you can help?
20150311 18:09:49 <bruce-> yeah, I can get the data files and expected outcome in place
20150311 18:10:25 <sgothel> TestJPEGTextureFromFileNEWT <- maybe something like this ..
20150311 18:10:35 <sgothel> you find other similar test in the package
20150311 18:10:44 <sgothel> com.jogamp.opengl.test.junit.jogl.util.texture
20150311 18:15:53 <sgothel> http://jogamp.org/git/?p=jogl.git;&a=commit&h=a622ffbced14e1e2fe797c82fc62c431ffb6949f
20150311 18:15:58 <sgothel> ^^ what do you think ?
20150311 18:16:06 <sgothel> GLBufferObjectTracker for GL 4.5: Separate GL 4.5 DSA and GL_EXT_direct_state_access
20150311 18:16:40 <sgothel> problem: they explicitly say .. no relation of GL 4.5 DSA to GL_EXT_direct_state_access (in questions)
20150311 18:16:57 <sgothel> so I have separated both .. hmm
20150311 18:17:08 <sgothel> guess no body will care :)
20150311 18:17:24 <rmk0> hehe
20150311 18:17:50 <rmk0> suspect by the time i could even reasonably use DSA, vulkan will already be everywhere
20150311 18:17:51 * Eclesia don't event know what that is
20150311 18:17:58 <Eclesia> even*
20150311 18:18:04 <sgothel> direct state access
20150311 18:18:14 <Eclesia> if you say so ^^
20150311 18:18:14 <sgothel> i.e. not using bound buffer, but pass the buffer name
20150311 18:18:28 <sgothel> damn it .. the builds .. suck today
20150311 18:28:49 * zzuegg_ (~zzuegg___@anon) has joined #jogamp
20150311 18:30:39 * zzuegg (~zzuegg___@anon) Quit (Ping timeout: 245 seconds)
20150311 19:54:22 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20150311 19:55:21 * monsieur_max (~maxime@anon) has joined #jogamp
20150311 20:26:50 <sgothel> https://www.youtube.com/watch?v=frO1T3vZNrA "long standing' .. 'if you go back, not long ..' .. lol, if it would not be so bloody
20150311 20:40:09 <Eclesia> ^^
20150311 20:41:12 <sgothel> long standing non intervention? let's see .. China, Iran, Russia .. :)
20150311 21:17:21 <sgothel> https://jogamp.org/chuck/view/fwd/job/jogl/1378/ .. looks great
20150311 21:18:06 <sgothel> will tag and release .. fancy stuff like big-fat-jar .. doxygen .. for 2.3.1 :)
20150311 21:35:06 <sgothel> http://jogamp.org/deployment/archive/rc/v2.3.0/
20150311 21:35:54 <bruce-> \o/
20150311 21:38:46 <sgothel> maven @jogamp -> 2.3.0
20150311 21:39:58 * rmk0 starts deploying
20150311 21:40:14 <rmk0> takes well over an hour to upload everything to sonatype
20150311 21:40:20 <sgothel> great - thx
20150311 21:40:27 <sgothel> tagging .. etc .. now
20150311 21:40:32 <rmk0> will be upgrading my connection soon \o/
20150311 21:41:05 <rmk0> http://idnet.net/data_products/fttc-self-install.php
20150311 21:41:20 <rmk0> pretty good for the price... free static ipv4, ipv6 subnet, etc
20150311 21:42:19 <sgothel> hmm .. me 2x 100mbit = 2x 40 EUR/month
20150311 21:42:31 <sgothel> linux load balancer / shaper .. works great
20150311 21:42:49 <sgothel> I just cannot click the 'remember me from my IP' .. since I use 2 :)
20150311 21:42:50 <rmk0> suppose that's what you get when your country invests in infrastructure
20150311 21:43:05 <sgothel> now its bought by Vodafon .. :)
20150311 21:43:30 <sgothel> so NSA knows about jogamp .. hehe .. all the ssh encrypted channels running from here ..
20150311 21:48:30 <rmk0> sgothel: jogl-core.jar seems to be missing
20150311 21:48:43 <sgothel> ?
20150311 21:49:01 <rmk0> there's no jogl-core.jar in the atomics, in jogamp-all-platforms.7z
20150311 21:49:39 <sgothel> http://jogamp.org/deployment/archive/rc/v2.2.4/jar/atomic/
20150311 21:49:44 <sgothel> neither there ..
20150311 21:50:11 <rmk0> ...
20150311 21:50:16 * rmk0 eyes deployment scripts
20150311 21:50:51 <sgothel> ls jogl/build-x86_64/jar/atomic/
20150311 21:50:57 <sgothel> no core .. here locally
20150311 21:51:08 <sgothel> what is jogl-core ? :)
20150311 21:51:14 <sgothel> isn't it now jogl.jar ?
20150311 21:51:45 <sgothel> jogl/build-x86_64/jar/atomic/jogl.jar
20150311 21:51:50 <sgothel> looks like ..
20150311 21:52:07 <rmk0> looks like i was using the wrong scripts
20150311 21:53:00 <sgothel> commit 5951b33b303df3a12888fe0fbc5ccc88112a3984
20150311 21:53:01 <sgothel> Author: Mark Raynsford <code@io7m.com>
20150311 21:53:01 <sgothel> Date: Mon Jun 30 12:45:53 2014 +0000
20150311 21:53:01 <sgothel> Attempt to remove aliasing from native libraries.
20150311 21:53:01 <sgothel>
20150311 21:53:01 <sgothel> Renamed:
20150311 21:53:01 <sgothel>
20150311 21:53:01 <sgothel> jogl-core.jar → jogl.jar
20150311 21:53:02 <sgothel> nativewindow-core.jar → nativewindow.jar
20150311 21:53:02 <sgothel>
20150311 21:53:03 <sgothel> The build scripts have been edited to produce sets of natives for
20150311 21:53:04 <sgothel>
20150311 21:53:04 <sgothel> :)
20150311 21:53:06 <rmk0> yep
20150311 21:53:20 <sgothel> you almost ruined my day :)
20150311 21:53:52 <rmk0> and mine!
20150311 21:55:18 <sgothel> tagged git repo ..
20150311 21:57:20 <sgothel> pushing tar balls & static changelogs
20150311 21:58:13 <sgothel> http://jogamp.org/deployment/v2.3.0/
20150311 22:00:17 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20150311 22:00:20 <sgothel> http://jogamp.org/deployment/jogamp-current/
20150311 22:01:23 <sgothel> http://jogamp.org/jogl/www/ enjoy
20150311 22:13:08 <sgothel> https://jogamp.org/wiki/index.php/Release_2.3.0
20150311 22:13:17 <sgothel> http://jogamp.org/
20150311 22:13:22 <sgothel> all done .. I guess
20150311 22:17:37 <Eclesia> good night +++
20150311 22:17:47 * Eclesia (~eclesia@anon) Quit (Quit: Leaving.)
20150311 22:31:50 <sgothel> .. and I am out .. nighty night
20150311 23:20:08 * rmk0 (~rmk0@anon) Quit (Ping timeout: 256 seconds)
20150311 23:42:20 * rmk0 (~rmk0@anon) has joined #jogamp
20150312 05:05:36 -jogamp- Continue @ http://jogamp.org/log/irc/jogamp_20150312050536.html