Sister blog of Physicists of the Caribbean. Shorter, more focused posts specialising in astronomy and data visualisation.

Tuesday 5 April 2016

Testing PyQTGraph



Having nothing much else to do while I wait for certain lazy co-authors such as Robert Minchin to respond, my afternoon has been spent investigating PyQtGraph.

Took < 5 minutes to install and about 15 minutes to hack the example code to load my own data set. Doesn't look so impressive in the screenshot I guess, but it's a realtime volumetric render, so I can move the display around easily. The really impressive thing is that it took all of 10 seconds to load the data - FRELLED would take more like 2 minutes for a cube this size. I suspect it's using a similar technique to FRELLED - mapping the data on to planes - but with a vastly more optimized engine.

Of course, I have no clue how to change the colour scheme or do anything useful with this, because the code is uncommented.  But this warrants further investigation.

6 comments:

  1. Sounds interesting. Stop distracting me when I'm trying to read your paper! :)

    ReplyDelete
  2. No idea what format your data is in or how much you have but have you considered using a game engine to render things?
    I've been experimenting with Unity3D for point cloud rendering (https://www.youtube.com/watch?v=Q8SnPSf57WA - low res recording experiment but it runs at 60 fps for 4.8million points). There's also Unreal Engine 4. Game engines have received tons of work to render ultra complex scenes and easily on a variety of GPUs.

    ReplyDelete
  3. Oliver Hamilton Nice !

    Yeah, I've thought about using a different engine from time to time. It's a case for finding enough spare time to do it. I did try playing with Unity a few years back, but not to any serious degree. I see it's got a Python interpreter these days, which is very intriguing...

    I work with particle and grid data. Blender's pretty lousy for particle data : starts getting sluggish with more than a million vertices and you can't give each one an individual texture or material. Actually you can't give them any sort of material in the realtime view and it has serious problems with combining transparency of particle and mesh materials. 

    One of Blender's major weaknesses is that it's not happy when you start having large numbers of objects or materials. Hence if I have 10,000 particles I have to bin them to give them different colours. Grid data I can import as image textures on planes. That's good up to cubes ~600 pixels on a side at around ~10 fps. I'd love to know how that compares with Unity.

    This would probably be a good time for me to explore new options. The bulk of my code is in standalone Python scripts so all the important astronomy stuff can be done externally to the rendering engine. Pretty nearly all of my internal Blender Python code is designed for 2.49, which has been obsolete for years, but more modern version look to be user-hostile when it comes to designing custom GUIs. It might actually be easier at this stage to switch to a new engine...

    ReplyDelete
  4. Rhys Taylor I would highly recommend Unity in that case! We recently exported a blender simulation to Unity/Unreal Engine as in blender it was taking hours to simulate output from a camera - unity was real-time :)

    ReplyDelete
  5. I'm downloading it right now. :)

    ReplyDelete
  6. Here's a good point cloud example that might help you get started https://www.assetstore.unity3d.com/en/#!/content/19811

    I'd also recommend these two tutorials 
    http://unity3d.com/learn/tutorials/projects/roll-ball-tutorial

    http://unity3d.com/learn/tutorials/projects/space-shooter-tutorial

    Both are nothing to do with what you want to do. But they do give a great into to how unity works.

    ReplyDelete

Red, dead, but very well-fed

What stops galaxies from forming stars ? Normally I'm most interested in this for objects which have hardly any stars at all : ultra dif...