Perl 6 - the future is here, just unevenly distributed

IRC log for #pdl, 2014-12-13

| Channels | #pdl index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
09:45 Mithaldu chm: do you maybe have an idea how i flip the data in an OpenGL::Image object?
17:33 chm joined #pdl
17:34 chm Mithaldu: I haven't used the OpenGL::Image stuff much since most of my processing is through PDL but here are some ideas:
17:34 chm If you are using as a texture, maybe you might not need to flip at all.
17:35 chm You could always use read/write pixels to and from and opengl buffer to do the op
17:35 chm I think if you have Perlmagick installed for the image magick engine there is a Flip() method and I'm sure much more
17:36 chm Don't know about doing so with the default Targa engine since it is pretty minimalistic
17:36 chm BTW, this is exactly the thing where a PDL::Tiny or some such would be nice to have
19:16 Mithaldu chm: i'm using IM and the issue is that the Magick engine of O::I does a bunch of flips on its own
19:16 Mithaldu it also has some kind of attribute called flipped, but that is only set to 1 once and never used again
19:17 Mithaldu and when i tried to flip the native image, it actually managed to crash perl
19:17 Mithaldu i was hoping you knew of a sane way to simply tell it "no don't flip this" or "reverse the flip"
19:18 Mithaldu as it stands, i simply reverted to using I::M directly with OpenGL::Array
19:18 Mithaldu (although now i'm running into the issue that my mesh importer is fucked)
19:33 Mithaldu great, this makes even less sense
19:34 Mithaldu the same image loaded by I::M in c code and dumped to an RGBA block does not result in the same file when i do it in perl
19:35 sivoais O_O
19:37 * sivoais had a problem like that once...turns out it was a linking mistake...patched system library vs. Alien:: library with no patches
19:37 sivoais that took a while to figure out
19:38 Mithaldu well, it is different libraries, but there's no way to tell which one's the right one
19:38 sivoais is it just the y-dim that's flipped?
19:39 Mithaldu even that i'm not 100% sure
19:39 Mithaldu i put glintercept inbetween the thing and it dumps the texture data as sent by glTexImage2D into a png file
19:39 Mithaldu and that file looks flipped for the perl script
19:40 sivoais ugh...sounds like a coordinate system problem. Different libraries have different ideas about coordinate systems. I have this problem sometimes with my research
19:44 vicash joined #pdl
19:44 Mithaldu motherfucker
19:44 Mithaldu i can't believe it
19:44 Mithaldu this file, clearly labeled phoenix.pcx
19:44 Mithaldu is actually a jpg
19:44 Mithaldu no wonder i'm getting noise differences
19:44 vicash File::LibMagic ++
19:45 Mithaldu wouldn't have helped me
19:45 Mithaldu i had no reason to suspect this file had been fucked with
19:49 Mithaldu ok, now the dumps are identical
19:53 Mithaldu which leaves only the question: why is the texture upside down on my model :|
19:53 sivoais maybe "You need to account for the fact that OpenGL's origin for textures is in the lower left corner (and not the upper-left corner)."?
19:53 sivoais <http://stackoverflow.com/questions/16500345​/upside-down-texture-opengl-es-2-0-android>
19:54 Mithaldu it's the same code
19:54 Mithaldu only one is in perl, one in c
19:54 Mithaldu i suspect it's because the mesh importer i'm using "optimizes" the mesh
20:02 chm Mithaldu: It looks like you've covered the gamut of possible suggestions I could have made.
20:02 Mithaldu yeah, i'm mostly using the channel as a rubber duck :)
20:03 chm Regarding OpenGL::Image, I am not really familiar with it but inherited it when I adopted OpenGL
20:03 Mithaldu also, i found an insignificant bug in the original c code, after the removal of which the gl logs should be identical
20:03 Mithaldu chm: oic
20:04 Mithaldu in that case i would recommend adding some kind of alpha warning indicating that the API has not been thought through whatsoever and is as of yet only half-implemented
20:04 chm Mostly because I was hoping to replace the OpenGL::Array with something simpler, orthogonal, and PDL compatable
20:04 chm That would suggest that I know enough about the api to issue such a warning.  :-)
20:04 Mithaldu i'm open to any suggestion, you know where to find my code :)
20:04 Mithaldu i know enough and i'm telling you :P
20:05 Mithaldu the thing has attributes that are never used
20:05 Mithaldu if that isn't half-implemented, then i don't know what is
20:05 chm Yes, the POGL2 work planned this holiday season is to address some of the bitrot in various modules
20:06 Mithaldu glUniform3f(41,0.000000,0.000000,0.000000)
20:06 Mithaldu glUniform3f(41,-1.#IND00,-1.#IND00,-1.#IND00)
20:06 Mithaldu first line is perl
20:06 Mithaldu second line is C
20:06 Mithaldu what the hell is c trying to tell me? :|
20:07 chm I'm not up to the shader stuff.  Sorry.
20:07 Mithaldu that's not even shader stuff
20:07 Mithaldu that's a plain old log of a c call
20:09 Mithaldu also, on less frivolous things
20:09 Mithaldu the last thing i'll say on O::I is that as it is it's a rake lying in tall grass with the pointy bits upwards
20:10 chm I found this info: http://stackoverflow.com/questions/34792​0/what-do-1-inf00-1-ind00-and-1-ind-mean
20:10 chm Oops, I have to go mail a package before the post office closes, later o/
20:10 Mithaldu even if you don't want to carry it away, i'd consider it polite to leave a sign that it's there
20:10 Mithaldu have fun
20:10 Mithaldu and thanks
20:10 Mithaldu oh it's undef
20:10 Mithaldu useful
21:37 chm joined #pdl
21:37 chm Mithaldu:  corrrection, I don't have any module perms for OpenGL::Image
21:38 chm (Probably why I haven't looked at it much...)
21:38 Mithaldu ooooooh
21:38 Mithaldu ok then!
22:26 mohawk joined #pdl

| Channels | #pdl index | Today | | Search | Google Search | Plain-Text | summary