-
Notifications
You must be signed in to change notification settings - Fork 34
Roadmap #80
Comments
List looks great. I would add better transparency handling as a priority. It's pretty broken right now. What's your opinion on the Float32. Is it not cumbersome and ugly to have to ensure all your code is using 32 floats when using gl visualize. Is the performance penalty large enough to warrant the user be explicit regarding using Float32 as opposed to Float64. |
Yeah transparency... That's a little more difficult to do efficiently. I can have a look at it, though! |
Hi Simon, Regarding the sliders/buttons/checkboxes item, a more general question/doubt is how GLVisualize will play with a GUI building tool. Implementing menus and buttons seams an very big task no? But without them how could we use the rendering capabilities in 3rth party GUI toolkit? Joaquim |
I hope to offer a nice set of GUI elements. 2016-03-25 0:28 GMT+01:00 Joaquim [email protected]:
|
Also the stuff that plotly does will be very hard to achieve without a great basis for interactive GUI's: |
Ok, and to be more direct. Don't know how much you experimented with Mirone but do you think I could hope to be able to port it to Julia using only GLVisualize? |
I think so. Most of the things you need are items on my list as well. |
Ok, I did that but as stated in the issue it basically consists in listing some of the handle graphics capabilities available in Matlab and common to other GUI building toolkits. |
Apart from following the issues and skimming through the new documentation,
I am not actually updated on the developments, nor did I get the full
understanding of how this - used to - work. I look forward to taking some
hours to go through the examples in documentation line by line, test the
arrows, and also the very interesting work I have seen posted by users with
regards to graph layout and meshing.
The below relates very loosely to your first three points - if we can lump
them toghether and call them interactivity. Interaction part is what makes
3d useful for other than presentations. The navigation needs to be second
nature, or else a good 2d representation and doing the rest of the
processing in your own brain works better for many problems. I wish for
three navigation modes as part of the packages set, or else I would soon
find myself implementing them instead of looking at the problem I wish to
solve.
1) Flying, combined with mouse-wheel perspective control. Keyboard / mouse
control as in computer games (q,w,e,a,s,d,x for camera movement and roll,
mouse for yaw and pitch) can work well.
More effective for, say, inspecting a model is: 2) Static camera /
navigation around a focus point. Perspective control is less important, and
the mouse wheel can be used for fast moving forwards / backwards. To change
the focus point by mouse clicking, we also need some kind of hit point
detection with distance.
3) Interaction mode. No navigation is strictly necessary, just the ability
to click on objects and inspect or change their properties. It is
impossible to foresee all the "users" will want to do in this mode (it
could be to change an axis label, move an object, add or remove a
connection, stretch or scale an object). So the package system just needs
to expose programmatic interfaces. I found the 'symbols' approach quite
hard to understand and inspect, by the way.
Is it a bit early to focus on OpenCL kernels for computations?
Can we hope for more lectures, blogs or publications?
|
In the simplest form it should be very quick to add a few examples... It's basically already there ;)
I hope! :)
Yeah, that's very essential. A lot of this should be straight forwad, though :) |
My 2c: Improve Camera
Add interactive Labels and Axis
remove most daring performance bottlenecks in GLAbstraction.
Seamless integration of OpenCL kernels for computations
add examples that walk you through the basic usage of GLVisualize and also some complex examples
|
For me, the main thing will be being able to use it through Plots.jl. As a fast backend for Plots.jl I could get a lot of use out of this. That's more on Tom's side though. I think compatibility with Float16's may be one way to help the GPU memory problem. Recent GPUs can store and compute on Float16s directly. Maybe not necessary, but something to think about. |
I am going through GLVisualize, attempting to learn its components. I have found the examples most helpful, but have a hard time finding out information through the API. I believe the functions in the edit and visualize folders look quite good, but I'm still figuring out how to use them (particularly textedit_signals). Perhaps I need a lower level tutorial (or could eventually create one!). |
@ChrisRackauckas the Plots backend is almost finished :) The work final work just got hold up by my vacation and rebasing some branches of mine. @ultradian sorry for the mess. This is a work which is only slowly progressing! I think I will refactor the edit and visualize folders soon and will take the chance to add a few comments! |
@SimonDanisch No need to apologize. This is a large work. I find it overwhelming to just think of what GUI elements to add as everything gets so interconnected. I have gone through |
Oh, text editing is broken right now! :( Bringing it back is my next project after merging the Plots backend ;) |
Update:
|
Issues from other packages:
Plots: |
I was wondering what I should concentrate on in the coming month to make GLVisualize a package that is pleasant to use.
I currently have this list:
What do you as users of GLVisualize think are the most important work items?
Does the API work out for you? Are the examples good to understand?
Best,
Simon
CC: @StreetLevel, @timholy, @Musmo, @joa-quim, @hustf, @dlfivefifty, @CarloLucibello, @kleinash @dpsanders
The text was updated successfully, but these errors were encountered: