in reply to Re^7: Creating X BitMap (XBM) images with directional gradients
in thread Creating X BitMap (XBM) images with directional gradients

I think trying to be ultra-fast from day 1 might be premature optimisation? Making something that works correctly (with automated tests) can then be made quick.

Though getting things "right" using separate ndarrays for each thing named above, and maybe sellotaping them together into objects later would probably also be processable quite quickly. Yes, I think I'm suggesting prototyping with PDL. It already has code to do OpenGL, including animation, and responding to user inputs (e.g. rotating the view around, while the molecule demo runs). It doesn't yet have textures, but that shouldn't be too agonising to add.

  • Comment on Re^8: Creating X BitMap (XBM) images with directional gradients

Replies are listed 'Best First'.
Re^9: Creating X BitMap (XBM) images with directional gradients
by NERDVANA (Priest) on Aug 15, 2024 at 05:10 UTC
    OpenGL::Sandbox already has textures, but more importantly, Buffer Objects which can be memory mapped to load them with data, and then used in shaders. In other words, I'm already to the point where I'd like to have Model data packed in buffers so I can just dump it into the graphics card quickly. Even more awesome would be if I could pre-allocate the memory-mapped buffers for the Model object prior to loading an STL file so that the data was already in the graphics card by the time it finished loading. *that* would perhaps be too much optimization.

    Maybe equally awesome would be if there was an option to tell PDL to use a memory buffer of the caller's choosing as the storage for an ndarray, so that I could have it backed by one of the memory-maps.

[reply]
      PDL absolutely could acquire such an ability. It would "only" (ha!) require new code in openglq.pd to make extra PDL operations.

      Spitballing a design, they'd take an OtherPars parameter that was a pointer Perl/C object, OR a an ndarray Par that was indx to capture pointers in a way that would broadcast naturally. I think a good starting point before cutting code would be to see what quick wins there were to steal working code/ideas from OGL:Sandbox into PDL's TriD, and textures is an obvious candidate. Are there others?

[reply]
[d/l]
[select]
        steal working code/ideas from OGL:Sandbox into PDL's TriD, and textures is an obvious candidate. Are there others?

        The single most awesome bit of code in OpenGL::Sandbox is $program->set_uniform. The documentation doesn't do it justice, but it performs magic that lets you set the uniform values for the shader in a very convenient manner. There might be an interesting way to tie that into PDL in a passive manner so that the user specifies everything in terms of PDL arrays, and PDL magically broadcasts into the graphics card for the final step instead of broadcasting across CPUs. (that's what Uniforms are, basically; global variables that get broadcast to N texture units each running a copy of the shader, and each with shared access to any of the texture or buffer objects that you have loaded.)

        Feel free to steal the code. I feel like it hasn't received its return-on-investment for the number of hours I put into it.

        For textures, you need to weigh the convenience vs. adding a dependency on PNG and JPEG libraries. But, you can always fall back to raw uncompressed RGBA files.

[reply]

In Section Cool Uses for Perl