@Leah Hanson That's quite an interesting use-case as it is a good example for a huge dataset, that won't even fit on the screen. Rendering them is mainly a problem of streaming and not rendering occluded objects, which should be integrated to the lower-level abstraction API. Its also something rather complicated, but I guess it doesn't hurt to keep it in mind. I wanted to start with this by not rendering items, that are out of the window bounds ;)
2014-05-19 22:02 GMT+02:00 Leah Hanson <[email protected]>: > I'd like an interface that would make it relatively easy to implement > something like this: http://ubietylab.net/ubigraph/ > > I've run into (and had friends run into) problems visualization (directed) > graphs with thousands to hundreds of thousands of nodes. Ubigraph, linked > above, tended to crash at close to a thousand nodes when I was using it a > few years ago. I'm not aware of a tool to visualize graphs with thousands > or more nodes. > > -- Leah > > > On Mon, May 19, 2014 at 2:35 PM, Simon Danisch <[email protected]> wrote: > >> As I already said, your point is definitely valid. And that's why it is >> certainly a good idea to implement VTK bindings for Julia. >> But that person wont be me. >> I'm doing this project for very special reasons, and among others, one is >> that I'm sick of the fact, that every good visualization/3D rendering >> package is implemented in a language, that I don't want to use. I don't >> want to start a discussion about C++ here, but I think most people would >> agree, that it has a lot slower development cycles than higher level >> languages. >> That's why I ended up with Julia, because I'm hoping it's one of the >> first languages to make it possible to implement something performance >> sensitive like a 3D rendering engine in a fun to use language. >> Which would be awesome, as the other fun packages would have direct >> access to it, and not like in most other languages, have slow performance >> or work with a black box for visualizations. >> >> >
