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

Yowzer, nearly 200 lines!

That in turn reminds me that the last Big Push™ I did for PDL::Graphics::Simple was the simple (ha!) task of making it handle contours. That featured moving the contour_segments operation out of TriD into ImageND, then rewriting it from 100 lines down to 19 so I could understand it (it's pretty much Marching Squares), then (because the line-segments are generated in a single pass) saving the amount of data passed to Gnuplot (etc) by joining them up into polylines with a path_join operation. Then writing my own contour_polylines algorithm because all the published ones were for computer vision stuff, not making polylines.

I can only imagine how much harder that would have been without the facilities from array programming. Would your spatial thingummy benefit from being a PDL thingummy?

Replies are listed 'Best First'.
Re^3: Creating X BitMap (XBM) images with directional gradients
by NERDVANA (Priest) on Aug 08, 2024 at 21:12 UTC
    I think it would benefit the most from some kind of CAD package that can clip polygons for me, so I don't have to do all the math manually. I was rendering semi-transparent, so I needed to prevent polygon overlap. (or use a different technique like rendering to a texture then rendering the texture semi-transparent, but that gets into zooming artifacts and awkwardness) There was also the problem where roads can turn at sharp bends and the default polygons for that look horrible without some sort of smoothing around the corner. And UGH, intersections...

    Geo::SpatialDB itself is just a database of things described in lat/lon, designed to be loaded tile-by-tile at varying levels of detail for the zoom level. I don't think that's really a PDL problem. The polygons it exports could be, if that's what a rendering pipeline wants to consume. But, PDL would need the polygon objects to be available without GLUT installed, because one of the use cases is server-side rendering.

[reply]
      I think you mentioned a similar idea elsewhere of making the TriD stuff available even when GLUT isn't available. I haven't run with that yet, because polygon objects don't really have any existence in PDL other than something like "indexed facesets", which are just two ndarrays of appropriate dimensions. The only output for those currently is into the GLUT stuff. You don't need any special code to handle two PDL objects. The code that does handle them is a couple of lines of sliceing madness, then chucking them into GLUT operations. There's no other rendering code that PDL has that could do anything with them (well, except giving 3D stuff to PDL::Graphics::Gnuplot).

      As discussed on your 3Space repo, I think it likely that bulk processing of this geospatial stuff could be quicker/easier to write with PDL (and run quicker too), but the hard grind of getting the maths right would still be there.

[reply]
[d/l]
        I kind of want a "Perl Standard Polygon Mesh Object" so that I can have modules pass those around without being especially dependent on eachother. Though, it's hard to have that when people want so many differing things from a mesh, like surface normals per polygon, or normals per vertex, or texture coordinates, texture references etc. On top of that, the most interesting meshes are the dynamic ones made by tools like Blender, and I have no idea how those are stored or processed. So, I probably don't have the expertise to define one that fits all use cases. I briefly investigated wrapping OpenCASCADE, but it's probably the most awkward C library I've ever tried to make into a CPAN module, mostly due to size and compilation speed and dependencies; even Debian divides that collection into 7 different packages. PDL can load STL files, so that seemed like a good place to focus, in the meantime.

        If I knew more about Blender models, I might try to create a standalone CPAN dist for 3D objects and then make them all PDL-compatible, and add support for them in Math::3Space and OpenGL::Sandbox and Geo::SpatialDB.

[reply]

In Section Cool Uses for Perl