please add commandline option to render design to image about openscad HOT 66 CLOSED

assurancetourix:~/3d/wormgear> openscad conveyor.scad -o conveyor.png
Compiling design (CSG Products normalization)...
Normalized CSG tree has 20 elements
assurancetourix:~/3d/wormgear> unsetenv DISPLAY
assurancetourix:~/3d/wormgear> openscad conveyor.scad -o conveyor.png
Compiling design (CSG Products normalization)...
Normalized CSG tree has 20 elements
Unable to open a connection to the X server
Can't create OpenGL OffscreenView. Code: -1.
assurancetourix:~/3d/wormgear> 

from openscad.

Just for the record, this might be usefull:
https://virgil3d.github.io/

VirGL virtual OpenGL renderer, which allows virtual machines without GPU to run software dependent on opengl acceleration.

from openscad.

This is a bit tricky to get right as it's highly OS dependent. I started on the code for doing this properly in the visitor branch (tests/cgalpngtest.cc), but so far it only works on Mac OS X. Help porting this to Linux&Windows would be welcome :)

from openscad.

kintel: thx for your efforts, it would be really nice if it can be done... Maybe i can test something on Linux, but i don't feel like porting it myself, because i have no experiences with OpenGL (or whatever you use) and therefore no idea how to do it. I thought that it would be as simple as calling some OpenGL function to dump the bitmap from (hidden) window...

from openscad.

I think that Linux version is most important because this feature will be usefull especially on Linux servers (like thingiverse.com which often fails to render .scad files properly right now...)

from openscad.

" I thought that it would be as simple as calling some OpenGL function to dump the bitmap from (hidden) window..."

I thought the same thing. But it is not so easy. In OpenGL, there are lots of ways to do offscreen rendering, but most of them don't work or are deprecated (Auxiliary Buffers, Pixmaps, PBuffers). The 'accepted' way is using a Framebuffer Object, but you need a working OpenGL Context to do that. How do you get an OpenGL Context? You normally would open a window, which we don't want to do.

In Mac OSX, Marius was able to get a context without a window (i think) by using NSOpenGLContext and the NSOpenGLPFAPixelBuffer attribute. Linux doesn't have that. It has GLX and X11, and glXCreateContext. You have to worry about if you are on GLX 1.2 or 1.3, and whether your OpenGL driver supports the EXT version of the Framebuffer Object or the ARB version. Alot of this is not documented very well.

As far as I can tell, these linux functions also require an X server to be up and running. There is a theoretical possibility to do things completely in software rendering with something called "OS Mesa" but that has it's own complications. (and some might say, what about the shell variable LBGL_ALWAYS_SOFTWARE =1 ? It doesn't always work)

I could be wrong but it's what I have figured out so far.

from openscad.

Oh, forgot to mention glXCreateNewContext is for GLX 1.3, and glXCreateContext is for GLX 1.2. Both require different setup-routines to be gone through.

from openscad.

@donbright i am sure that i saw some kind of fake X server (xfb,xvfb,tightvnc which are ugly that you need another process to e running, but i guess it's not big problem if you really need it) or some way to redirect X connection to null for cases like this. but it's still not completely portable.

I think that you can make some portable solution that will make the window flash shortly on the screen before you'll figure out how to do this. BTW isn't it possible to create hidden window? will this still need X connection? will it still initialize glx context? Can't you check how the glx context is created in routine for creating window?

from openscad.

This seems to be working:

nc -l -p 6011&  # OR socat TCP-LISTEN:6011 STDIO&
DISPLAY=':11' xterm

but i am not sure if xterm is really running on background or if it waits for some handshake/negotiation from xserver...

from openscad.

Harvie thanks for the ideas, can you run OpenGL over netcat? The best I have been able to do so far (in my visitortests fork) is to create a GLXPixmap, and create a Context using that, sort of like Marius does in his Mac OSX work. I don't know if this will work with a 'fake' X server. It works on my machine but it won't work in a VMWARE linux session (openscad itself works fine in a VMWARE linux session).

from openscad.

Just for another example of how non-trivial this is, here is an example of a bug in Mozilla, they are trying to do Offscreen OpenGL. It has 103 comments and spans 10 months, for one single bug. There are numerous duplicate bugs linked to as well. Basically, some implementations of a certain GLX setup function do not report failure, other than printing a "bad drawable" message to the screen, which it's hard for a program to detect at runtime (you generally don't read your own output buffers, if you did, youd have to then re-print them yourself, and deal with buffering issues yourself?).

https://bugzilla.mozilla.org/show_bug.cgi?id=589546

It's not impossible, it's just slow going.

from openscad.

it also seems to be hardware-dependent capability :-( can't we just switch opengl to "software" (CPU) rendering mode to simplify the things? I think that we do not need to render picture extremely fast as we don't need realtime rotation, etc..

he answer is "no, it's not". However, it is very widely supported on most modern cards and chips, so you really need to research your user base, find out more about what hardware they have, and write your code to target that hardware.
(from http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=287046 )

from openscad.

Even with software rendering you have to open an OpenGL context into your software renderer, and there is no standard way to do that. OSMesa might work but it introduces yet-another-library dependency that you would have to specially-compile to get OpenSCAD running. Here are some examples of problems others have had with OSMESA:

http://learningwebgl.com/blog/?p=2266
http://www.underworldproject.org/documentation/OSMesaDownload.html
http://www.vtk.org/pipermail/vtk-developers/2009-February/005785.html

Note the 'underworld' project doesn't use OSMESA on its Mac port, even though theoretically it should be 'easier'.

from openscad.

How about something like the following code?
This might only work on machines with OpenGL 2 drivers. We might have to first create a non-pbuffer context and query that context for PBuffer support, and fall back to software rendering if we cannot do PBuffers.

AFAIU, a PBuffer context is a hardware-accelerated context which enables us to create and render to e.g. FBOs without having to have visual pixels.

#include <GL/gl.h>
#include <GL/glx.h>

int main(void)
{
Display *display = XOpenDisplay(":0");
const int single_buffer_attribs[] = { GLX_DRAWABLE_TYPE, GLX_PBUFFER_BIT, None };
int fbconfigs_len;
GLXFBConfig *fbconfigs = glXChooseFBConfig(display, DefaultScreen(display),
single_buffer_attribs, &fbconfigs_len);
GLXPbuffer pbuffer = glXCreatePbuffer(display, fbconfigs[0], NULL);
GLXContext context = glXCreateNewContext(display, fbconfigs[0], GLX_RGBA_TYPE, NULL, True);
glXMakeContextCurrent(display, pbuffer, pbuffer, context);

// We now have a HW-accelerated context and should be able to create FBO's
// and off-screen render to them 

glXDestroyContext(display, context);
glXDestroyPbuffer(display, pbuffer);
XCloseDisplay(display);

return 0;

}

from openscad.

Marius: I tried that on a VMWARE installed with Ubuntu 10 - it segfaults during the call to glXCreatePBuffer. IIRC there's even a document somewhere that says 'this might never work'.

I think a solution might be to XCreateWindow and then never call XMapWindow, so it is "hidden". (I shoulda listened to Harvie at the top of this thread. ) then create the FBO off of that.

But there is still the issue of GLX versions that are not compatible, for example Mesa on Ubuntu 10 inside VMWARE claims to be GLX 1.4 on glxinfo, but if you try to use the FBConfig VisualInfo setup functions like glXChooseFBConfig, (which were introduced in GLX 1.3), it doesn't work. You can verify this by apt-get source mesa-utils (the Mesa demos) and trying to run glxgears-fbconfigs and glxgears-pixmaps. Both break under Mesa shipped with Ubuntu 10 under VMWARE, while plain old glxgears (using GLX setup functions that existed in GLX 1.2) it works fine.

But if you try to run a program using FRAMEBUFFER_EXT using GLX 1.2 setup functions, sometimes it doesnt work even though your glx driver says it supports FRAMEBUFFER_EXT (like on my machine). And sometimes it will complain with a "Application calling GLX 1.3 function "glxCreatePixmap" when GLX 1.3 is not supported! This is an application bug!" if you use the 1.3 functions (other things besides glxCreatePixmap can cause this).

Also, sometimes the GLX creation functions don't return an error and don't return NULL like they theoretically should.

I know some people say 'tell users to upgrade their drivers'. But Openscad (via QT's GL) works so damned well in so many places, I would hate to think to have an situation with an Openscad that doesn't work in "command line" mode but does work in full QT mode.

from openscad.

My intuition tells me that the reason glXCreatePBuffer crashes is that that function in question isn't bound yet, and that you must first query if PBuffers are supported and use glxGetProcAddress() to bind the function before calling it.
The GLEW library should already make it convenient to deal with this though, but you still might need to do the multi-step context creation (first a normal context, then query for pbuffers and then the pbuffer context).

I'm too busy with other things to look into this atm., but if you play around a bit and point me to a git repos/branch with misc. failing attempst, I could investigate further. ...in a week or two that is.

from openscad.

i have it working inside of VMWARE now with MESA and on my "real machine". I copied some ideas from glxgears, it uses XCreateWindow, avoids GLXCreatexxx, and does not Map the window, making it invisible. The FBO setup then proceeds as normal.

https://github.com/donbright/openscad/blob/visitortests/tests/OffscreenContext.cc

from openscad.

here is an experimental proof of concept of rendering without any X server, at all, using OSMESA.

https://github.com/donbright/openscad/tree/headless

i tested the 'cgalpngtest' on a few examples, after killing X and bringing up a console window. It worked without any X server at all. There are a lot of problems to work out.

Using the OSMesa method, it might be impossible to have a single binary that can both be an ordinary interactive windowed program, and also have a 'command line option' to render to a file. The problem seems to be that once you link a binary to OSMESA, all your GL calls go to OSMESA, not to the graphics card OpenGL driver. This is according to bjacques page at gnashdev : http://www.gnashdev.org/?q=node/46

So, what is the solution? Do you have two binaries, one called openscad, the other called openscad-headless, and put them in the same distribution? What about windows, where openscad is statically linked? Doesnt that double the size of your distribution?

What if you had three binaries? Openscad-headless, openscad-window, and openscad, with the latter being just a frontend to the other two? Again, what about Windows?

Am I wrong about a binary being unable to switch back and forth from OSMESA rendering to hardware rendering?

Also, what do the command line options look like?

openscad --headless --cgal sphere.scad --output sphere.png ??????

Anyways. Its possible. Im not going to pursue it further until i can finish the Regression Tests thing. (porting to Windows, which i have done, but i dont have a Windows machine that has FRAMEBUFFER extensions on its OpenGL card to test it on)

from openscad.

@donbright nice :-) actually... my initial thought was the classical unix-way (have backend headless binary and frontend windowed binary that will use it to do all the work), but i guess right now it's bit problematic (in means of performance) to make realtime rendering (and eg.: rotating) this way (if backend can't do direct rendering to screen).

from openscad.

Theoretically i guess you could dynamically graphics drivers, for headless mode it does dlload() for OSMESA, and for GUI mode, it does dlload() for GLX, ordinary Mesa + OpenGL drivers. Now, you still have to link-in QT to do this (and i dont think you can dynamically load QT?), which means it will also link in some X11 drivers. Does linking QT also link in OpenGL drivers? i dont know.

from openscad.

How about to have multiple dynamically linkable (OpenGL API compatible) libraries that we'll be able to select using comandline argument (and possibly using GUI too), where some of features will be dependent on library that you will choose?

from openscad.

Sorry if i was misleading, i forgot to mention that dynamic loading all of that stuff is highly non-trivial. SDL loads X11 dynamically, and some games load GL dynamically, but i dont know if anything does all that and also interacts with QT + QT-GL at the same time - im guessing its practically impossible. It would be vastly, vastly easier to just have two different worker-binaries, and a third wrapper-binary that just forks off the appropriate worker-binary and runs it. But i dont know if thats appropriate for this project.

More questions: do users want OpenCSG rendering from commandline, or just CGAL rendering? Does OpenCSG even work in OSMESA? Would it be OK to have two separate distributions, one headless and one GUI, or is it better to have one fat download with both versions included? What do you do about the inevitable incompatabilities between OSMESA and people's hardware? i.e. they look at something in their QT-openscad gui, then they render it from a headless commandline in OSMESA, and it winds up looking different.. how do you handle that issue?

Would it be easier to just tell people they have to have a windowing system up-and-running to use openscad, even in the 'dump to file' mode on a server, and forget about OSMESA alltogether? What about Xvfb, does it even work with OpenGL and OpenCSG? What do users want, what would they prefer?

from openscad.

On Oct 13, 2011, at 03:39 AM, donbright wrote:

More questions: do users want OpenCSG rendering from commandline, or just CGAL rendering?

For the test framework, I'd like to see both.
For the OpenSCAD command-line, OpenCSG rendering sometimes looks better (colors, transparency), so it would make sense to add it, depending on why such a feature is there in the first place, e.g. for CloudSCAD-like operation it would be essential.

-Marius

from openscad.

Ok... here is another method. It works using a 'virtual' X server called Xvfb.

export DISPLAY=:2
Xvfb :2 -screen 0 800x600x24 &> xvfb.log &
cgalpngtest sphere.scad out.png

This still requires X libraries to be installed, but you don't have to have a running X server, monitor, etc. It can all be done through a terminal.

I have used it to run 'make test' on a box that I only had shell access to.

from openscad.

although i should mention that parallell running of the tests (ctest -j) causes Xvfb to segfault. perhaps each test could spawn it's own Xvfb?...but something tells me osmesa is a 'cleaner' way to go.

from openscad.

if anyone is reading this in future, its nice to know that if you use Xvnc instead of Xvfb, it doesnt crash so much.

from openscad.

And what about making framework for multiple CGAL rendering backends (other than OpenGL) implemented as plugins? Is it possible?

@donbright have you tried it like this?

xvfb-run cgalpngtest sphere.scad out.png

from openscad.

thanks for the tip about xvfb-run , someone should add that to the documentation.

from openscad.

my patch above will enable png's to be rendered from the command line using the CGAL renderer. please see the pull request for more info. thank you

on headless machines, for some reason xvfb-run does not work. you have to run Xvfb then set your DISPLAY env. variable like you would with any other X program running on a headless server.

from openscad.

Do we need some kind of improvements in OpenCSG, CGAL or OpenGL? Maybe we can try to demand support for offscreen rendering somewhere in upstream.

BTW It was never much clear how OpenCSG and CGAL are working together in OpenSCAD. I thought that CGAL is used for modeling (boolean operations, etc...) and OpenCSG for rendering it's output, but now it looks like it's bit more complicated (CGAL can also render and OpenCSG can do boolean stuff too which leaves me confused :-).

from openscad.

CGAL and OpenCSG work independently for two different purposes:
OpenCSG: Render a 2D image on the screen which looks like a CSG model
CGAL: Evaluate the actual geometry of the CSG model

Note that OpenCSG is lacking in some places (e.g. projection), so we fall back to rendering a 3D model using CGAL and then displaying that in such cases.

don: Do you have a gut feeling what's left on this one?

from openscad.

On Tue, Nov 6, 2012 at 6:46 PM, Marius Kintel [email protected]:

CGAL and OpenCSG work independently for two different purposes:
OpenCSG: Render a 2D image on the screen which looks like a CSG model
CGAL: Evaluate the actual geometry of the CSG model

Note that OpenCSG is lacking in some places (e.g. projection), so we fall
back to rendering a 3D model using CGAL and then displaying that in such
cases.

don: Do you have a gut feeling what's left on this one?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/11#issuecomment-10134223.

Sorry for the delay

I had a branch about this... CGAL export to .png was working, you just
did 'openscad blah.scad out.png' ... the problem came with export of
OpenCSG.... there was a lot of refactoring required to merge the stuff in
the testsuite and the plain openscad gui, in order to get the Offscreen
OpenGL stuff to work and get rid of QT code. I dont think it would be good
for the release, since the qt-elimination might have effected file + path
handling....

-DB

from openscad.

@donbright What are the current limitations to the opencsg export to .png in your branch? Is it in a state where I could try it out?

I'd very much like to see if I could use it in cloudscad, like Marius said. Trying to figure out a way to get quick previews has been holding me back for a loooong time now. (I can live with slow stl export) I've gone down many dead ends trying to do openscad csg operations in javascript and at this point I'd be happy with a static image. Rendering cgal to png is still too slow, as it's not much faster than just exporting it to stl and viewing in webgl as I'm doing now. I considered just loading it in X and taking a screenshot, but that's kind of a pain... especially without much control over the viewport.

from openscad.

Tony,

Sorry but my branch it's current state just segfaults while setting up the OpenCSG shaders.

However, if you really want to just play around, you don't need my branch - you can build the test suite from HEAD (see doc/testing.txt), and it will generate a binary called 'opencsgtest' in the 'tests' directory. This can be used to generate pngs as follows: "opencsgtest blah.scad o.png" (with, of course, Xvfb/Xvnc running properly and the appropriate DISPLAY env set on headless servers). There's no way to modify viewpoint / colors / etc currently, but it should be enough to 'play around' with experimentally.

from openscad.

This feature would be so nice for me. I've written and published (shared) build scripts that use XML to parametrize SCAD builds. This lets me build multiple parts from one (or small sets) of SCAD files with one command (or one click). My build script can package and deploy the 3D designs also. The packages are deployed for human consumption, so previews are needed. Currently I have to go into SCAD and generate PNGs manually, and sometimes edits are made to SCAD code for the right parametrization.

I'd like to generate the PNG previews from the command line so my build script can generate a complete deployment package with PNG previews.

Also I understand there's a binary in the test pkg. that might handle this, and I might need to compile HEAD. Either way I can't really share the updated build system with everybody, unless they do the same.

from openscad.

The easiest way atm. is to use cgalpngtest or opencsgtest from the tests folder. Both of these output png.

from openscad.

Is this somehow documented? How to compile those tests, how to use
them to output pngs? Thanks

from openscad.

Some is documented in https://github.com/openscad/openscad/blob/master/doc/testing.txt
To run: <file.scad> <out.png>

It's meant for the test framework, but may be hacked for any other purpose :)

from openscad.

First as an outsider I think it's awesome you have image-based functional tests and can imagine they're likely to introduce their own headaches! It sounds like this is feasible but honestly I'm not familiar with the code so don't have a vision for implementation. It seems like what I want is a command-line hook to execute the PNG export process with a certain distance and camera angle. Currently another workaround for this use-case is to deploy to a website with a STL renderer - though no free (or paid?) ones are 100% cross-compat. I'll get the source compiling locally as I've wanted that for some time anyway.

from openscad.

please let me know if you have any problems compiling the source, and what platform you are using...

from openscad.

Guys, the feature was added: Great!
But above it is suggested that it should work with an "xvfb" connection, but here it doesn't work in that case.
We tried xvfb and the VNC x server, but in both cases it reports: glXChooseFBConfig failed

From the conversation above I gather that when this was implemented this used to work, but now it no longer works due to some "improvement" later on.... :-(
Any idea what this could have been?

from openscad.

This is still working - we use this to test on external headless VMs.
See here, perhaps you get some ideas: https://github.com/openscad/openscad/blob/master/tests/virtualfb.sh

from openscad.

Additional forum thread about that... http://forum.openscad.org/Headless-OpenSCAD-td5187.html

from openscad.

@rewolff

can you run any other openGL programs on your headless machine?
for example, glxinfo ?

does your xvfb and/or VNC actually have OpenGL built in? some systems package Xvfb without GLX support.

from openscad.

OK, got it working.... For those experiencing this problem and stumbling on this here:

• By default xvfb starts up with only 8 bit visuals. Run with Xvfb :1 -screen 0 1600x1200x24+32
  (note that the example in the manual doesn't work!)
• By default xvfb starts up without the "RENDER" extension. Add +render to the xvfb command line.
• By default openscad will use the first libGL it finds, which will be for the hardware you have installed. For the openscad invocation libGL.so.1 needs to point to the mesa implementation.

@donbright The machine isn't really headless. We were testing on a workstation that actually has pretty good GL acceleration hardware..... We also got it to work by starting an X server without authentication in the background and having the openscad connect to that (from the web script). However the X server had to be the active console, or it too would not have GL available....

from openscad.

"By default openscad will use the first libGL it finds, which will be for the hardware you have installed. For the openscad invocation libGL.so.1 needs to point to the mesa implementation. "

I am confused. Does this relate to LIBGL_ALWAYS_SOFTWARE=1 ??

from openscad.

" (note that the example in the manual doesn't work!)"

which manual? doc/testing.txt uses 24bit startup and the wiki at http://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Building_on_Linux/UNIX also uses 24 bit startup.... although not exactly as your command line is listed..

from openscad.

What manpage? The xvfb one.
$ man xvfb
....
EXAMPLES
Xvfb :1 -screen 0 1600x1200x32
...
$ Xvfb :1 -screen 0 1600x1200x32
(EE) Couldn't add screen 0(EE)

I do not know about the "LIBGL_ALWAYS_SOFTWARE=1" option.
What I did was I built openscad with the help of the "build dependencies" script. Then the openscad binary will search "~/openscad_deps/lib" directory for all libraries, including the libGL one, even though the library is not expected to be there. Anyway, putting a link there to the libGL from mesa allowed me to do headless "screenshots" from the PHP script. At the expense of having non-accelerated graphics in the interactive version.... for now.

If/when this situation persists, the link will go away, and I'll start openscad with a LD_LIBRARY_PATH or LD_PRELOAD option to get the right libraries when started from the web script.
(On the other hand, we were developing on a workstation with graphics acceleration. On the webserver that will run this in the end we don't have any need for hardware acceleration, so simply making sure that libGL points to the mesa library will suffice. )

from openscad.

Testing that on my Debian7 VM, I found I still need the "GALLIUM_DRIVER=softpipe" as at least the llvm driver version used there produces horrible render errors in some cases (e.g. example006.scad).

from openscad.

@rewolff im confused.... is this machine you are on using some kind of proprietary GL driver?

as far as i know, all OpenGL on linux, hardware accellerated or not, goes through Mesa, unless there is some proprietary driver involved.

not sure why you have to create a symlink to libGL.so .... i would consider that a bug in the build scripts that we should be able to fix somehow..... but i dont really understand what is going on. ..

from openscad.

The machine has an NVIDIA card. I'm not sure what driver it uses. Could be the proprietary one.
% ..../openscad.git/openscad -o /tmp/test.png doos.scad
...
Compiling design (CSG Products normalization)...
Normalized CSG tree has 118 elements
% rm ..../openscad_deps/lib/libGL.so.1 # remove the link to /usr/lib/i386-linux-gnu/mesa/libGL.so.1
% ..../openscad.git/openscad -o /tmp/test2.png doos.scad
...
PolySetCache hit: cube(size=[18,4.02,5],center=false);
Compiling design (CSG Products normalization)...
Normalized CSG tree has 118 elements
Xlib: extension "NV-GLX" missing on display ":1.0".
OpenGL error 0x502: invalid operation after glBindFramebufferEXT
Can't create OpenGL OffscreenView. Code: -1.
buttonius:~>

from openscad.

thanks for those details....

I googled a bit and found some folks with similar issues...

1. someone trying to run UCSF Chimera and getting those problems with a proprietary driver install mix-up ( apparently? ) on Fedora Linux

http://forums.fedoraforum.org/showthread.php?t=284088

1. Here is someone trying to run Comsol remotely, with the Nvidia proprietary driver... this time on Ubuntu... (they have some steps to solve the problem)

ubuntuforums.org/archive/index.php/t-1822396.html

Needs some more research to be sure i guess.

from openscad.

Excuse me, but why was this closed? I can't see any resolution.
Is it possible it was closed accidentaly by github? It seems to me it automaticaly links this to unrelated issues, just because they contain #11 string...

from openscad.

This was closed 4 years ago, I guess the bitmap export was implemented at that time.

The feature itself is extensively used in the test framework for years now and documented in the manual, so what's wrong with closing it? If there's some additional feature request, I'd suggest to create a new issue.

from openscad.

t seems to me it automaticaly links this to unrelated issues, just because they contain #11 string...

They are deliberate references to this issue. Each pull request and issue is automatically given a number by GitHub and you can reference them in comments with # as shorthand for the full URL.

from openscad.

@t-paul but it still can't be run without X server...

from openscad.

What gives you that impression? It works fine for me without an X server.

from openscad.

Well, that's what's commonly called complete requirements, I guess :-). @nophead is normally running on Windows I think and there is indeed no X-Server needed. So the topic is platform specific and also as discussed above not simple to solve for the Linux platform (not sure about macOS and if anyone cares for that).

Still the image export feature does exist, works on all platforms and is used by a number of people on Linux servers.

I think it would be nice to remove the need for Xvfb or Xvnc for headless operation but that should go into another ticket and may take a while as it probably needs quite some changes in the display code.

from openscad.

This might solve the issue in the future:

https://www.phoronix.com/scan.php?page=news_item&px=Virtual-KMS-VKMS-Linux-4.19

from openscad.

OpenSCAD uses OpenGL to render images. To get OpenGL to render you need a "GL Context"

Inside the GUI it uses QT toolkit's OpenGL widget to get a GL context.
On the command line, Mac OSX, it uses Cocoa library to make a GL context. Marius created this.
We ported Marius' work to linux(bsd), it uses GLX under X11 to create a GL context.
We also ported it to Windows, which uses WGL to create a GL context.

You do not need a physical GPU to make a GL Context. On linux/bsd the GLX calls are made using a library called libopengl.so, and you set the environment variable LIBGL_ALWAYS_SOFTWARE=1 you can force it into 'software rendering', where it basically does what a GPU does, but on a normal CPU instead.

If you do have a GPU, then opengl.so will talk to the driver for your GPU. Now, drivers on linux are kind of a nightmare because, unlike most hardware in linux, there are two kinds of drivers in linux for GPU/vidcards. There's open source driver, then there's proprietary driver. You can get open source driver for AMD, but also Proprietary if you want. Intel has open source drivers - alot of them are crap because they crash (google i950 or i915 crash sometime). But they are open source. They all go into the Mesa project. But Nvidia. Nvidia. People think Linux Torvalds is a mean person for flipping off Nvidia in public and using curse words. Well, I agree.... its a bit uncalled for. however.

Nvidia doesnt ship open source drivers for linux. They ship binary blobs in packages that try to overlay the linux distro with their own files. As you can imagine, things get bungled up alot, with file naming conventions, automatic updates of the OS, etc etc etc etc. On top of this, Nvidia's proprietary drivers are not actually drivers. Nvidias drivers are actually massive patch/shim jobs for buggy games coming out of sweatshops where they intimidate people to work 100 hours a week in permanent "death march" programming sessions. Nvidia ships what are essentially game updates out, but they call them drivers. It is just depressing. But the other point of this paragraph is that.... if it doesnt work on Nvidia drivers, its going to most of the time be a packaging issue, an installation issue, etc. Its not something isolated to one program like OpenSCAD.

But anyways. All of that, software or hardware rendering, open source or proprietary driver, MESA or not, on linux/bsd, that is still using GLX to get an OpenGL Context, which still needs X11. Now, there is a theoretical possibility to get a GL Context without X, that of something called Offscreen Mesa, which is a version of the Mesa GL library, that can render GL calls without X. Unfortunately, Offscreen Mesa has always been a little bit obscure, a bit unintegrated properly into distributions, for example. By default Mesa does not build the Offscreen Mesa version of itself. You have to rebuild the entire Mesa package to make it work. But it gets a bit confused about the naming of the libraries and such. Its not easy. Here is the other thing about OpenGL. OpenGL programs really really depend on a library called GLEW. GLEW has issues with Offscreen Mesa as well. I have experimented with specially modifying and re-buidling GLEW and Offscreen Mesa to be able to render in OpenSCAD in command line without X. I had it working actually. There was someone who very nicely gave me a login account on an old Sun Sparc machine where i played with this. The problem is that making an experimental working build of openscad, based on highly modified GLEW and Offscreen Mesa, that renders without X is a whole different ballgame than working with several different projects to upstream some weird bizarre set of patches for something that almost nobody cares about. I'm not going to be able to persuade GLEW to re-do it's entire build system, nor Mesa to re-do theirs. for a tiny use case like this.

There are other ways to get a GL context without GLX on linux/bsd... but ... they require you to use 'newer' style OpenGL. OpenSCAD's OpenGL is actually largely from CGAL and OpenCSG, and they are both really old. Really old.

Lastly, OpenGL itself is dying, as Apple has stopped updating/supporting (which means they will likely remove eventually), and the industry is moving to Vulkan. You cannot 'port from OpenGL to Vulkan', you have to write thousands of lines of code to replace OpenGL functions, and then port on top of that, because Vulkan doesnt provide high level operations like OpenGL did. That's probably the only way to survive long term. (Or hope someone writes an 'Old Opengl on top of Vulkan' library).

@Harvie VirtualKMS might be helpful, but it is very vague in that phoronix link about what its relationship to OpenGL, or even Vulkan, will be. If it can provide a GL Context without X, then it would be nice. I'm doubting it tho.

from openscad.

you set the environment variable LIBGL_ALWAYS_SOFTWARE=1 you can force it into 'software rendering', where it basically does what a GPU does, but on a normal CPU instead.

@donbright does that work on Windows? I'm doing RDP remote desktop and OpenGL is intermittently working.

from openscad.

@donbright can't find the article, but i've read that VKMS is exactly for this. To provide virtual display on headless servers including GPU acceleration. It's made to enable multiple containers/VMs to use GPU.

from openscad.

@MichaelAtOz someone, somewhere, a long time ago, posted how to copy Mesa's version of opengl32.dll into the same directory as OpenSCAD, and IIRC, it did allow the enabling of software rendering on Windows (which would be detectably by looking into openscad help/lib info). It was kind of one of those things, since hardly anybody uses it, its not very polished. I have experimented it on a few windows boxes but i think it was hit and miss. (Mesa can use some weird assembly language optimization that is invalid on some CPUs.)

from openscad.

@Harvie

as root

apt-get install xserver-xorg-video-dummy mesa-utils

# /etc/X11/xorg.conf # dummy configuration link
wget -O "/etc/X11/xorg.conf" https://gist.githubusercontent.com/unique1984/1d29e8caaf649546ff0bc07769b834af/raw/f8b34b33f6b378368812bc3d65e1ed5cccd2129c/X11%2520Dummy%2520configuration.txt

export DISPLAY=:0

Xorg &

openscad test.scad -o test.png

Debian 8, Debian 9, Debian 10 Tested.

from openscad.

@unique1984 But will this work on VM without proper opengl HW?

from openscad.

@Harvie

@unique1984 But will this work on VM without proper opengl HW?

As far as i tried, virtualbox headless and digitalocean headless machines gave me something.
Ofcourse these machines have a proper VGA, but just VGA, and standard drivers on Linux kernel, nothing more. It's doing its job :)

VirtualBox Debian 10 & With my OpenScadPhpConnector
glxgears -> 5seconds ~1000fps

VirtualBox Debian 10 Console

DigitalOcean Console (ssh without -X)
glxgears -> 5seconds ~500fps

Last one is OpenScad's GUI on my Notebook
I am not a CAD expert so, sorry for my inexperience

from openscad.