#571 VRML/X3D support?

[mohawk]

Thank you for this incredible piece of plotting software!

Sorry if this has been asked and answered already; I searched for vrml in Patches and Feature Requests (no hits) and x3d (only what looked like false positives).

Is there any appetite to accept a patch implementing output of VRML/X3D? I'd start from this patch against Gnuplot 4 (http://t-kita.net/gnuplot_povrml/) that doesn't seem to have been accepted or even submitted. Background: I'm the maintainer of PDL::Graphics::Gnuplot and I'd like to be able to generate X3D files using Gnuplot's fantastic capabilities.

[Ethan Merritt]

Gnuplot was designed and originally implemented about 40 years ago in the era of pen-plotters and character cell terminals (at best!). The software design consists of an input layer, a graphics layer, and a device-output layer. That has made it easy over the decades since then to add new output devices (gnuplot calls them "terminals") through modular additions to the output layer. By the same token it has been easy to add new plotting styles and generic graphics operations in the core layer that are largely, if not entirely, independent of the eventual output device. However since 3D graphics basically did not exist at that time of the original design, the API/ABI between the core layer and the output layer is purely 2D. So it is not possible to add a true 3D module to the output layer because the third positional coordinate has already been lost before that. The core→output ABI carries only x and y coordinates.

The patch you link to attempted to bypass this restriction by adding a chunk of code to the core layer that would produce POVRAY output. But this meant it was parallel to, rather than above or below, all the normal gnuplot plotting modes. This approach only allowed it to handle plots consisting of points, lines, and gridded surfaces. It failed to handle many of the plot styles already present in gnuplot 4, let alone the new styles and graphics capabilities added to gnuplot versions 5 and 6 in the twenty years since then. The patch was rejected because it was fundamentally incompatible with gnuplot's design.

Obviously if gnuplot were being written now it would be designed differently. The ABI between the core layer and the output layer would allow 3D coordinates. Or maybe there would be a fourth layer input→core→3Dto2D→output. The added layer would be necessary for the existing output terminals but trivial/optional for hypothetical new 3D output terminals such as VRML. But that's not where we are.

What do you see as the use case for PDL::Graphics::Gnuplot with X3D output?

If it is simply for the display of flat plots (2D or pre-rendered 3D projection) inside a session using X3D protocols to communicate with the display window, then yeah it would be easy to write a gnuplot terminal module to emit a stream of X3D protocol commands. But they would not contain a useful z coordinate.

In principle would be possible to re-architect gnuplot to add a fourth layer to the code path as summarized above. In my informed opinion that would be quite a large programming task, but I'd be willing to consult or offer guidance if someone wants to tackle it. If that were in place then I imagine it would open up a straightforward path to adding terminals for VRML, X3D, Mesa, etc. Probably one could convert or replace the existing Qt output path also.

[mohawk]

Thank you for an extremely thorough explanation of the situation. I understand old software and dealing with limitations that it has, having contributed to a number of older programmes (PDL was conceived in 1996).

I'm glad that the patch linked above was actually looked at. The StackOverflow answer that linked me to it pointed out that Gnuplot's splot etc renders its 3D internal model to 2D as the mouse is moved around. My assumption was that the 3D internal model could (although clearly not at this moment in time) have other types of processing done, including having X3D etc generated from its internal 3D structures.

You raise a point I'm mentally wrestling with right now, about 2D vs 3D; I intend to implement a (fairly basic) outputter of X3D stuff from the same API currently handled by https://metacpan.org/pod/PDL::Graphics::TriD (line3d, mesh3d, etc - you can install PDL, run the perldl shell, and do demo 3d if you're remotely interested). I'm also going to add a 3D capability to the unifying https://metacpan.org/pod/PDL::Graphics::Simple, including for drivers that don't support 2D in any useful way (like the TriD one linked here) - the wrestling is how to deal with a user calling for a 2D thing when it's defaulted to a 3D-only driver.

Gnuplot's part in this would be that it would provide an alternative, and undoubtedly better, way to take in scientific data, that the user/programmer could control in a way they'll already understand, then end up with something they can either visualise as they can now, or generate e.g. X3D from, for publishing to the web.