#jogamp @ irc.freenode.net - 20150727 05:05:26 (UTC)

20150727 05:05:26 -jogamp- Previous @ http://jogamp.org/log/irc/jogamp_20150726050525.html
20150727 05:05:26 -jogamp- This channel is logged @ http://jogamp.org/log/irc/jogamp_20150727050526.html
20150727 06:36:18 * elect (~elect@anon) has joined #jogamp
20150727 06:36:30 <elect> hi
20150727 06:43:32 * doev (~doev@anon) has joined #jogamp
20150727 07:08:40 * doev (~doev@anon) Quit (Ping timeout: 250 seconds)
20150727 07:13:12 * monsieur_max (~maxime@anon) has joined #jogamp
20150727 08:12:24 * doev (~doev@anon) has joined #jogamp
20150727 09:39:16 <xranby> elect: hi
20150727 09:39:38 <xranby> elect: if you look at the top of the link you pasted https://github.com/sgothel/jogl/blob/master/src/jogl/classes/com/jogamp/opengl/util/texture/spi/DDSImage.java#L835
20150727 09:40:10 <xranby> elect: then you will see "3 contributors" and a "blame" button
20150727 09:40:48 <xranby> by pressing the blame button you can find out that the line 835 was written by Ken Russel
20150727 09:41:19 <xranby> l
20150727 09:42:24 <xranby> ha. github is broken! the blame view clearly lists more than 3 contributors
20150727 09:42:29 <elect> awesome, thanks xranby
20150727 09:43:33 <elect> always wondered about that button
20150727 09:43:36 <elect> lol
20150727 09:45:16 <xranby> elect: like sgothel said, git blame is the functionality of git that gives you the information which author modified which line http://git-scm.com/docs/git-blame
20150727 09:46:31 <xranby> and now you know why that button is labelled blame
20150727 09:52:54 <zubzub> afaik that functionality existed since svn?
20150727 09:52:58 <zubzub> maybe even before that?
20150727 09:54:34 <xranby> yes with cvs and svn... blame really was about quickly find out and "blame" who commited somethign to the central repository that broke the build for everyone
20150727 09:56:49 <xranby> in cvs it was called annotate
20150727 10:01:19 <xranby> but most linux commands used the blame suffix as a more memorizable way to invoke cvs annotate http://linux.die.net/man/1/cvsblame
20150727 10:11:51 * jvanek (jvanek@anon) has joined #jogamp
20150727 10:17:57 * doev (~doev@anon) Quit (Ping timeout: 255 seconds)
20150727 10:19:03 * bigpet_ (uid25664@anon) has joined #jogamp
20150727 10:21:55 * bigpet (uid25664@anon) Quit (Ping timeout: 240 seconds)
20150727 10:22:27 * bigpet_ is now known as bigpet
20150727 10:53:50 * doev (~doev@anon) has joined #jogamp
20150727 11:05:28 * eclesia (~husky@anon) has joined #jogamp
20150727 11:05:36 <eclesia> hello jogamp
20150727 11:56:51 <elect> hi
20150727 12:39:20 <eclesia> elect: finally have the dx10 in jogl ?
20150727 12:39:42 <elect> i get right pixel format and type
20150727 12:39:49 <elect> but internalFormat 0
20150727 12:40:08 <elect> anyway, I found the specs for the header size
20150727 12:40:48 <elect> 148 with dx10 header
20150727 12:48:58 <elect> how do you detect if dx10 tex is compressed, eclesia ?
20150727 12:49:24 <eclesia> the format tells you. those 180 different types
20150727 12:49:29 <elect> im just looking for values < 70 https://msdn.microsoft.com/en-us/library/windows/desktop/bb173059%28v=vs.85%29.aspx
20150727 12:49:38 <elect> I assume all others compressed
20150727 12:49:51 <elect> but I am not sure
20150727 12:50:00 <elect> for sure BCx and ASTC are compressed
20150727 12:50:17 <elect> but I have no idea of the [85-132]
20150727 12:52:56 <elect> you?
20150727 12:53:53 <elect> moreover, what do you select as internalFomat for DXGI_FORMAT_R8G8B8A8_UNORM_SRGB, GL_RGBA8?
20150727 12:54:02 <eclesia> haven't done many so far.
20150727 12:55:14 <eclesia> I don't know ^^ worse case scenario my texture importer will rebuild the image as plain rgba
20150727 12:56:03 <elect> because I guess we should use GL_SRGB8_ALPHA8
20150727 12:57:03 <elect> that matches number of components, component format and space color
20150727 12:58:36 <xranby> eclesia: elect: api's that need to convert between many different pixel A -> B formats usually solve it by converting from A -> one intermediate common format and then convert from the common format to -> B that makes the problem spce constrained enough so that a human c
20150727 12:58:47 <xranby> an implement it
20150727 13:00:56 <eclesia> that's the best way to lost some informations.
20150727 13:02:22 <sgothel> one may also consider add more conversions to PixelFormatUtil .. iff required, however, reading texture data at runtime and convert them on CPU doesn't seem to be a great idea - if that is the idea here
20150727 13:06:02 <sgothel> texture internal format usually is simply: ES3/Desktop: RGBA8 or RGB8, ES1/2: RGBA, RGB
20150727 13:06:16 <sgothel> see FBObject line 680 for example
20150727 13:06:31 <eclesia> that's a very limited view of what 'images' are.
20150727 13:07:12 <elect> sgothel, any news on the srgb fbo support?
20150727 13:07:38 <sgothel> I always update news in the bugreport, so: nope
20150727 13:09:34 <sgothel> @elect: if you change something and add features: you need to add unit tests for the old changed behavior, and the new one - to prove that all is [still] working. Best if also considering the different GLProfiles (ES2, ES3, GL3 .. core etc)
20150727 13:10:01 <sgothel> b/c as described above the texture format/type can backfire big time
20150727 13:11:15 <eclesia> there is a way to ask for the list of supported internal formats ?
20150727 13:11:50 <sgothel> @eclesia: that is a good question ..
20150727 13:12:23 <elect> sgothel, I am trying to not break anything, so there is no neeed to modify the old unit test
20150727 13:12:35 <elect> we just have to add the new ones
20150727 13:12:40 <sgothel> I started something here GLContext: getDefaultPixelDataType, getDefaultPixelDataFormat
20150727 13:13:44 <sgothel> however, maybe I should add the same for textures .. right now, the determination as in FBObject is copied a few times .. hmm
20150727 13:14:16 <sgothel> so .. good thing to put it in GLContext as well. I simply read the spec - to answer the orig question
20150727 13:15:59 <elect> anyway, I am looking at the tests right now, there is nothing about dds
20150727 13:16:02 <elect> https://github.com/sgothel/jogl/tree/master/src/test/com/jogamp/opengl/test/junit/jogl/util/texture
20150727 13:17:19 <sgothel> yup .. and that might be a problem .. i.e. to prove no regression has happened. It would be perfect to add unit tests for existing formats (where you change code) .. and then the additional new formats (thx to Eclesia and Elect)
20150727 13:17:49 <sgothel> the time we started unit tests .. all this code already existed .. hence not everything is covered _yet_ :)
20150727 13:18:02 <eclesia> and also be able to transform images for older profiles when they are not supported
20150727 13:18:05 <elect> but I see a dxt1-5 text inside
20150727 13:18:16 <elect> anyway I will check better that later
20150727 13:18:26 <sgothel> @eclesia: that is the thing .. hmm
20150727 13:18:57 <sgothel> we could either simply bail out .. in this case the application shall pick the right format regarding the GL profile (preferred way)
20150727 13:19:37 <sgothel> AFAIK this is how we usually do it today .. since a CPU conversion for possibly huge textures is not desired
20150727 13:20:05 <sgothel> otherwise we would need to be able to query whether the texture format is natively supported in hardware .. oh dear :)
20150727 13:20:16 <elect> sgothel, do you have a contact of Ken Russell?
20150727 13:20:31 <sgothel> then things get complicated and we defer from the whole point of hw acceleration
20150727 13:21:12 <elect> but conversion is something that should be done just once
20150727 13:21:22 <xranby> elect: Ken Russell now work at google inside the Khronos WebGL team.
20150727 13:21:35 <elect> I saw, but I didnt manage to find anything
20150727 13:22:39 <sgothel> I guess it would be best to use existing information and solve it, doubt he knows anything or wants to know .. >10 year old code here
20150727 13:23:54 <eclesia> sgothel: or maybe there is a list of minimal supported formats for each profile somewhere ?
20150727 13:24:19 <sgothel> in the spec - yes, and that is what I have used in the code snippet referenced
20150727 13:24:29 <xranby> elect: https://twitter.com/gfxprogrammer
20150727 13:24:40 <elect> xranby, thansk
20150727 13:24:45 <sgothel> and this is logic is also applied in Texture...
20150727 13:25:39 <elect> I know sgothel, I will try to ask and see what he replies
20150727 13:26:55 <elect> anyway for "broad hardware support" MS itself suggest to use much fewer formats than the 180
20150727 13:27:01 <elect> https://msdn.microsoft.com/en-us/library/windows/desktop/bb943991%28v=vs.85%29.aspx
20150727 13:27:31 <elect> we could start supporting those
20150727 13:27:34 <xranby> elect: what excites you about the dx10 image formats?
20150727 13:27:52 <elect> I need it for the jogl-samples
20150727 13:28:21 <xranby> do microsoft hold any patents related to dx10 image formats?
20150727 13:28:30 <sgothel> personally: the whole DX texture stuff is sick, IMHO. Applications shall prepare the assets according to the running platform and use hardware accelerated texture decompression as supported in ES3, GL3, .. etc - oh well, its just me :)
20150727 13:28:31 <elect> I have no idea
20150727 13:28:34 <eclesia> xranby : 1,2,3,4 band image, byte, short, float types mostly. convinient for normal maps etc...
20150727 13:29:14 <elect> I totally agree sgothel, but many people use DX textures..
20150727 13:29:22 <elect> GLI support them out of the box
20150727 13:29:52 <sgothel> only via CPU conversion - so what is the point?
20150727 13:29:56 <elect> I see it like, we shouldn't push them, but at least support them
20150727 13:30:14 <elect> at least the most common
20150727 13:49:39 <eclesia> ... or you could consider it to be the job of third party image libraries :D