Dear experts,
I need to generate hundreds (if not thousands) of views from a single OpenSCAD model using just the command line tool (because it will run on a linux web server), and as fast as possible. So far, I´ve only found an old thread about this topic titled " rendering scad images via an api <http://forum.openscad.org/rendering-scad-images-via-an-api-td4277.html> ", but the issue was not fully solved. I already can do it using the -D option to pre-define some variable(s), for example with the following bash script: for((i=0;i<=100;i++)) do openscad -o myimage_$i.png --imgsize=640x480 --autocenter --projection o --camera 0,0,0,90,0,0,10 -D someangle=$i -q mymodel.scad done This approach is terribly slow (minutes) because OpenSCAD parses the input scad file and renders the scene for every single view. Any better alternatives? I know that OpenSCAD GUI is able to dump all animation images, but this option seems not available from command line. Perhaps, adding an "--animation" option would be a good improvement in future releases, don´t you think? Ideally, OpenSCAD would read once the input model and then generate and dump the PNG image for every pre-defined variable set. Such variable sets would be provided via some simple text file with, e.g. one variable set per line. Note that, at least for my application, the model is the same for all generated views, only the orientation changes. Thanks a lot in advance! -- Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
On 09.01.21 12:54, Vigardo wrote:
> I know that OpenSCAD GUI is able to dump all animation images, > but this option seems not available from command line. Perhaps, > adding an "--animation" option would be a good improvement in > future releases, don´t you think? Yep, that already exists in the release candidates. In addition there's a persistent cache feature which is still work in progress. As the name implies, this will persist caches across multiple separate calls of OpenSCAD via either local files or redis server. ciao, Torsten. _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
|
Sorry for my ignorance or if I did not understood you well:
1) Then, is the OpenSCAD release candidate 2021.01-RC5 (6 January 2021) <https://www.openscad.org/news.html> , available as a Development Snapshots in the downloads page <https://www.openscad.org/downloads.html> able to dump all animation PNGs from the command line? 2) Will the persistent cache feature persist across multiple separate calls to OpenSCAD command-lined or just the GUI version? 3) When do you think such persistent cache will be available? Thanks a lot for the help and quick response! -- Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
On 09.01.21 18:10, Vigardo wrote:
> 1) Then, is the OpenSCAD release candidate 2021.01-RC5 > (6 January 2021) <https://www.openscad.org/news.html>, > available as a Development Snapshots in the downloads > page <https://www.openscad.org/downloads.html> able to > dump all animation PNGs from the command line? At this point dev snapshots and the release candidate are almost identical but that will start to diverge again pretty soon. Both support the new --animate command line option. Downloads are separate: RC: https://www.openscad.org/downloads.html#rc DEV: https://www.openscad.org/downloads.html#snapshots > 2) Will the persistent cache feature persist across > multiple separate calls to OpenSCAD command-lined or > just the GUI version? It's supposed to work with both (but commandline will need explicit setup options, not using the config that is available in GUI). > 3) When do you think such persistent cache will be > available? No idea. I'd love to see that as soon as possible, but there's no way to plan free time of people. ciao, Torsten. _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
|
In reply to this post by Vigardo
I have a similar problem, though with SVG export. Just having to restart
everything for every export takes ages. Animation doesn't work for anything but PNG. It would be great if there was a built-in export (filename) module. Example: export("mypart.svg") mypart(); -- Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
On 09.01.21 20:11, Troberg wrote:
> I have a similar problem, though with SVG export. Just > having to restart everything for every export takes ages. > Animation doesn't work for anything but PNG. It does work in command line mode. --- square.scad --- rotate(90 * $t) square(10); ------------------- openscad-nightly --animate 10 -o square.svg square.scad produces 10 SVG files with a rotating square, although it might be useful to also add a camera option too for a fixed view. > export("mypart.svg") > mypart(); No. There's likely some feature to export multiple files, but it's not going to be an imperative call writing a file. ciao, Torsten. _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
|
On 1/9/2021 11:39 AM, Torsten Paul
wrote:
No. There's likely some feature to export multiple files, but it's not going to be an imperative call writing a file. Indeed. Danger, Will Robinson! As soon as the language has a way to write named files, you have to worry about what interesting files a malicious program might write. (That's one of the disturbing aspects of a Python-based replacement, that it's hard to avoid giving the program you just downloaded way too much access to your system.) _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
In reply to this post by tp3
> > I have a similar problem, though with SVG export. Just
> > having to restart everything for every export takes ages. > > Animation doesn't work for anything but PNG. > > It does work in command line mode. Wow, didn't know that! Now I'll have to rethink my 11 hour export batch! > produces 10 SVG files with a rotating square, although it > might be useful to also add a camera option too for a > fixed view. Not really, as the SVG files will be top down of the entire object, no matter what, which is what I like. > > export("mypart.svg") > > mypart(); > > No. There's likely some feature to export multiple files, > but it's not going to be an imperative call writing a file. So, just don't allow any directory except the same as the SCAD file. Can't do much damage then, unless the user does something really, really stupid, such as running it from the Windows directory. Or just have a setting to turn off all file writing in the settings, which is set to disable as default. For me, it would be immensely useful to be able to write to files, both as export and as an ability to echo() to a file. It makes it much easier to build an integrated tool chain where you can connect everything with little or no manual interaction. -- Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
On 10.01.21 08:06, Troberg wrote:
>> produces 10 SVG files with a rotating square, although it >> might be useful to also add a camera option too for a >> fixed view. > Not really, as the SVG files will be top down of the entire > object, no matter what, which is what I like. Right, I was thinking of PNG where the camera does define the field of view. I think you are correct that it would not have an effect on the viewport of the SVG. Some other workaround like tiny boxes in the viewport corners might work. ciao, Torsten. _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
|
In reply to this post by Vigardo
You can get pretty good speed boost, at least with Linux. You can add a space and ampersand at the end of the commands your script is making. That will launch that command in a separate thread, so you'll have multiple instances of openscad running simultaneously. Depending on how many cores your computer has, you should get a pretty good reduction in processing time. You have to add a 'wait' command at the end for the script to wait for all the threads to finish. On January 9, 2021 6:55:32 AM Vigardo <[hidden email]> wrote:
_______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
goblinbot wrote
> You can get pretty good speed boost, at least with Linux. You can add a > space and ampersand at the end of the commands your script is making. > That > will launch that command in a separate thread, so you'll have multiple > instances of openscad running simultaneously. Depending on how many cores > your computer has, you should get a pretty good reduction in processing > time. You have to add a 'wait' command at the end for the script to wait > for all the threads to finish. Well, I run them in Windows (my most powerful machine, hardware wise, is a Windows machine, as I also use it for gaming), from my own program. I could simply launch several instances from that program, but the downside is that it bogs down the computer too much, as Windows is really crappy at starting/stopping programs in an intelligent and efficient way, so your OS gets mutex-strangled. -- Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
Thank you all for the interesting comments!
*goblinbot*: I already was aware of the "& + wait" parallelization, nice contribution anyways! *tp3*: I´ve tried some dummy example to generate several views of a rotating model using either successive command line calls to OpenSCAD or a single call with the --animate option. The latter resulted about 2-fold faster (23 s vs 40 s). To test this I used the following command #> time /home/mon/OpenSCAD-2021.01-RC6-x86_64.AppImage --animate 37 --colorscheme Tomorrow --camera 0,0,0,90,0,0,5 anim.scad and the following OpenSCAD script: // Explicit rotation echo("a=",$t*180); rotate(a=$t*180,v=[0,0,1]) mymodel(); module mymodel() { difference() { cube([1,1,1],center=true); sphere(d=1.25,$fn=24); } } Now I wonder if there would be a faster approach, for example, to rotate the camera (using --camera option) or the viewport (using $vpr) instead of the direct model rotation. // Viewport rotation $vpr=[90,0,-$t*180]; echo("vpr=",$vpr,"vpt=",$vpt,"vpd=",$vpd); mymodel(); However, using the following command (with or without the --camera option) produces a very small object. #> time /home/mon/OpenSCAD-2021.01-RC6-x86_64.AppImage --animate 37 --colorscheme Tomorrow --camera 0,0,0,90,0,0,5 anim.scad ECHO: "vpr=", [90, 0, -34.0541], "vpt=", [0, 0, 0], "vpd=", 500 I only partially fix this behavior by explicitly setting the $vpd variable to a manually adjusted value, e.g. 5. #> time /home/mon/OpenSCAD-2021.01-RC6-x86_64.AppImage --animate 37 --colorscheme Tomorrow -D '$vpd=5' anim.scad Unfortunately, there was not any significant speedup using $vpr rotation. In any case, this behavior (having to manually set the $vpd value) differs from GUI and is quite annoying since in GUI there is no need to specify the $vpd variable at all. 1) I think that the command line tool should behave exactly the same as the GUI version, at least for this case, don´t you agree? 2) Any faster approach to generate different views from a model in OpenSCAD? Intuitively it seems that computing a thousand views should take just a couple of seconds (the 3D navigation is very responsive) but it takes around 10 times more, why is this so? Best, -- Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
Animation recomputes everything as any aspect of the geometry could depend on $t, not just the camera position. You do set $vpd in the GUI with the zoom setting and it is displayed as "distance" in the status bar. On Tue, 19 Jan 2021 at 20:12, Vigardo <[hidden email]> wrote: Thank you all for the interesting comments! _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
Thanks *nophead* for the quick response!
What you say makes sense: "Animation recomputes everything as any aspect of the geometry could depend on $t, not just the camera position." But, what if the model does not change at all and what just changes is camera view? Recomputing everything in this case seems a waste of CPU time, don´t you agree? Is there a way to speed up the generation of different view snapshots of exactly the same object? (Sorry if I say something stupid since I don´t know how OpenSCAD internally works :-) -- Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
Yes in theory it could be optimised but since $vpr, etc are just variables anything could depend on them, so it would need a compex dependency analysis to work out that none of the model had changed. Sprinkling render() in the model might help because then the geometry gets computed once and cashed, so each animation frame would only calculate all the variables and expressions and get cache hits for all the geometry. On Thu, 21 Jan 2021 at 17:59, Vigardo <[hidden email]> wrote: Thanks *nophead* for the quick response! _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
nophead wrote
> Yes in theory it could be optimised but since $vpr, etc are just variables > anything could depend on them, so it would need a compex dependency > analysis to work out that none of the model had changed. I wonder how many folks would use simple camera movements, without any need for re-rendering. If there's a significant number who wish for it, perhaps OpenSCAD could include some sort of switch that would turn that on as a specific mode. I know I have wanted to send someone a single animated file rather than a series of PNGs in order to show different aspects of a model. I never bothered, because doing so took too long. It wouldn't even be necessary to detect things that would require re-rendering, if a warning about bad results could occur. -- Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
The problem is the camera parameters are set with variables, which can depend on any other variables or expressions. So you have to at least run the first pass of OpenSCAD that evaluates all the expressions. That is usually quick but can get very slow. In my case it takes minutes. When it is animating, which stage takes all the time? I.e. Parsing design (AST generation)... Compiling design (CSG Tree generation)... Compiling design (CSG Products generation)... Compiling design (CSG Products normalization)... On Thu, 21 Jan 2021 at 19:16, lar3ry <[hidden email]> wrote: nophead wrote _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
Thanks all for the interesting contributions and fast responses, you´re very
nice! The render() parameter does speed up the process more than 10 fold (i.e. from about 20 to less than 2 seconds!) using either the "Explicit rotation" or the "Viewport rotation" methods. However, this only works from GUI. When I run it from command-line "Explicit rotation" works but takes 20 s and the "Viewport rotation" takes the same time but the view is not updated (i.e. 36 equal "frozen" snapshots are produced...). Is this the expected OpenSCAD behavior? I think that *tp3* already advised about this on a previous post: Me: "2) Will the persistent cache feature persist across multiple separate calls to OpenSCAD command-lined or just the GUI version?" tp3: "It's supposed to work with both (but command line will need explicit setup options, not using the config that is available in GUI)." What are these "explicit setup options"? For completeness, these were the two methods used in my tests: // Explicit rotation echo("a=",$t*180); rotate(a=$t*180,v=[0,0,1]) render() mymodel(); // Viewport rotation $vpr=[90,0,-$t*180]; $vpd=5; echo("vpr=",$vpr,"vpt=",$vpt,"vpd=",$vpd); render() mymodel(); And this was the command: #> time OpenSCAD-2021.01-RC6-x86_64.AppImage --animate 36 --camera 0,0,0,90,0,0,5 ViewRender.scad Note that the --camera option is required to prevent the annoying automatic zoom in & out issue. I want that the object appears like if it were placed in a virtual rotation table, the camera has to be at the same distance all the time. By the way, is there some way to tell OpenSCAD to use the initial camera parameters (i.e. those at $t=0) for the whole animation? -- Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
On 1/22/2021 9:43 AM, Vigardo wrote:
// Explicit rotation echo("a=",$t*180); rotate(a=$t*180,v=[0,0,1]) render() mymodel(); // Viewport rotation $vpr=[90,0,-$t*180]; $vpd=5; echo("vpr=",$vpr,"vpt=",$vpt,"vpd=",$vpd); render() mymodel(); You probably want to stick with the latter. It's doing what you want to do: moving the camera. And this was the command: #> time OpenSCAD-2021.01-RC6-x86_64.AppImage --animate 36 --camera 0,0,0,90,0,0,5 ViewRender.scad Note that the --camera option is required to prevent the annoying automatic zoom in & out issue. I want that the object appears like if it were placed in a virtual rotation table, the camera has to be at the same distance all the time. I'm not sure exactly what problem you're seeing, but note that --camera is the same as setting $vpt, $vpr, and $vpd. By the way, is there some way to tell OpenSCAD to use the initial camera parameters (i.e. those at $t=0) for the whole animation? Don't have $vpt/$vpr/$vpd depend on $t. Or is there something more complicated that I'm missing? But of course if your animation consists of flying your camera around, it will get really boring if you don't have the camera move when $t changes. _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
In reply to this post by Vigardo
On Jan 22, 2021, 09:44 -0800, Vigardo <[hidden email]>, wrote:
#> time OpenSCAD-2021.01-RC6-x86_64.AppImage --animate 36 --camera 0,0,0,90,0,0,5 ViewRender.scad Putting --camera in your command line will override $vpr, $vpt and $vpd. _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
Free forum by Nabble | Edit this page |