Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feature request: rotate 3D plots #47

Closed
mars0i opened this issue Jun 8, 2017 · 5 comments
Closed

feature request: rotate 3D plots #47

mars0i opened this issue Jun 8, 2017 · 5 comments

Comments

@mars0i
Copy link
Contributor

mars0i commented Jun 8, 2017

This might be planned anyway--I know that work on the plot routines are in progress--but it would be helpful to be able to specify the orientation of 3D plots. Thanks for including the plot routines. I just took a look at plplot, and I appreciate the way in which Owl greatly simplifies usage, as Tutorial 4 notes.

@mars0i
Copy link
Contributor Author

mars0i commented Jun 16, 2017

I think I see what additions would be needed. At the moment I'm having trouble compiling Owl ("Unbound value Eigen.Dense.S.gemm" in owl_dense_common.ml--I'll investigate further), so for now I thought I'd just document what additions I think would be needed to allow different perspectives on 3D plots.

In owl_plot.ml, one would add the following.

In type page {...}:

mutable altitude : float;
mutable azimuth : float;

And somewhere in the same file:

let set_altitude h s = (h.pages.(h.current_page)).altitude <- s
let set_azimuth h s = (h.pages.(h.current_page)).azimuth <- s

and in the definition of _prepare_page, in the 3D plot section, in the call to plw3d, replace 33. by p.altitude, and 115. by p.azimuth.

And add signatures and comments for set_altitude and set_azimuth to the .mli file.

See http://plplot.sourceforge.net/docbook-manual/plplot-html-5.12.0/plw3d.html and http://plplot.sourceforge.net/docbook-manual/plplot-html-5.12.0/plw3d.html .

@ryanrhymes
Copy link
Member

Yes, adding more fields to page type can be one solution. Another possible solution is incorporating the orientation parameters into the plot functions. You might already notice that Owl caches all the drawing operations then executes them one by one in the final stage. So it might be possible to cache that orientation parameters in the drawing function.

But this is just my current thought, I don't know myself whether it works or not. Or if that is really a cleaner solution comparing to add more fields to the page type.

@mars0i
Copy link
Contributor Author

mars0i commented Jun 21, 2017

OK, I'll look into those possibilities.

@mars0i
Copy link
Contributor Author

mars0i commented Jun 22, 2017

I have altitude and orientation working as fields in the page in the way I described above: https://github.com/mars0i/owl/blob/master/lib/owl_plot.ml . I added functions set_altitude and set_azimuth to allow setting these values in the page structure.

The altitude and azimuth are used by the plplot function plw3d, which sets up some of the 3D parameters. This is the only way to set the viewing perspective, as far as I know. plw3d is already called in _prepare_page in owl_plot.ml, so I simply modified that call so that it would use the altitude and azimuth from the page.

It makes some sense to store altitude and azimuth in the page structure, since plw3d uses values from xrange/yrange/zrange, which are also stored in the page.

About passing altitude and azimuth to mesh and surf:

Summary: altitude and azimuth should remain as fields in the page structure; there's no other good way to store for execution by output. It would be easy to add these as optional arguments to mesh and surf for these values (i.e. to cause them to be stored in the page structure). I don't have a clear opinion about whether this makes sense from a user perpsective.

At present, the optional parameters for mesh and surv are the handle and a contour boolean. So viewing altitude and azimuth would be parameters of a different category than what mesh and surf have now. However, many of the 2D plotting functions have parameters that affect display, so maybe this would make sense.

plw3d is not currently called in mesh or surf but is called in _prepare_page, and plw3d shouldn't be called within either the body of mesh and surf or in the function that they store in p.plots. In that case the call to plw3d would be overridden by the call to plw3d in _prepare_page when that is called in output. So the best way to set the altitude and azimuth from mesh or surf would be to set fields in the page structure, just as p.is_3d is currently set in these functions.

I guess for me, personally, I'm not sure that it makes sense to have optional altitude and azimuth parameters for mesh and surf, because I already set a number of other page parameters, so it's nature to set a couple of additional ones rather than passing arguments to mesh.

What do you think?

No need to comment immediately if you're busy, of course.

@mars0i
Copy link
Contributor Author

mars0i commented Jun 22, 2017

Thinking about it further, it seems like it would be very convenient for experimentation in utop if mesh and surf had optional arguments for altitude and azimuth. I'll implement that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants