Hi, 
Guest
Pic
Sign In

discuss@lists.openscad.org

OpenSCAD general discussion Mailing-list

View all threads

Efficient generation of many PNG images from command line?

V
Vigardo
Sat, Jan 9, 2021 11:54 AM

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/

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/
TP
Torsten Paul
Sat, Jan 9, 2021 3:29 PM

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.

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.
V
Vigardo
Sat, Jan 9, 2021 5:10 PM

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/

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/
TP
Torsten Paul
Sat, Jan 9, 2021 6:44 PM

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

  1. 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).

  1. 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.

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.
T
Troberg
Sat, Jan 9, 2021 7:11 PM

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/

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/
TP
Torsten Paul
Sat, Jan 9, 2021 7:39 PM

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.

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.
JB
Jordan Brown
Sat, Jan 9, 2021 8:09 PM

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.)

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.)
T
Troberg
Sun, Jan 10, 2021 7:06 AM

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/

> > 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/
TP
Torsten Paul
Sun, Jan 10, 2021 4:11 PM

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.

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.
MB
Michael Bronnenberg
Mon, Jan 11, 2021 6:27 AM

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 bioramon@gmail.com wrote:

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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

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 <bioramon@gmail.com> wrote: > 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 > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
T
Troberg
Mon, Jan 11, 2021 8:20 AM

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/

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/
V
Vigardo
Tue, Jan 19, 2021 8:11 PM

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=",$t180);
rotate(a=$t180,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/

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/
NH
nop head
Tue, Jan 19, 2021 11:08 PM

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 bioramon@gmail.com wrote:

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=",$t180);
rotate(a=$t180,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
Discuss@lists.openscad.org
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 <bioramon@gmail.com> wrote: > 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 > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >
V
Vigardo
Thu, Jan 21, 2021 5:58 PM

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/

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/
NH
nop head
Thu, Jan 21, 2021 6:30 PM

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 bioramon@gmail.com wrote:

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
Discuss@lists.openscad.org
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 <bioramon@gmail.com> wrote: > 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 > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >
L
lar3ry
Thu, Jan 21, 2021 7:15 PM

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/

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/
NH
nop head
Thu, Jan 21, 2021 7:42 PM

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 lar3ry@sasktel.net wrote:

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
Discuss@lists.openscad.org
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 <lar3ry@sasktel.net> wrote: > 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 > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >
V
Vigardo
Fri, Jan 22, 2021 5:43 PM

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=",$t180);
rotate(a=$t180,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/

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/
JB
Jordan Brown
Sat, Jan 23, 2021 4:32 AM

On 1/22/2021 9:43 AM, Vigardo wrote:

// Explicit rotation
echo("a=",$t180);
rotate(a=$t180,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.

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.
W
Whosawhatsis
Sat, Jan 23, 2021 4:42 AM

On Jan 22, 2021, 09:44 -0800, Vigardo bioramon@gmail.com, 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.

On Jan 22, 2021, 09:44 -0800, Vigardo <bioramon@gmail.com>, 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.
MM
Michael Marx
Sat, Jan 23, 2021 5:06 AM

-----Original Message-----
From: Discuss [mailto:discuss-bounces@lists.openscad.org] On Behalf Of Vigardo
Sent: Sat, 23 Jan 2021 04:43

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"?

The persistent cache feature is a work-in-progress. Not in nightly builds yet.

--
This email has been checked for viruses by AVG.
https://www.avg.com

> -----Original Message----- > From: Discuss [mailto:discuss-bounces@lists.openscad.org] On Behalf Of Vigardo > Sent: Sat, 23 Jan 2021 04:43 > > 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"? > The persistent cache feature is a work-in-progress. Not in nightly builds yet. -- This email has been checked for viruses by AVG. https://www.avg.com
V
Vigardo
Sat, Jan 23, 2021 12:13 PM

MichaelAtOz' wrote

The persistent cache feature is a work-in-progress. Not in nightly builds
yet.

Ok, I´ll wait. But, the cache behavior is going to be the exactly the same
in command-line and GUI, am I right? Thanks!

Whosawhatsis wrote

Putting --camera in your command line will override $vpr, $vpt and $vpd.

This totally explains why the "Viewport rotation" method did not update the
view :-) Thanks!

JordanBrown wrote

You probably want to stick with the latter.  It's doing what you want to
do:  moving the camera.

Ok, I´ll do!

JordanBrown wrote

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.

Sure, but this is how a turn table is expected to behave :-)

JordanBrown wrote

I'm not sure exactly what problem you're seeing, but note that --camera is
the same as setting $vpt, $vpr, and $vpd.
Don't have $vpt/$vpr/$vpd depend on $t.  Or is there something more
complicated that I'm missing?

Yes, I´ll try to explain it better here, sorry :-)

When I generate the snapshots from GUI there is no problem, the turntable
works as expected (both ways, rotating either the object itself or the
camera).

// Viewport rotation
$vpr=[90,0,-$t*180];
echo("vpr=",$vpr,"vpt=",$vpt,"vpd=",$vpd);
render() mymodel();

The problem arises when I run the same script from the command-line:

#> OpenSCAD-2021.01-RC6-x86_64.AppImage --animate 36 ViewRender.scad

Then, to obtain the same expected behavior I have to explicitly set the view
port distance ($vpd) to some manually adjusted distance, e.g. $vpd=5. If I
do not add this value to the code, then the views appear empty since the
$vpd seems to be set to some very high distance (i.e. 500) by default:

ECHO: "vpr=", [90, 0, 0], "vpt=", [0, 0, 0], "vpd=", 500

Conversely, the same $vpd-less script works perfect from GUI. It seems that
if the GUI is not used, then the $vpd is not appropriately set. May this be
a bug? Any workaround?

Note that for my turntable application the camera must be rotating while
maintaining a constant distance to the object. The $vpd must be maintained
from first to last frame of the animation, but at the same time must be set
automatically to fit the whole object. If the view is fitted to the object
for each frame, this will cause an annoying "zoom in & out" effect. This
latter effect happens if using the "Explicit rotation" approach form
command-line but not from GUI.

--
Sent from: http://forum.openscad.org/

MichaelAtOz' wrote > The persistent cache feature is a work-in-progress. Not in nightly builds > yet. Ok, I´ll wait. But, the cache behavior is going to be the exactly the same in command-line and GUI, am I right? Thanks! Whosawhatsis wrote > Putting --camera in your command line will override $vpr, $vpt and $vpd. This totally explains why the "Viewport rotation" method did not update the view :-) Thanks! JordanBrown wrote > You probably want to stick with the latter.  It's doing what you want to > do:  moving the camera. Ok, I´ll do! JordanBrown wrote > 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. Sure, but this is how a turn table is expected to behave :-) JordanBrown wrote > I'm not sure exactly what problem you're seeing, but note that --camera is > the same as setting $vpt, $vpr, and $vpd. > Don't have $vpt/$vpr/$vpd depend on $t.  Or is there something more > complicated that I'm missing? Yes, I´ll try to explain it better here, sorry :-) When I generate the snapshots from GUI there is no problem, the turntable works as expected (both ways, rotating either the object itself or the camera). // Viewport rotation $vpr=[90,0,-$t*180]; echo("vpr=",$vpr,"vpt=",$vpt,"vpd=",$vpd); render() mymodel(); The problem arises when I run the same script from the command-line: #> OpenSCAD-2021.01-RC6-x86_64.AppImage --animate 36 ViewRender.scad Then, to obtain the same expected behavior I have to explicitly set the view port distance ($vpd) to some manually adjusted distance, e.g. $vpd=5. If I do not add this value to the code, then the views appear empty since the $vpd seems to be set to some very high distance (i.e. 500) by default: ECHO: "vpr=", [90, 0, 0], "vpt=", [0, 0, 0], "vpd=", 500 Conversely, the same $vpd-less script works perfect from GUI. It seems that if the GUI is not used, then the $vpd is not appropriately set. May this be a bug? Any workaround? Note that for my turntable application the camera must be rotating while maintaining a constant distance to the object. The $vpd must be maintained from first to last frame of the animation, but at the same time must be set automatically to fit the whole object. If the view is fitted to the object for each frame, this will cause an annoying "zoom in & out" effect. This latter effect happens if using the "Explicit rotation" approach form command-line but not from GUI. -- Sent from: http://forum.openscad.org/
MM
Michael Marx
Sat, Jan 23, 2021 12:33 PM

-----Original Message-----
From: Discuss [mailto:discuss-bounces@lists.openscad.org] On Behalf Of Vigardo
Sent: Sat, 23 Jan 2021 23:13
To: discuss@lists.openscad.org
Subject: Re: [OpenSCAD] Efficient generation of many PNG images from command line?

MichaelAtOz' wrote

The persistent cache feature is a work-in-progress. Not in nightly builds
yet.

Ok, I´ll wait. But, the cache behavior is going to be the exactly the same
in command-line and GUI, am I right? Thanks!

The persistent cache feature is a work-in-progress.

--
This email has been checked for viruses by AVG.
https://www.avg.com

> -----Original Message----- > From: Discuss [mailto:discuss-bounces@lists.openscad.org] On Behalf Of Vigardo > Sent: Sat, 23 Jan 2021 23:13 > To: discuss@lists.openscad.org > Subject: Re: [OpenSCAD] Efficient generation of many PNG images from command line? > > MichaelAtOz' wrote > > The persistent cache feature is a work-in-progress. Not in nightly builds > > yet. > > Ok, I´ll wait. But, the cache behavior is going to be the exactly the same > in command-line and GUI, am I right? Thanks! > The persistent cache feature is a work-in-progress. -- This email has been checked for viruses by AVG. https://www.avg.com
NH
nop head
Sat, Jan 23, 2021 12:44 PM

$vpd seems to be set to some very high distance (i.e. 500) by default:

Yes that is the default for the GUI as well. You have to click on ViewAll
to set it appropriately for your object. On the command line --viewall does
the same.

On Sat, 23 Jan 2021 at 12:34, Michael Marx michael@marx.id.au wrote:

-----Original Message-----
From: Discuss [mailto:discuss-bounces@lists.openscad.org] On Behalf Of

Vigardo

Sent: Sat, 23 Jan 2021 23:13
To: discuss@lists.openscad.org
Subject: Re: [OpenSCAD] Efficient generation of many PNG images from

command line?

MichaelAtOz' wrote

The persistent cache feature is a work-in-progress. Not in nightly

builds

yet.

Ok, I´ll wait. But, the cache behavior is going to be the exactly the

same

in command-line and GUI, am I right? Thanks!

The persistent cache feature is a work-in-progress.

--
This email has been checked for viruses by AVG.
https://www.avg.com

OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

> $vpd seems to be set to some very high distance (i.e. 500) by default: Yes that is the default for the GUI as well. You have to click on ViewAll to set it appropriately for your object. On the command line --viewall does the same. On Sat, 23 Jan 2021 at 12:34, Michael Marx <michael@marx.id.au> wrote: > > > > -----Original Message----- > > From: Discuss [mailto:discuss-bounces@lists.openscad.org] On Behalf Of > Vigardo > > Sent: Sat, 23 Jan 2021 23:13 > > To: discuss@lists.openscad.org > > Subject: Re: [OpenSCAD] Efficient generation of many PNG images from > command line? > > > > MichaelAtOz' wrote > > > The persistent cache feature is a work-in-progress. Not in nightly > builds > > > yet. > > > > Ok, I´ll wait. But, the cache behavior is going to be the exactly the > same > > in command-line and GUI, am I right? Thanks! > > > > > The persistent cache feature is a work-in-progress. > > > -- > This email has been checked for viruses by AVG. > https://www.avg.com > > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >
V
Vigardo
Sat, Jan 23, 2021 3:13 PM

nophead wrote

Yes that is the default for the GUI as well. You have to click on ViewAll
to set it appropriately for your object. On the command line --viewall
does
the same.

That is what I though. I tried --viewall option in some of my past tests but
since it did not work I removed it from the command line options (to avoid
adding noise to the discussion :-)... but I was wrong...this may be the key
point.

The --viewall option does not work from command line, at least not for
OpenSCAD-2021.01-RC5-x86_64 and OpenSCAD-2021.01-RC6-x86_64 versions:

#> OpenSCAD-2021.01-RC6-x86_64.AppImage --viewall --animate 36
ViewRender.scad

As you can check, the $vpd remains 500, with or without --viewall option.

SCRIPT CODE:
$vpr=[90,0,-$t*180];
echo("vpr=",$vpr,"vpt=",$vpt,"vpd=",$vpd);
render() mymodel();

OUTPUT:
ECHO: "vpr=", [90, 0, 0], "vpt=", [0, 0, 0], "vpd=", 500

Would this be a bug related to --viewall behavior in command-line tool or am
I doing something wrong?

--
Sent from: http://forum.openscad.org/

nophead wrote > Yes that is the default for the GUI as well. You have to click on ViewAll > to set it appropriately for your object. On the command line --viewall > does > the same. That is what I though. I tried --viewall option in some of my past tests but since it did not work I removed it from the command line options (to avoid adding noise to the discussion :-)... but I was wrong...this may be the key point. The --viewall option does not work from command line, at least not for OpenSCAD-2021.01-RC5-x86_64 and OpenSCAD-2021.01-RC6-x86_64 versions: #> OpenSCAD-2021.01-RC6-x86_64.AppImage --viewall --animate 36 ViewRender.scad As you can check, the $vpd remains 500, with or without --viewall option. SCRIPT CODE: $vpr=[90,0,-$t*180]; echo("vpr=",$vpr,"vpt=",$vpt,"vpd=",$vpd); render() mymodel(); OUTPUT: ECHO: "vpr=", [90, 0, 0], "vpt=", [0, 0, 0], "vpd=", 500 Would this be a bug related to --viewall behavior in command-line tool or am I doing something wrong? -- Sent from: http://forum.openscad.org/
TP
Torsten Paul
Sat, Jan 23, 2021 3:22 PM

As you can check, the $vpd remains 500, with or
without --viewall option.

And generates this warning with --viewall which explains
what's happening:

WARNING: Viewall and autocenter disabled in favor of $vp*

ciao,
Torsten.

> As you can check, the $vpd remains 500, with or > without --viewall option. And generates this warning with --viewall which explains what's happening: WARNING: Viewall and autocenter disabled in favor of $vp* ciao, Torsten.
JB
Jordan Brown
Sat, Jan 23, 2021 3:39 PM

On 1/23/2021 4:13 AM, Vigardo wrote:

JordanBrown wrote

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.

Sure, but this is how a turn table is expected to behave :-)

So, as you noted, you can either rotate the model, or move the camera.

If you want to simulate a turntable, you'd rotate the model while
keeping the camera in the same place.  Note that the axes stay fixed.

rotate($t*360) cube(10, center=true);

From the CLI, you could have --camera set whatever viewpoint you

wanted.  You probably don't want --viewall, because for a non-trivial
model it'll probably zoom in and out to make the various views of the
model fit into the viewport.  (Or, alternatively, you could have the
model set $vpr/$vpt/$vpd and lock the viewpoint in place.)

If you want to simulate flying the camera around the model, you'd move
the camera while leaving the model in the same place.  Note that the
axes move, because the camera is moving relative to them.

$vpr=[80,0,360*$t];
$vpd=140;
$vpt=[0,0,0];
cube(10, center=true);

Here you would not want to use --camera or --viewall from the CLI,
because the model file is completely controlling the camera.

What values would you want for $vpt/$vpr/$vpd or, alternatively, for
--camera?  Probably simplest is to first not set up the camera, use
the interactive controls to put the camera where you want it, and then
read the values off the "Viewport" line at the bottom of the window. 
You can also use the "Copy viewport ..." options from the Edit menu.

On 1/23/2021 4:13 AM, Vigardo wrote: > JordanBrown wrote >> 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. > Sure, but this is how a turn table is expected to behave :-) So, as you noted, you can either rotate the model, or move the camera. If you want to simulate a turntable, you'd rotate the model while keeping the camera in the same place.  Note that the axes stay fixed. rotate($t*360) cube(10, center=true); >From the CLI, you could have --camera set whatever viewpoint you wanted.  You probably don't want --viewall, because for a non-trivial model it'll probably zoom in and out to make the various views of the model fit into the viewport.  (Or, alternatively, you could have the model set $vpr/$vpt/$vpd and lock the viewpoint in place.) If you want to simulate flying the camera around the model, you'd move the camera while leaving the model in the same place.  Note that the axes move, because the camera is moving relative to them. $vpr=[80,0,360*$t]; $vpd=140; $vpt=[0,0,0]; cube(10, center=true); Here you would not want to use --camera or --viewall from the CLI, because the model file is completely controlling the camera. What values would you want for $vpt/$vpr/$vpd or, alternatively, for --camera?  Probably simplest is to first *not* set up the camera, use the interactive controls to put the camera where you want it, and then read the values off the "Viewport" line at the bottom of the window.  You can also use the "Copy viewport ..." options from the Edit menu.
V
Vigardo
Sat, Jan 23, 2021 4:32 PM

tp3 wrote

And generates this warning with --viewall which explains what's happening:
WARNING: Viewall and autocenter disabled in favor of $vp*

You´re absolutely right. I miss that warning, I´m sorry!

JordanBrown wrote

From the CLI, you could have --camera set whatever viewpoint you
wanted.  You probably don't want --viewall, because for a non-trivial
model it'll probably zoom in and out to make the various views of the
model fit into the viewport.  (Or, alternatively, you could have the
model set $vpr/$vpt/$vpd and lock the viewpoint in place.)

This is exactly what I´m trying to. However, if I keep the camera fix and
rotate the model, the zoom in and out issue happens. Both using or not
--viewall option. Conversely, if I keep the model fix but rotate the camera
around it, then I have to manually set the $vpd variable... which is not
possible (see next)

JordanBrown wrote

What values would you want for $vpt/$vpr/$vpd or, alternatively, for
--camera?  Probably simplest is to first not set up the camera, use
the interactive controls to put the camera where you want it, and then
read the values off the "Viewport" line at the bottom of the window. 
You can also use the "Copy viewport ..." options from the Edit menu.

Unfortunately, your approach is not possible for my application. Let me tell
you more. I´m developing some web server that is intended to run OpenSCAD
(server side), so automation and CLI are mandatory. Sorry, perhaps I should
have told this before.

I already figured out a quite dirty workaround to create the turntable... I
used an awk script that parsed the an OpenSCAD generated STL file to dump
its boundary box and from it I can roughly estimate $vpd... But I don´t like
this solution since it slows down even more my workflow. The way OpenSCAD
defines the appropriate camera zoom using the "View All" seems much better.

How would I tell OpenSCAD (from CLI) to use and keep fixed the camera "View
All" parameters?

Perhaps adding a "--viewall_zero" option to initialize all view parameters
at $t=0 (i.e. for the first frame), and then let the user choose which $vp*
parameters to update via code?

Any better alternative?

--
Sent from: http://forum.openscad.org/

tp3 wrote > And generates this warning with --viewall which explains what's happening: > WARNING: Viewall and autocenter disabled in favor of $vp* You´re absolutely right. I miss that warning, I´m sorry! JordanBrown wrote > From the CLI, you could have --camera set whatever viewpoint you > wanted.  You probably don't want --viewall, because for a non-trivial > model it'll probably zoom in and out to make the various views of the > model fit into the viewport.  (Or, alternatively, you could have the > model set $vpr/$vpt/$vpd and lock the viewpoint in place.) This is exactly what I´m trying to. However, if I keep the camera fix and rotate the model, the zoom in and out issue happens. Both using or not --viewall option. Conversely, if I keep the model fix but rotate the camera around it, then I have to manually set the $vpd variable... which is not possible (see next) JordanBrown wrote > What values would you want for $vpt/$vpr/$vpd or, alternatively, for > --camera?  Probably simplest is to first *not* set up the camera, use > the interactive controls to put the camera where you want it, and then > read the values off the "Viewport" line at the bottom of the window.  > You can also use the "Copy viewport ..." options from the Edit menu. Unfortunately, your approach is not possible for my application. Let me tell you more. I´m developing some web server that is intended to run OpenSCAD (server side), so automation and CLI are mandatory. Sorry, perhaps I should have told this before. I already figured out a quite dirty workaround to create the turntable... I used an awk script that parsed the an OpenSCAD generated STL file to dump its boundary box and from it I can roughly estimate $vpd... But I don´t like this solution since it slows down even more my workflow. The way OpenSCAD defines the appropriate camera zoom using the "View All" seems much better. How would I tell OpenSCAD (from CLI) to use and keep fixed the camera "View All" parameters? Perhaps adding a "--viewall_zero" option to initialize all view parameters at $t=0 (i.e. for the first frame), and then let the user choose which $vp* parameters to update via code? Any better alternative? -- Sent from: http://forum.openscad.org/
JB
Jordan Brown
Sat, Jan 23, 2021 4:55 PM

Sorry, we've exceeded my understanding.  Somebody who understands the
camera settings, and in particular how they relate to "view all", will
need to chime in.

Sorry, we've exceeded my understanding.  Somebody who understands the camera settings, and in particular how they relate to "view all", will need to chime in.
NH
nop head
Sat, Jan 23, 2021 6:33 PM

I always use --autocenter with --viewall on the command line to get the
camera looking at the object and scaling it to fit. I haven't tried the
command line animation yet. If it recomputes the camera setting per frame I
could that would be a problem. In the GUI you do it first and then start
the animation. It needs to match that.

On Sat, 23 Jan 2021 at 17:32, Jordan Brown openscad@jordan.maileater.net
wrote:

Sorry, we've exceeded my understanding.  Somebody who understands the
camera settings, and in particular how they relate to "view all", will need
to chime in.

OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

I always use --autocenter with --viewall on the command line to get the camera looking at the object and scaling it to fit. I haven't tried the command line animation yet. If it recomputes the camera setting per frame I could that would be a problem. In the GUI you do it first and then start the animation. It needs to match that. On Sat, 23 Jan 2021 at 17:32, Jordan Brown <openscad@jordan.maileater.net> wrote: > Sorry, we've exceeded my understanding. Somebody who understands the > camera settings, and in particular how they relate to "view all", will need > to chime in. > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >
Next page
Empathy v1.0   2026 ©emwd.com
Documentation