Improving threejs() in SageMathCell

[Paul Masson]

Andrey, I have an interest in helping to improve the state of the threejs() function. Here's an example of why from my documentation project:

http://paulmasson.github.io/sagemath-docs/functions/spherical_harmonic.html

The first thing I would like to do is add the option to disable or resize labels on the axes. I'd also like to expose more of the underlying Three.js attributes for those who know how to use them.

In order to test out changes in either the JS or Python code, do I have to build an entire SageMathCell server or is there some subset of the build that would be sufficient?

[Andrey Novoseltsev]

Building SageMathCell itself is very fast, so I am not sure I quite understand the question. I have updated instructions some time ago and they worked for me to setup a development server from scratch. When you change Python code, there is no need to make anything, just restart web_server. When you change JS you have to make it which is not instantaneous, but not long. And you probably want to uncomment
https://github.com/sagemath/sagecell/blob/master/js/build.js#L4
to speed up making and ease debugging.

Having said that - if you are going to work on threejs it would be highly desirable to coordinate with SageMathCloud (I think our version is based on some old William's code) and push threejs support in terms of options/scene preparation into Sage itself. So please consider volunteering for this task ;-)

Also, in my experience the quality of JSmol is still superior to that of threejs and it is consistent across browsers/OSes. Since default plotting is done using it, it maybe worthwhile to improve its handling as well.

[Paul Masson]

On Wednesday, June 22, 2016 at 9:47:37 PM UTC-7, Andrey Novoseltsev wrote:

On Wednesday, 22 June 2016 21:00:50 UTC-6, Paul Masson wrote:

Andrey, I have an interest in helping to improve the state of the threejs() function. Here's an example of why from my documentation project:

http://paulmasson.github.io/sagemath-docs/functions/spherical_harmonic.html

The first thing I would like to do is add the option to disable or resize labels on the axes. I'd also like to expose more of the underlying Three.js attributes for those who know how to use them.

In order to test out changes in either the JS or Python code, do I have to build an entire SageMathCell server or is there some subset of the build that would be sufficient?

Building SageMathCell itself is very fast, so I am not sure I quite understand the question. I have updated instructions some time ago and they worked for me to setup a development server from scratch. When you change Python code, there is no need to make anything, just restart web_server. When you change JS you have to make it which is not instantaneous, but not long. And you probably want to uncomment
https://github.com/sagemath/sagecell/blob/master/js/build.js#L4
to speed up making and ease debugging.

Having said that - if you are going to work on threejs it would be highly desirable to coordinate with SageMathCloud (I think our version is based on some old William's code)

I'm unclear as to the exact relation of SageMath to SMC. Mr. Stein has made a number of improvements to Three.js handling in SMC: why hasn't any of that made it back to SageMathCell already? Is it for lack of someone wanting to do it, or is there some other issue in using SMC code?
 

and push threejs support in terms of options/scene preparation into Sage itself.

What do you have in mind here? The preparation in SageMathCell appears to depend on IPython messaging if I recall correctly. Would all of that need to be replicated in SageMath? Or some simpler mechanism?

Presumably for viewing it would then open a browser window to display output. How would that work when SageMath got uploaded to the cell server? Would the preparation in SageMath replace the preparation on the cell server?
 

So please consider volunteering for this task ;-)

Since I have an interest, I'm willing to put some time into it once I have a clearer idea of how to proceed. Updating the cell server is certainly easier at the moment.
 

Also, in my experience the quality of JSmol is still superior to that of threejs

I'm a bit surprised to hear this, unless it's because of lack of WebGL support on older machines/browsers. I've used Three.js enough to know that it can do amazing things, and I personally wrote one of the examples in the Three.js repository (the only one with math in it). The current implementation in the cell server certainly doesn't give Three.js the space to shine it deserves, and maybe that also is coloring your opinion.
 

and it is consistent across browsers/OSes.

JSmol cannot be used from the cell server on any Mac system, either desktop or iOS. There is always an error pertaining to synchronous data transfer.

On Windows from the cell server there is always an initial image load then a reprocessing. I find that distracting because it takes too long to process. Three.js comes up faster because it works in the browser, not externally.

And most important for the future, JSmol on the desktop is Java = security risk. I'd rather support moving to JavaScript processing or even Python interpreted in a browser rather than hanging on to Java.
 

Since default plotting is done using it, it maybe worthwhile to improve its handling as well.

 

[Andrey Novoseltsev]

On Thursday, 23 June 2016 16:11:42 UTC-6, Paul Masson wrote:

I'm unclear as to the exact relation of SageMath to SMC. Mr. Stein has made a number of improvements to Three.js handling in SMC: why hasn't any of that made it back to SageMathCell already? Is it for lack of someone wanting to do it, or is there some other issue in using SMC code?

Note that somewhat confusingly SageMathCloud = SMC = SageMathCell, but this equality is not transitive ;-) On the other hand there are similarities: both SMCs use SageMath not only with some additional interface files, but also with some tweaking. As I've already mentioned, SMCell support for threejs includes methods for graphics objects that produce "threejs input". SMCloud has to have the same type of functionality one way or the other. My guess is that no SMC got to pushing these changes into SageMath itself just because it is not as urgent as other things. There should be no legal issues since SM and SMCloud are GPL.

 

and push threejs support in terms of options/scene preparation into Sage itself.

What do you have in mind here? The preparation in SageMathCell appears to depend on IPython messaging if I recall correctly. Would all of that need to be replicated in SageMath? Or some simpler mechanism?

First you need to convert SageMath graphics into threejs description. This is unrelated to actually displaying. Then you have to pass this description to threejs which is specific to each case, but SageMath has "built in" support for IPython/Jupyter and the code used there is close to what is need in SMCell. This file is responsible for SM-SMCell display interface:
https://github.com/sagemath/sagecell/blob/master/backend_cell.py
and this is where it is "turned on"
https://github.com/sagemath/sagecell/blob/master/receiver.py#L287

Presumably for viewing it would then open a browser window to display output. How would that work when SageMath got uploaded to the cell server? Would the preparation in SageMath replace the preparation on the cell server?

If you want threejs from a command line, it will probably open a browser window, something similar is already done for other non-text types. "preparation on the cell server" is actually already "preparation in SageMath" with the only subtle point that it is a separate branch. If the code in plot files was properly documented/tested and submitted to a trac ticket for review, there will be no need for this branch at least from the threeejs point of view.

 

Also, in my experience the quality of JSmol is still superior to that of threejs

I'm a bit surprised to hear this, unless it's because of lack of WebGL support on older machines/browsers. I've used Three.js enough to know that it can do amazing things, and I personally wrote one of the examples in the Three.js repository (the only one with math in it). The current implementation in the cell server certainly doesn't give Three.js the space to shine it deserves, and maybe that also is coloring your opinion.

Old machines are definitely an issue, but my main problems are
1) displaying partially transparent surfaces
2) no "lines of fixed width" different from one pixel which is usually inadequate for projectors
 I had longer lists somewhere, but to be fair I didn't use it for quite a while
 

 
And most important for the future, JSmol on the desktop is Java = security risk. I'd rather support moving to JavaScript processing or even Python interpreted in a browser rather than hanging on to Java.

Jmol was using Java and I don't care much about that one for a long time now. JSmol is the same but in pure JavaScript, so not a problem. But it has indeed other issues so if you know threejs and can make it work well - please do!!!

[Jason Grout]

On Thu, Jun 23, 2016 at 11:06 PM Andrey Novoseltsev <novo...@gmail.com> wrote:

On Thursday, 23 June 2016 16:11:42 UTC-6, Paul Masson wrote:

I'm unclear as to the exact relation of SageMath to SMC. Mr. Stein has made a number of improvements to Three.js handling in SMC: why hasn't any of that made it back to SageMathCell already? Is it for lack of someone wanting to do it, or is there some other issue in using SMC code?

Note that somewhat confusingly SageMathCloud = SMC = SageMathCell, but this equality is not transitive ;-) On the other hand there are similarities: both SMCs use SageMath not only with some additional interface files, but also with some tweaking. As I've already mentioned, SMCell support for threejs includes methods for graphics objects that produce "threejs input". SMCloud has to have the same type of functionality one way or the other. My guess is that no SMC got to pushing these changes into SageMath itself just because it is not as urgent as other things. There should be no legal issues since SM and SMCloud are GPL.

 A bit of history: William wrote the original code in SageCloud to generate threejs objects. We (students and I) took it and then rewrote a lot of it for SageCell. Then William rewrote a lot of his code again in SageCloud. Then Andrey took over SageCell and I haven't kept track of what's happened then.

Separately, some students and I (and then some coworkers and I) worked on pythreejs, an adaptation of three.js to the IPython widget system. We're still working on pythreejs (though not very actively at the moment).

 

 

Also, in my experience the quality of JSmol is still superior to that of threejs

I'm a bit surprised to hear this, unless it's because of lack of WebGL support on older machines/browsers. I've used Three.js enough to know that it can do amazing things, and I personally wrote one of the examples in the Three.js repository (the only one with math in it). The current implementation in the cell server certainly doesn't give Three.js the space to shine it deserves, and maybe that also is coloring your opinion.

Old machines are definitely an issue, but my main problems are 
1) displaying partially transparent surfaces
2) no "lines of fixed width" different from one pixel which is usually inadequate for projectors

IIRC, this is a problem with the way opengl is rendered in Chrome on Windows (using the ANGLE library). 

 

Thanks,

Jason 

[Paul Masson]

Andrey, you're absolutely right about the difference between Jmol and JSmol. I guess I got confused because there doesn't appear to be a way to launch JSmol from the Sage command line, only in the context of a notebook. Typing "show(plot3d(...,view='canvas3d'))" at the command line still launches the Java version.

Is this a design decision? Is there some reason why the JavaScript version can't be launched in a new browser window, just like the Tachyon viewer opens a .png? This would have a bearing on how Three.js would be used on the desktop. Must it also be restricted to the notebook environment?

This is probably a discussion for sage-devel, but I'd like a bit more context before starting it there. Thanks!

[Andrey Novoseltsev]

On Friday, 24 June 2016 15:38:06 UTC-6, Paul Masson wrote:

Andrey, you're absolutely right about the difference between Jmol and JSmol. I guess I got confused because there doesn't appear to be a way to launch JSmol from the Sage command line, only in the context of a notebook. Typing "show(plot3d(...,view='canvas3d'))" at the command line still launches the Java version.

Is this a design decision? Is there some reason why the JavaScript version can't be launched in a new browser window, just like the Tachyon viewer opens a .png? This would have a bearing on how Three.js would be used on the desktop. Must it also be restricted to the notebook environment?

This is probably a discussion for sage-devel, but I'd like a bit more context before starting it there. Thanks!

You probably should look over https://github.com/sagemath/sage/tree/master/src/sage/repl/rich_output

Jmol for the command line is launched by
https://github.com/sagemath/sage/blob/master/src/sage/repl/rich_output/backend_ipython.py#L265
Nothing prevents you from making it use JSmol rather than Jmol, just make the function create appropriate web page to feed to a browser. Historically there was only Java version so it is used everywhere where the switch was not made. In principle Java has some advantages like being faster (I am actually not sure if there is anything else), but in reality I think the choice is between JS and not working at all...

I also remembered why I don't recall any threejs code in SMCell - it is in a separate coffee file
https://github.com/sagemath/sagecell/blob/master/js/3d.coffee
and the only change to it by me was move to js folder, everything else was done by Jason 2 years ago. So feel free to tinker with it and perhaps ask William where is the current version of his code.

[Paul Masson]

I finally have a preliminary version of basic Three.js support for the Sage command line:

https://trac.sagemath.org/ticket/12402

It's not yet integrated with the Rich Output backend because I want to see whether people have any interest in it first. It currently works just like the cell server: wrap any Graphics3d object with threejs(). Please do have a look!