Visualizer

[fredrikbk]

It would be great if someone could develop a visualizer (or integrate an existing one).

Our current visualizer has gone unused and experienced code rot. I also believe it uses glut and we'd like to use glfw for cross platform. We should style our visualizer on the one in libigl, and maybe even make libigl an optional dependency and use their visualizer.

[symek]

How about https://github.com/wjakob/nanogui ?

[fredrikbk]

That could work! Nanogui is the library used by newer version of libigl and it looks really neat.

[symek]

So, the question is whether to go with libigl integration as you mentioned or do a viewer from scratch (or rather from copying code of instant meshes (which I suspect to be referential for Nanogui, but haven't checked it yet).

[fredrikbk]

Yes exactly. I think it's better to build a new Simit viewer, because over time we may want to extend the visualizations with general (non-physical) graphs and things like MATLAB-style matrix spy. It would also free us from depending on libigl (for practical purposes and since it is licensed under a different license than Simit).

Would you perhaps be interested in taking this on?

[symek]

I definitely would, though with my moderate experience in C++ and OpenGL, I'm a little skeptical. What would be, in your opinion, a reasonable time frame for this task?

I was actually about to ask you about different and probably much harder Simit task, so this one might be good staring point for me.

[fredrikbk]

That's great! We can certainly use the help. I think a simple bare-bone viewer might be 10-50 hours, depending on experience with that sort of thing. I do like the API of libigl's viewer so that would be a reasonable starting design. A good viewer could take a lot of time of course, but something simple would be really useful and the good thing is that it is a pretty self-contained project!

I think an easier place to start though, if you're looking to get warm, would be to clean up the mesh loader API and add support for formats (attributes, .dot etc) (see e.g. #32). I also have some ideas for a new simit-run tool that would make it really easy to get started that I'll file as a separate issue.

If I may ask, what was the other task?

[symek]

Thanks for encouraging! I would definitely follow some good examples from sources like libigl (doing some work with it currently). I was also thinking about looking into mesh loader issue.

As to my task, I wanted to ask for your opinion anyway before blindly jumping into it: I was thinking if it would be feasible to develop an alternative frontend of Simit, much in spirit of halide: http://halide-lang.org, which is a language embedded in C++. Would it ruin optimization process? (hopefully not) Does it look like re-implementing much if Simit? (hopefully not, I'm guessing bulk of the job is done much later on llvm assembly/ir?). Obviously without knowing more, I can't be sure how stupid this idea sounds, but my first impression was, that when one wants to use Simit for practical job, first thing he wants, is to make it freely talk to C++ program itself, jump between collision phase and linear solve, make it as transparent for main application as possible. I think Simit design objective was to compete with Matlab with syntax simplicity and brevity, which doesn't have to be so important while developing a real-life tool. This is all premature, as I haven't tried yet to do anything beyond examples, so sorry if I am confusing something here, this is obviously all based on an assumption that C++ embedding wouldn't change much of Simit and wouldn't take significant amount of work.

[fredrikbk]

Halide does have a great design! A similar Simit frontend would not ruin optimization at all, and would also not re-implement that much since most of the work is in the compiler core. I originally tried to design Simit with a pure C++ library interface, without any online parser.

However, I chose to add the language syntax that is compiled through the C++ library much like OpenGL SL and DirectX shading languages. The reason for this choice was mainly that Simit code is imperative, which makes it cumbersome to define functions through a non-parsed library interface. Halide has the benefit of having functions whose bodies are expressions, which let them make a very intuitive interface. I'm not saying a good library interface can't be made for Simit, it's just that it probably would not be as convenient as Halide's.

As for making Simit freely talk to C++ programs, that can be done right now. Simit is a C++ library and IO with Simit is done through a C++ graph data structure. For example collisions could be detected and provided to Simit as an edge set, from which a collision resolution matrix can be built. The fact that the library calls a parser to parse the Simit programs has no effect on this interoperability. However, some people prefer to use pure libraries, and for them a non-parsed API would be good.

Finally, we do have an API for building programs. This is the API that the parser uses to build the Simit IR. However, this API is not nearly user friendly enough for end users, so an alternative frontend could be built on top of it to make it easier to use.