RW
Rogier Wolff
Wed, May 1, 2024 4:59 PM
Hi,
I was just cosidering if maybe I should write a script that simply
calls openscad with the appropriate arguments to generate all my STLs
for my project.
I usually work with view==1 to show the assembly and then other
numbers will call all the submodules that need printint separately (or
a build-plate)
When I use interactive openscad, the "preview" finishes in 25 ms. in a
fresh openscad. About 2 seconds realtime.
Generating the mesh (F6) then takes 137ms. (using "manifold").
No time delays are observed except "waiting for input from user" when
I then export the STL.
But when I run:
time openscad -q -o esun-reel.stl -D view=2 esun-reel.scad
there is a significant delay. "time" tells me 8 seconds realtime with
about 96% CPU usage.
Would this be unavoidable, or is there something wrong somewhere?
Oh? Is it using my GPU in interactive mode, and not in commandline
mode?
I had copied the commandline from some stackexchange example, so I
didn't know (but suspected) what -q did. I did it without,
and... openscad then reports a total rendering time of 8 seconds...
Could it be that it is not loading my "preference" to use manifold?
OK! Yes, that's it. I tried another openscad binary on my system
without manifold and it takes on the order of 11 seconds to render
(F6) my file.
So the question is: How do I select "manifold" as the render engine on
the commandline?
Roger.
P.S. The 16 seconds of CPU time (for this project) is not what worries
me. What really worries me is that I have a bunch of projects that
generate errors with the old rendering engine. If that happens without
me noticing, I'm prone to accidentally 3D print an older
version... stuff like that.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 **
f equals m times a. When your f is steady, and your m is going down
your a is going up. -- Chris Hadfield about flying up the space shuttle.
Hi,
I was just cosidering if maybe I should write a script that simply
calls openscad with the appropriate arguments to generate all my STLs
for my project.
I usually work with view==1 to show the assembly and then other
numbers will call all the submodules that need printint separately (or
a build-plate)
When I use interactive openscad, the "preview" finishes in 25 ms. in a
fresh openscad. About 2 seconds realtime.
Generating the mesh (F6) then takes 137ms. (using "manifold").
No time delays are observed except "waiting for input from user" when
I then export the STL.
But when I run:
time openscad -q -o esun-reel.stl -D view=2 esun-reel.scad
there is a significant delay. "time" tells me 8 seconds realtime with
about 96% CPU usage.
Would this be unavoidable, or is there something wrong somewhere?
Oh? Is it using my GPU in interactive mode, and not in commandline
mode?
I had copied the commandline from some stackexchange example, so I
didn't know (but suspected) what -q did. I did it without,
and... openscad then reports a total rendering time of 8 seconds...
Could it be that it is not loading my "preference" to use manifold?
OK! Yes, that's it. I tried another openscad binary on my system
without manifold and it takes on the order of 11 seconds to render
(F6) my file.
So the question is: How do I select "manifold" as the render engine on
the commandline?
Roger.
P.S. The 16 seconds of CPU time (for this project) is not what worries
me. What really worries me is that I have a bunch of projects that
generate errors with the old rendering engine. If that happens without
me noticing, I'm prone to accidentally 3D print an older
version... stuff like that.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 **
f equals m times a. When your f is steady, and your m is going down
your a is going up. -- Chris Hadfield about flying up the space shuttle.
NH
nop head
Wed, May 1, 2024 5:06 PM
Hi,
I was just cosidering if maybe I should write a script that simply
calls openscad with the appropriate arguments to generate all my STLs
for my project.
I usually work with view==1 to show the assembly and then other
numbers will call all the submodules that need printint separately (or
a build-plate)
When I use interactive openscad, the "preview" finishes in 25 ms. in a
fresh openscad. About 2 seconds realtime.
Generating the mesh (F6) then takes 137ms. (using "manifold").
No time delays are observed except "waiting for input from user" when
I then export the STL.
But when I run:
time openscad -q -o esun-reel.stl -D view=2 esun-reel.scad
there is a significant delay. "time" tells me 8 seconds realtime with
about 96% CPU usage.
Would this be unavoidable, or is there something wrong somewhere?
Oh? Is it using my GPU in interactive mode, and not in commandline
mode?
I had copied the commandline from some stackexchange example, so I
didn't know (but suspected) what -q did. I did it without,
and... openscad then reports a total rendering time of 8 seconds...
Could it be that it is not loading my "preference" to use manifold?
OK! Yes, that's it. I tried another openscad binary on my system
without manifold and it takes on the order of 11 seconds to render
(F6) my file.
So the question is: How do I select "manifold" as the render engine on
the commandline?
Roger.
P.S. The 16 seconds of CPU time (for this project) is not what worries
me. What really worries me is that I have a bunch of projects that
generate errors with the old rendering engine. If that happens without
me noticing, I'm prone to accidentally 3D print an older
version... stuff like that.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110
**
** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 **
f equals m times a. When your f is steady, and your m is going down
your a is going up. -- Chris Hadfield about flying up the space shuttle.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
--enable manifold on the command line.
On Wed, 1 May 2024 at 17:59, Rogier Wolff via Discuss <
discuss@lists.openscad.org> wrote:
>
> Hi,
>
> I was just cosidering if maybe I should write a script that simply
> calls openscad with the appropriate arguments to generate all my STLs
> for my project.
>
> I usually work with view==1 to show the assembly and then other
> numbers will call all the submodules that need printint separately (or
> a build-plate)
>
> When I use interactive openscad, the "preview" finishes in 25 ms. in a
> fresh openscad. About 2 seconds realtime.
>
> Generating the mesh (F6) then takes 137ms. (using "manifold").
>
> No time delays are observed except "waiting for input from user" when
> I then export the STL.
>
> But when I run:
>
> time openscad -q -o esun-reel.stl -D view=2 esun-reel.scad
>
> there is a significant delay. "time" tells me 8 seconds realtime with
> about 96% CPU usage.
>
> Would this be unavoidable, or is there something wrong somewhere?
>
> Oh? Is it using my GPU in interactive mode, and not in commandline
> mode?
>
> I had copied the commandline from some stackexchange example, so I
> didn't know (but suspected) what -q did. I did it without,
> and... openscad then reports a total rendering time of 8 seconds...
>
> Could it be that it is not loading my "preference" to use manifold?
> OK! Yes, that's it. I tried another openscad binary on my system
> without manifold and it takes on the order of 11 seconds to render
> (F6) my file.
>
> So the question is: How do I select "manifold" as the render engine on
> the commandline?
>
> Roger.
>
> P.S. The 16 seconds of CPU time (for this project) is not what worries
> me. What really worries me is that I have a bunch of projects that
> generate errors with the old rendering engine. If that happens without
> me noticing, I'm prone to accidentally 3D print an older
> version... stuff like that.
>
>
> --
> ** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110
> **
> ** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 **
> f equals m times a. When your f is steady, and your m is going down
> your a is going up. -- Chris Hadfield about flying up the space shuttle.
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
NH
nop head
Wed, May 1, 2024 5:07 PM
The command line version doesn't inherit any of the GUI preferences.
On Wed, 1 May 2024 at 18:06, nop head nop.head@gmail.com wrote:
Hi,
I was just cosidering if maybe I should write a script that simply
calls openscad with the appropriate arguments to generate all my STLs
for my project.
I usually work with view==1 to show the assembly and then other
numbers will call all the submodules that need printint separately (or
a build-plate)
When I use interactive openscad, the "preview" finishes in 25 ms. in a
fresh openscad. About 2 seconds realtime.
Generating the mesh (F6) then takes 137ms. (using "manifold").
No time delays are observed except "waiting for input from user" when
I then export the STL.
But when I run:
time openscad -q -o esun-reel.stl -D view=2 esun-reel.scad
there is a significant delay. "time" tells me 8 seconds realtime with
about 96% CPU usage.
Would this be unavoidable, or is there something wrong somewhere?
Oh? Is it using my GPU in interactive mode, and not in commandline
mode?
I had copied the commandline from some stackexchange example, so I
didn't know (but suspected) what -q did. I did it without,
and... openscad then reports a total rendering time of 8 seconds...
Could it be that it is not loading my "preference" to use manifold?
OK! Yes, that's it. I tried another openscad binary on my system
without manifold and it takes on the order of 11 seconds to render
(F6) my file.
So the question is: How do I select "manifold" as the render engine on
the commandline?
Roger.
P.S. The 16 seconds of CPU time (for this project) is not what worries
me. What really worries me is that I have a bunch of projects that
generate errors with the old rendering engine. If that happens without
me noticing, I'm prone to accidentally 3D print an older
version... stuff like that.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110
**
** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233
**
f equals m times a. When your f is steady, and your m is going down
your a is going up. -- Chris Hadfield about flying up the space shuttle.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
The command line version doesn't inherit any of the GUI preferences.
On Wed, 1 May 2024 at 18:06, nop head <nop.head@gmail.com> wrote:
> --enable manifold on the command line.
>
> On Wed, 1 May 2024 at 17:59, Rogier Wolff via Discuss <
> discuss@lists.openscad.org> wrote:
>
>>
>> Hi,
>>
>> I was just cosidering if maybe I should write a script that simply
>> calls openscad with the appropriate arguments to generate all my STLs
>> for my project.
>>
>> I usually work with view==1 to show the assembly and then other
>> numbers will call all the submodules that need printint separately (or
>> a build-plate)
>>
>> When I use interactive openscad, the "preview" finishes in 25 ms. in a
>> fresh openscad. About 2 seconds realtime.
>>
>> Generating the mesh (F6) then takes 137ms. (using "manifold").
>>
>> No time delays are observed except "waiting for input from user" when
>> I then export the STL.
>>
>> But when I run:
>>
>> time openscad -q -o esun-reel.stl -D view=2 esun-reel.scad
>>
>> there is a significant delay. "time" tells me 8 seconds realtime with
>> about 96% CPU usage.
>>
>> Would this be unavoidable, or is there something wrong somewhere?
>>
>> Oh? Is it using my GPU in interactive mode, and not in commandline
>> mode?
>>
>> I had copied the commandline from some stackexchange example, so I
>> didn't know (but suspected) what -q did. I did it without,
>> and... openscad then reports a total rendering time of 8 seconds...
>>
>> Could it be that it is not loading my "preference" to use manifold?
>> OK! Yes, that's it. I tried another openscad binary on my system
>> without manifold and it takes on the order of 11 seconds to render
>> (F6) my file.
>>
>> So the question is: How do I select "manifold" as the render engine on
>> the commandline?
>>
>> Roger.
>>
>> P.S. The 16 seconds of CPU time (for this project) is not what worries
>> me. What really worries me is that I have a bunch of projects that
>> generate errors with the old rendering engine. If that happens without
>> me noticing, I'm prone to accidentally 3D print an older
>> version... stuff like that.
>>
>>
>> --
>> ** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110
>> **
>> ** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233
>> **
>> f equals m times a. When your f is steady, and your m is going down
>> your a is going up. -- Chris Hadfield about flying up the space shuttle.
>> _______________________________________________
>> OpenSCAD mailing list
>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>
>
GB
Glenn Butcher
Wed, May 1, 2024 6:41 PM
Rogier,
Related to the title of your post, I have an OpenSCAD project of some 28
individual parts, same sort of need for something to keep the .stl files
current. I messed a bit with unix 'make', worked okay but I thought a
more OpenSCAD-specific tool would be nice.
So, I wrote a make-like tool, I call it 'scadmake'. It requires a
simple configuration file to point to openscad and the directory with
the .scad files, running in a directory where the .stl files will go it
will check each script to see if it is newer than the corresponding .stl
file and if so, run openscad to make it. Just like 'make' does for
computer programs, but without all the targets. It also checks all of a
script's dependencies to do the same thing. Found here:
https://github.com/butcherg/SCADMake
Unfortunately, you currently have to compile the program yourself. If
there's interest, I can make a bit of time to compile a Windows
executable...
Glenn
On 5/1/2024 10:59 AM, Rogier Wolff via Discuss wrote:
Hi,
I was just cosidering if maybe I should write a script that simply
calls openscad with the appropriate arguments to generate all my STLs
for my project.
I usually work with view==1 to show the assembly and then other
numbers will call all the submodules that need printint separately (or
a build-plate)
When I use interactive openscad, the "preview" finishes in 25 ms. in a
fresh openscad. About 2 seconds realtime.
Generating the mesh (F6) then takes 137ms. (using "manifold").
No time delays are observed except "waiting for input from user" when
I then export the STL.
But when I run:
time openscad -q -o esun-reel.stl -D view=2 esun-reel.scad
there is a significant delay. "time" tells me 8 seconds realtime with
about 96% CPU usage.
Would this be unavoidable, or is there something wrong somewhere?
Oh? Is it using my GPU in interactive mode, and not in commandline
mode?
I had copied the commandline from some stackexchange example, so I
didn't know (but suspected) what -q did. I did it without,
and... openscad then reports a total rendering time of 8 seconds...
Could it be that it is not loading my "preference" to use manifold?
OK! Yes, that's it. I tried another openscad binary on my system
without manifold and it takes on the order of 11 seconds to render
(F6) my file.
So the question is: How do I select "manifold" as the render engine on
the commandline?
Roger.
P.S. The 16 seconds of CPU time (for this project) is not what worries
me. What really worries me is that I have a bunch of projects that
generate errors with the old rendering engine. If that happens without
me noticing, I'm prone to accidentally 3D print an older
version... stuff like that.
Rogier,
Related to the title of your post, I have an OpenSCAD project of some 28
individual parts, same sort of need for something to keep the .stl files
current. I messed a bit with unix 'make', worked okay but I thought a
more OpenSCAD-specific tool would be nice.
So, I wrote a make-like tool, I call it 'scadmake'. It requires a
simple configuration file to point to openscad and the directory with
the .scad files, running in a directory where the .stl files will go it
will check each script to see if it is newer than the corresponding .stl
file and if so, run openscad to make it. Just like 'make' does for
computer programs, but without all the targets. It also checks all of a
script's dependencies to do the same thing. Found here:
https://github.com/butcherg/SCADMake
Unfortunately, you currently have to compile the program yourself. If
there's interest, I can make a bit of time to compile a Windows
executable...
Glenn
On 5/1/2024 10:59 AM, Rogier Wolff via Discuss wrote:
> Hi,
>
> I was just cosidering if maybe I should write a script that simply
> calls openscad with the appropriate arguments to generate all my STLs
> for my project.
>
> I usually work with view==1 to show the assembly and then other
> numbers will call all the submodules that need printint separately (or
> a build-plate)
>
> When I use interactive openscad, the "preview" finishes in 25 ms. in a
> fresh openscad. About 2 seconds realtime.
>
> Generating the mesh (F6) then takes 137ms. (using "manifold").
>
> No time delays are observed except "waiting for input from user" when
> I then export the STL.
>
> But when I run:
>
> time openscad -q -o esun-reel.stl -D view=2 esun-reel.scad
>
> there is a significant delay. "time" tells me 8 seconds realtime with
> about 96% CPU usage.
>
> Would this be unavoidable, or is there something wrong somewhere?
>
> Oh? Is it using my GPU in interactive mode, and not in commandline
> mode?
>
> I had copied the commandline from some stackexchange example, so I
> didn't know (but suspected) what -q did. I did it without,
> and... openscad then reports a total rendering time of 8 seconds...
>
> Could it be that it is not loading my "preference" to use manifold?
> OK! Yes, that's it. I tried another openscad binary on my system
> without manifold and it takes on the order of 11 seconds to render
> (F6) my file.
>
> So the question is: How do I select "manifold" as the render engine on
> the commandline?
>
> Roger.
>
> P.S. The 16 seconds of CPU time (for this project) is not what worries
> me. What really worries me is that I have a bunch of projects that
> generate errors with the old rendering engine. If that happens without
> me noticing, I'm prone to accidentally 3D print an older
> version... stuff like that.
>
>
NH
nop head
Wed, May 1, 2024 9:58 PM
NopSCADlib has a python framework that makes all the STL files for a
project looking at the dependencies. It also can make assembly views and
build instructions.
On Wed, 1 May 2024, 19:42 Glenn Butcher via Discuss, <
discuss@lists.openscad.org> wrote:
Rogier,
Related to the title of your post, I have an OpenSCAD project of some 28
individual parts, same sort of need for something to keep the .stl files
current. I messed a bit with unix 'make', worked okay but I thought a
more OpenSCAD-specific tool would be nice.
So, I wrote a make-like tool, I call it 'scadmake'. It requires a
simple configuration file to point to openscad and the directory with
the .scad files, running in a directory where the .stl files will go it
will check each script to see if it is newer than the corresponding .stl
file and if so, run openscad to make it. Just like 'make' does for
computer programs, but without all the targets. It also checks all of a
script's dependencies to do the same thing. Found here:
https://github.com/butcherg/SCADMake
Unfortunately, you currently have to compile the program yourself. If
there's interest, I can make a bit of time to compile a Windows
executable...
Glenn
On 5/1/2024 10:59 AM, Rogier Wolff via Discuss wrote:
Hi,
I was just cosidering if maybe I should write a script that simply
calls openscad with the appropriate arguments to generate all my STLs
for my project.
I usually work with view==1 to show the assembly and then other
numbers will call all the submodules that need printint separately (or
a build-plate)
When I use interactive openscad, the "preview" finishes in 25 ms. in a
fresh openscad. About 2 seconds realtime.
Generating the mesh (F6) then takes 137ms. (using "manifold").
No time delays are observed except "waiting for input from user" when
I then export the STL.
But when I run:
time openscad -q -o esun-reel.stl -D view=2 esun-reel.scad
there is a significant delay. "time" tells me 8 seconds realtime with
about 96% CPU usage.
Would this be unavoidable, or is there something wrong somewhere?
Oh? Is it using my GPU in interactive mode, and not in commandline
mode?
I had copied the commandline from some stackexchange example, so I
didn't know (but suspected) what -q did. I did it without,
and... openscad then reports a total rendering time of 8 seconds...
Could it be that it is not loading my "preference" to use manifold?
OK! Yes, that's it. I tried another openscad binary on my system
without manifold and it takes on the order of 11 seconds to render
(F6) my file.
So the question is: How do I select "manifold" as the render engine on
the commandline?
Roger.
P.S. The 16 seconds of CPU time (for this project) is not what worries
me. What really worries me is that I have a bunch of projects that
generate errors with the old rendering engine. If that happens without
me noticing, I'm prone to accidentally 3D print an older
version... stuff like that.
NopSCADlib has a python framework that makes all the STL files for a
project looking at the dependencies. It also can make assembly views and
build instructions.
On Wed, 1 May 2024, 19:42 Glenn Butcher via Discuss, <
discuss@lists.openscad.org> wrote:
> Rogier,
>
> Related to the title of your post, I have an OpenSCAD project of some 28
> individual parts, same sort of need for something to keep the .stl files
> current. I messed a bit with unix 'make', worked okay but I thought a
> more OpenSCAD-specific tool would be nice.
>
> So, I wrote a make-like tool, I call it 'scadmake'. It requires a
> simple configuration file to point to openscad and the directory with
> the .scad files, running in a directory where the .stl files will go it
> will check each script to see if it is newer than the corresponding .stl
> file and if so, run openscad to make it. Just like 'make' does for
> computer programs, but without all the targets. It also checks all of a
> script's dependencies to do the same thing. Found here:
>
> https://github.com/butcherg/SCADMake
>
> Unfortunately, you currently have to compile the program yourself. If
> there's interest, I can make a bit of time to compile a Windows
> executable...
>
> Glenn
>
> On 5/1/2024 10:59 AM, Rogier Wolff via Discuss wrote:
> > Hi,
> >
> > I was just cosidering if maybe I should write a script that simply
> > calls openscad with the appropriate arguments to generate all my STLs
> > for my project.
> >
> > I usually work with view==1 to show the assembly and then other
> > numbers will call all the submodules that need printint separately (or
> > a build-plate)
> >
> > When I use interactive openscad, the "preview" finishes in 25 ms. in a
> > fresh openscad. About 2 seconds realtime.
> >
> > Generating the mesh (F6) then takes 137ms. (using "manifold").
> >
> > No time delays are observed except "waiting for input from user" when
> > I then export the STL.
> >
> > But when I run:
> >
> > time openscad -q -o esun-reel.stl -D view=2 esun-reel.scad
> >
> > there is a significant delay. "time" tells me 8 seconds realtime with
> > about 96% CPU usage.
> >
> > Would this be unavoidable, or is there something wrong somewhere?
> >
> > Oh? Is it using my GPU in interactive mode, and not in commandline
> > mode?
> >
> > I had copied the commandline from some stackexchange example, so I
> > didn't know (but suspected) what -q did. I did it without,
> > and... openscad then reports a total rendering time of 8 seconds...
> >
> > Could it be that it is not loading my "preference" to use manifold?
> > OK! Yes, that's it. I tried another openscad binary on my system
> > without manifold and it takes on the order of 11 seconds to render
> > (F6) my file.
> >
> > So the question is: How do I select "manifold" as the render engine on
> > the commandline?
> >
> > Roger.
> >
> > P.S. The 16 seconds of CPU time (for this project) is not what worries
> > me. What really worries me is that I have a bunch of projects that
> > generate errors with the old rendering engine. If that happens without
> > me noticing, I'm prone to accidentally 3D print an older
> > version... stuff like that.
> >
> >
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
JB
Jordan Brown
Wed, May 1, 2024 11:09 PM
You should expect that it would take a little longer using the command
line, because you have to start the program from zero each time.
A "make" answer should be nearly trivial if it's 1:1 between the .SCAD
files and the .STL files. More complicated if you want to track library
dependencies; more complicated up front but less complicated on a
per-file basis if you want to automatically generate the dependency lists.
My personal answer is that I have a module that lets me select one of N
models in the file (or all of them), and that will also give me a list
of the models, and have a shell script that gets the list and then
generates STL and PNG files as directed.
Attached please find the little library that does the work, the shell
script, and a file that uses them.
The file that uses them is not an exact match; it is for an earlier
version that's embedded in a different library, and I haven't included
the other libraries that it needs. But it should give you an idea of
how it works. If you want a full working set let me know.
Or you can look at https://www.thingiverse.com/thing:4264614 .
You should expect that it would take a *little* longer using the command
line, because you have to start the program from zero each time.
A "make" answer should be nearly trivial if it's 1:1 between the .SCAD
files and the .STL files. More complicated if you want to track library
dependencies; more complicated up front but less complicated on a
per-file basis if you want to automatically generate the dependency lists.
---
My personal answer is that I have a module that lets me select one of N
models in the file (or all of them), and that will also give me a list
of the models, and have a shell script that gets the list and then
generates STL and PNG files as directed.
Attached please find the little library that does the work, the shell
script, and a file that uses them.
The file that uses them is not an exact match; it is for an earlier
version that's embedded in a different library, and I haven't included
the other libraries that it needs. But it should give you an idea of
how it works. If you want a full working set let me know.
Or you can look at https://www.thingiverse.com/thing:4264614 .
MH
Matthieu Hendriks
Thu, May 2, 2024 4:17 AM
I.ve created several bash scripts for autogenerate stl and png files:
scadcreate projectname [print_obj1 print_obj2 mod1 mod2] // basic
scipt for generating an skeleton scad file with an auto run section and
include section
scad4include projectname // script for regenerate the auto run
section
scad2stl projectname // create a png file and a stl file for
every module that start with print_
scad2mp4 projectname // create a movie from a a rotating model
osm // a menu file for calling the different scripts
All files are simple adaptable to your needs, installation/documentation
in the script itself
If you start scadcreate as follows:
scadcreate test print_t print_s m1 m2
you get :
//******************
// Title: test
// Author: Matthieu Hendriks
// Date: 2024-04-25
// License: t.b.d
//******************
// start include section
//******************
include <mhlib/mhlib.scad>;
// *****************
// start constants section
// *****************
// constants
$fn=128;
run="main";
// *****************
// start run section
// *****************
/* runstart Start:autogenerated run file */
if (run == "print_t") { print_t(); }
if (run == "print_s") { print_s(); }
module main() {
// print_t();
// print_s();
}
module run_all() {
mvx(10) print_t();
mvx(20) print_s();
}
/* runeind End:autogenerated run file */
// *****************
// start module section
// *****************
module print_t() {
}
module print_s() {
}
module m1() {
}
module m2() {
}
mhlib is my own small standard library with usefull modules like mv,
mvx, mvy, mvz, rot and so on (shorthand for translate9[x,y,x]),
rotate([x,y,z])
Groet Matthieu
Matthieu Hendriks
Telf: 06-52371841
I.ve created several bash scripts for autogenerate stl and png files:
scadcreate projectname [print_obj1 print_obj2 mod1 mod2] // basic
scipt for generating an skeleton scad file with an auto run section and
include section
scad4include projectname // script for regenerate the auto run
section
scad2stl projectname // create a png file and a stl file for
every module that start with print_
scad2mp4 projectname // create a movie from a a rotating model
osm // a menu file for calling the different scripts
All files are simple adaptable to your needs, installation/documentation
in the script itself
If you start scadcreate as follows:
scadcreate test print_t print_s m1 m2
you get :
//******************
// Title: test
// Author: Matthieu Hendriks
// Date: 2024-04-25
// License: t.b.d
//******************
// start include section
//******************
include <mhlib/mhlib.scad>;
// *****************
// start constants section
// *****************
// constants
$fn=128;
run="main";
// *****************
// start run section
// *****************
/* runstart Start:autogenerated run file */
if (run == "print_t") { print_t(); }
if (run == "print_s") { print_s(); }
module main() {
// print_t();
// print_s();
}
module run_all() {
mvx(10) print_t();
mvx(20) print_s();
}
/* runeind End:autogenerated run file */
// *****************
// start module section
// *****************
module print_t() {
}
module print_s() {
}
module m1() {
}
module m2() {
}
mhlib is my own small standard library with usefull modules like mv,
mvx, mvy, mvz, rot and so on (shorthand for translate9[x,y,x]),
rotate([x,y,z])
Groet Matthieu
-------------------------
Matthieu Hendriks
Telf: 06-52371841
-------------------------
>
RW
Rogier Wolff
Thu, May 2, 2024 8:59 AM
On Wed, May 01, 2024 at 12:41:56PM -0600, Glenn Butcher via Discuss wrote:
Rogier,
Related to the title of your post, I have an OpenSCAD project of some 28
individual parts, same sort of need for something to keep the .stl files
current. I messed a bit with unix 'make', worked okay but I thought a more
OpenSCAD-specific tool would be nice.
So, I wrote a make-like tool, I call it 'scadmake'. It requires a simple
configuration file to point to openscad and the directory with the .scad
files, running in a directory where the .stl files will go it will check
each script to see if it is newer than the corresponding .stl file and if
so, run openscad to make it. Just like 'make' does for computer programs,
but without all the targets. It also checks all of a script's dependencies
to do the same thing. Found here:
https://github.com/butcherg/SCADMake
Unfortunately, you currently have to compile the program yourself. If
there's interest, I can make a bit of time to compile a Windows
executable...
I've been thinking about this since yesterday. if I create
a makefile:
all: foo-part1.stl foo-part2.stl
%.stl: %.scad
make_stl $< $@
foo-part1.stl: foo.scad
foo-part2.stl: foo.scad
and then a script make_stl that looks in the scad for the parameter
to make part1... then I'm all set, I think.
// generate foo-part1.stl view=2
// generate foo-part2.stl view=3
is easy for a sed to manipulate into the appropriate commandline option
for openscad. But something integrated is easy to do as well. Yeah. I'm
going to do that.
#!/bin/sh
file=$1
parts=grep '// generate' $file | awk '{print $3}' for p in $parts ; do v=sed -ne 's/generate.*'$p' //p' $file`
openscad -o $p -D $v
fi
^^^UNTESTED^^^
but something like that should work. But first I want to use manifold
for the STL generation. It is not good if I interactively look at one
"interpretation" of the source and then use a different "toolset"
to actually process it further.
This is already the case where preview sometimes (mostly older
versions of openscad) shows a valid model and hten "render" doesn't.
The documentation in the scad is going to be:
// list of machine readable output STLs:
// output 1 part1
// output 2 part2
little redundant typing and the script is where the magic happens.
Roger.
Glenn
On 5/1/2024 10:59 AM, Rogier Wolff via Discuss wrote:
Hi,
I was just cosidering if maybe I should write a script that simply
calls openscad with the appropriate arguments to generate all my STLs
for my project.
I usually work with view==1 to show the assembly and then other
numbers will call all the submodules that need printint separately (or
a build-plate)
When I use interactive openscad, the "preview" finishes in 25 ms. in a
fresh openscad. About 2 seconds realtime.
Generating the mesh (F6) then takes 137ms. (using "manifold").
No time delays are observed except "waiting for input from user" when
I then export the STL.
But when I run:
time openscad -q -o esun-reel.stl -D view=2 esun-reel.scad
there is a significant delay. "time" tells me 8 seconds realtime with
about 96% CPU usage.
Would this be unavoidable, or is there something wrong somewhere?
Oh? Is it using my GPU in interactive mode, and not in commandline
mode?
I had copied the commandline from some stackexchange example, so I
didn't know (but suspected) what -q did. I did it without,
and... openscad then reports a total rendering time of 8 seconds...
Could it be that it is not loading my "preference" to use manifold?
OK! Yes, that's it. I tried another openscad binary on my system
without manifold and it takes on the order of 11 seconds to render
(F6) my file.
So the question is: How do I select "manifold" as the render engine on
the commandline?
Roger.
P.S. The 16 seconds of CPU time (for this project) is not what worries
me. What really worries me is that I have a bunch of projects that
generate errors with the old rendering engine. If that happens without
me noticing, I'm prone to accidentally 3D print an older
version... stuff like that.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 **
f equals m times a. When your f is steady, and your m is going down
your a is going up. -- Chris Hadfield about flying up the space shuttle.
On Wed, May 01, 2024 at 12:41:56PM -0600, Glenn Butcher via Discuss wrote:
> Rogier,
>
> Related to the title of your post, I have an OpenSCAD project of some 28
> individual parts, same sort of need for something to keep the .stl files
> current. I messed a bit with unix 'make', worked okay but I thought a more
> OpenSCAD-specific tool would be nice.
>
> So, I wrote a make-like tool, I call it 'scadmake'. It requires a simple
> configuration file to point to openscad and the directory with the .scad
> files, running in a directory where the .stl files will go it will check
> each script to see if it is newer than the corresponding .stl file and if
> so, run openscad to make it. Just like 'make' does for computer programs,
> but without all the targets. It also checks all of a script's dependencies
> to do the same thing. Found here:
>
> https://github.com/butcherg/SCADMake
>
> Unfortunately, you currently have to compile the program yourself. If
> there's interest, I can make a bit of time to compile a Windows
> executable...
I've been thinking about this since yesterday. if I create
a makefile:
all: foo-part1.stl foo-part2.stl
%.stl: %.scad
make_stl $< $@
foo-part1.stl: foo.scad
foo-part2.stl: foo.scad
and then a script make_stl that looks in the scad for the parameter
to make part1... then I'm all set, I think.
// generate foo-part1.stl view=2
// generate foo-part2.stl view=3
is easy for a sed to manipulate into the appropriate commandline option
for openscad. But something integrated is easy to do as well. Yeah. I'm
going to do that.
#!/bin/sh
file=$1
parts=`grep '// generate' $file | awk '{print $3}'
for p in $parts ; do
v=`sed -ne 's/generate.*'$p' //p' $file`
openscad -o $p -D $v
fi
^^^UNTESTED^^^
but something like that should work. But first I want to use manifold
for the STL generation. It is not good if I interactively look at one
"interpretation" of the source and then use a different "toolset"
to actually process it further.
This is already the case where preview sometimes (mostly older
versions of openscad) shows a valid model and hten "render" doesn't.
The documentation in the scad is going to be:
// list of machine readable output STLs:
// output 1 part1
// output 2 part2
little redundant typing and the script is where the magic happens.
Roger.
>
> Glenn
>
> On 5/1/2024 10:59 AM, Rogier Wolff via Discuss wrote:
> > Hi,
> >
> > I was just cosidering if maybe I should write a script that simply
> > calls openscad with the appropriate arguments to generate all my STLs
> > for my project.
> >
> > I usually work with view==1 to show the assembly and then other
> > numbers will call all the submodules that need printint separately (or
> > a build-plate)
> >
> > When I use interactive openscad, the "preview" finishes in 25 ms. in a
> > fresh openscad. About 2 seconds realtime.
> >
> > Generating the mesh (F6) then takes 137ms. (using "manifold").
> >
> > No time delays are observed except "waiting for input from user" when
> > I then export the STL.
> >
> > But when I run:
> >
> > time openscad -q -o esun-reel.stl -D view=2 esun-reel.scad
> >
> > there is a significant delay. "time" tells me 8 seconds realtime with
> > about 96% CPU usage.
> >
> > Would this be unavoidable, or is there something wrong somewhere?
> >
> > Oh? Is it using my GPU in interactive mode, and not in commandline
> > mode?
> >
> > I had copied the commandline from some stackexchange example, so I
> > didn't know (but suspected) what -q did. I did it without,
> > and... openscad then reports a total rendering time of 8 seconds...
> >
> > Could it be that it is not loading my "preference" to use manifold?
> > OK! Yes, that's it. I tried another openscad binary on my system
> > without manifold and it takes on the order of 11 seconds to render
> > (F6) my file.
> >
> > So the question is: How do I select "manifold" as the render engine on
> > the commandline?
> >
> > Roger.
> >
> > P.S. The 16 seconds of CPU time (for this project) is not what worries
> > me. What really worries me is that I have a bunch of projects that
> > generate errors with the old rendering engine. If that happens without
> > me noticing, I'm prone to accidentally 3D print an older
> > version... stuff like that.
> >
> >
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 **
f equals m times a. When your f is steady, and your m is going down
your a is going up. -- Chris Hadfield about flying up the space shuttle.
RW
Rogier Wolff
Thu, May 2, 2024 9:11 AM
On Wed, May 01, 2024 at 11:09:41PM +0000, Jordan Brown via Discuss wrote:
You should expect that it would take a little longer using the command
line, because you have to start the program from zero each time.
Right! But generally speaking I can start programs say with 10ms intervals
between invocations on my computer and get a significant fraction of
100 invocations per second. (that's a generic test script that waits
the specified amount BETWEEN invocations of the specified program!)
So my computer is plenty fast to start up a program in a fraction
of a second. And although openscad time-measurements are WAY off (*), they
are this time close enough to determine for sure that it is not
the "starting the program" that is costing time, but the "old rendering
engine".
Roger.
(*) It is not currently worth looking into: I bet we'll find it is
measuring something correctly.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 **
f equals m times a. When your f is steady, and your m is going down
your a is going up. -- Chris Hadfield about flying up the space shuttle.
On Wed, May 01, 2024 at 11:09:41PM +0000, Jordan Brown via Discuss wrote:
> You should expect that it would take a *little* longer using the command
> line, because you have to start the program from zero each time.
Right! But generally speaking I can start programs say with 10ms intervals
between invocations on my computer and get a significant fraction of
100 invocations per second. (that's a generic test script that waits
the specified amount BETWEEN invocations of the specified program!)
So my computer is plenty fast to start up a program in a fraction
of a second. And although openscad time-measurements are WAY off (*), they
are this time close enough to determine for sure that it is not
the "starting the program" that is costing time, but the "old rendering
engine".
Roger.
(*) It is not currently worth looking into: I bet we'll find it is
measuring *something* correctly.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 **
f equals m times a. When your f is steady, and your m is going down
your a is going up. -- Chris Hadfield about flying up the space shuttle.
GB
Glenn Butcher
Thu, May 2, 2024 1:06 PM
If you're not worried about dependencies based on include <> or use <>
in your scripts, your makefile will work okay.
For my project, I have three subdirectories:
lib/
scad/
stl/
scad/ contains the scripts that generate the individual .stl files, lib/
contains parts that make up some of the assemblies in scad/, as well a a
few libraries that include generally useful modules, and stl/ is where
the generated .stl file go. If any of the lib/ files change, I need to
re-generate the .stl files of the scad/*.scad scripts that use them, so
dependencies are a thing for me.
You can see the whole thing here:
https://github.com/butcherg/DRG_168
There's a Makefile in st/ that shows dependencies for each make target.
It's a bit outdated, but you should get the drift...
On 5/2/24 02:59, Rogier Wolff wrote:
On Wed, May 01, 2024 at 12:41:56PM -0600, Glenn Butcher via Discuss wrote:
Rogier,
Related to the title of your post, I have an OpenSCAD project of some 28
individual parts, same sort of need for something to keep the .stl files
current. I messed a bit with unix 'make', worked okay but I thought a more
OpenSCAD-specific tool would be nice.
So, I wrote a make-like tool, I call it 'scadmake'. It requires a simple
configuration file to point to openscad and the directory with the .scad
files, running in a directory where the .stl files will go it will check
each script to see if it is newer than the corresponding .stl file and if
so, run openscad to make it. Just like 'make' does for computer programs,
but without all the targets. It also checks all of a script's dependencies
to do the same thing. Found here:
https://github.com/butcherg/SCADMake
Unfortunately, you currently have to compile the program yourself. If
there's interest, I can make a bit of time to compile a Windows
executable...
I've been thinking about this since yesterday. if I create
a makefile:
all: foo-part1.stl foo-part2.stl
%.stl: %.scad
make_stl $< $@
foo-part1.stl: foo.scad
foo-part2.stl: foo.scad
and then a script make_stl that looks in the scad for the parameter
to make part1... then I'm all set, I think.
// generate foo-part1.stl view=2
// generate foo-part2.stl view=3
is easy for a sed to manipulate into the appropriate commandline option
for openscad. But something integrated is easy to do as well. Yeah. I'm
going to do that.
#!/bin/sh
file=$1
parts=grep '// generate' $file | awk '{print $3}' for p in $parts ; do v=sed -ne 's/generate.*'$p' //p' $file`
openscad -o $p -D $v
fi
^^^UNTESTED^^^
but something like that should work. But first I want to use manifold
for the STL generation. It is not good if I interactively look at one
"interpretation" of the source and then use a different "toolset"
to actually process it further.
This is already the case where preview sometimes (mostly older
versions of openscad) shows a valid model and hten "render" doesn't.
The documentation in the scad is going to be:
// list of machine readable output STLs:
// output 1 part1
// output 2 part2
little redundant typing and the script is where the magic happens.
Roger.
Glenn
On 5/1/2024 10:59 AM, Rogier Wolff via Discuss wrote:
Hi,
I was just cosidering if maybe I should write a script that simply
calls openscad with the appropriate arguments to generate all my STLs
for my project.
I usually work with view==1 to show the assembly and then other
numbers will call all the submodules that need printint separately (or
a build-plate)
When I use interactive openscad, the "preview" finishes in 25 ms. in a
fresh openscad. About 2 seconds realtime.
Generating the mesh (F6) then takes 137ms. (using "manifold").
No time delays are observed except "waiting for input from user" when
I then export the STL.
But when I run:
time openscad -q -o esun-reel.stl -D view=2 esun-reel.scad
there is a significant delay. "time" tells me 8 seconds realtime with
about 96% CPU usage.
Would this be unavoidable, or is there something wrong somewhere?
Oh? Is it using my GPU in interactive mode, and not in commandline
mode?
I had copied the commandline from some stackexchange example, so I
didn't know (but suspected) what -q did. I did it without,
and... openscad then reports a total rendering time of 8 seconds...
Could it be that it is not loading my "preference" to use manifold?
OK! Yes, that's it. I tried another openscad binary on my system
without manifold and it takes on the order of 11 seconds to render
(F6) my file.
So the question is: How do I select "manifold" as the render engine on
the commandline?
Roger.
P.S. The 16 seconds of CPU time (for this project) is not what worries
me. What really worries me is that I have a bunch of projects that
generate errors with the old rendering engine. If that happens without
me noticing, I'm prone to accidentally 3D print an older
version... stuff like that.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
If you're not worried about dependencies based on include <> or use <>
in your scripts, your makefile will work okay.
For my project, I have three subdirectories:
lib/
scad/
stl/
scad/ contains the scripts that generate the individual .stl files, lib/
contains parts that make up some of the assemblies in scad/, as well a a
few libraries that include generally useful modules, and stl/ is where
the generated .stl file go. If any of the lib/ files change, I need to
re-generate the .stl files of the scad/*.scad scripts that use them, so
dependencies are a thing for me.
You can see the whole thing here:
https://github.com/butcherg/DRG_168
There's a Makefile in st/ that shows dependencies for each make target.
It's a bit outdated, but you should get the drift...
On 5/2/24 02:59, Rogier Wolff wrote:
> On Wed, May 01, 2024 at 12:41:56PM -0600, Glenn Butcher via Discuss wrote:
>> Rogier,
>>
>> Related to the title of your post, I have an OpenSCAD project of some 28
>> individual parts, same sort of need for something to keep the .stl files
>> current. I messed a bit with unix 'make', worked okay but I thought a more
>> OpenSCAD-specific tool would be nice.
>>
>> So, I wrote a make-like tool, I call it 'scadmake'. It requires a simple
>> configuration file to point to openscad and the directory with the .scad
>> files, running in a directory where the .stl files will go it will check
>> each script to see if it is newer than the corresponding .stl file and if
>> so, run openscad to make it. Just like 'make' does for computer programs,
>> but without all the targets. It also checks all of a script's dependencies
>> to do the same thing. Found here:
>>
>> https://github.com/butcherg/SCADMake
>>
>> Unfortunately, you currently have to compile the program yourself. If
>> there's interest, I can make a bit of time to compile a Windows
>> executable...
> I've been thinking about this since yesterday. if I create
> a makefile:
>
> all: foo-part1.stl foo-part2.stl
> %.stl: %.scad
> make_stl $< $@
> foo-part1.stl: foo.scad
> foo-part2.stl: foo.scad
>
> and then a script make_stl that looks in the scad for the parameter
> to make part1... then I'm all set, I think.
>
> // generate foo-part1.stl view=2
> // generate foo-part2.stl view=3
>
> is easy for a sed to manipulate into the appropriate commandline option
> for openscad. But something integrated is easy to do as well. Yeah. I'm
> going to do that.
>
> #!/bin/sh
> file=$1
> parts=`grep '// generate' $file | awk '{print $3}'
> for p in $parts ; do
> v=`sed -ne 's/generate.*'$p' //p' $file`
> openscad -o $p -D $v
> fi
>
> ^^^UNTESTED^^^
>
> but something like that should work. But first I want to use manifold
> for the STL generation. It is not good if I interactively look at one
> "interpretation" of the source and then use a different "toolset"
> to actually process it further.
>
> This is already the case where preview sometimes (mostly older
> versions of openscad) shows a valid model and hten "render" doesn't.
>
>
> The documentation in the scad is going to be:
> // list of machine readable output STLs:
> // output 1 part1
> // output 2 part2
>
> little redundant typing and the script is where the magic happens.
>
> Roger.
>
>
>> Glenn
>>
>> On 5/1/2024 10:59 AM, Rogier Wolff via Discuss wrote:
>>> Hi,
>>>
>>> I was just cosidering if maybe I should write a script that simply
>>> calls openscad with the appropriate arguments to generate all my STLs
>>> for my project.
>>>
>>> I usually work with view==1 to show the assembly and then other
>>> numbers will call all the submodules that need printint separately (or
>>> a build-plate)
>>>
>>> When I use interactive openscad, the "preview" finishes in 25 ms. in a
>>> fresh openscad. About 2 seconds realtime.
>>>
>>> Generating the mesh (F6) then takes 137ms. (using "manifold").
>>>
>>> No time delays are observed except "waiting for input from user" when
>>> I then export the STL.
>>>
>>> But when I run:
>>>
>>> time openscad -q -o esun-reel.stl -D view=2 esun-reel.scad
>>>
>>> there is a significant delay. "time" tells me 8 seconds realtime with
>>> about 96% CPU usage.
>>>
>>> Would this be unavoidable, or is there something wrong somewhere?
>>>
>>> Oh? Is it using my GPU in interactive mode, and not in commandline
>>> mode?
>>>
>>> I had copied the commandline from some stackexchange example, so I
>>> didn't know (but suspected) what -q did. I did it without,
>>> and... openscad then reports a total rendering time of 8 seconds...
>>>
>>> Could it be that it is not loading my "preference" to use manifold?
>>> OK! Yes, that's it. I tried another openscad binary on my system
>>> without manifold and it takes on the order of 11 seconds to render
>>> (F6) my file.
>>>
>>> So the question is: How do I select "manifold" as the render engine on
>>> the commandline?
>>>
>>> Roger.
>>>
>>> P.S. The 16 seconds of CPU time (for this project) is not what worries
>>> me. What really worries me is that I have a bunch of projects that
>>> generate errors with the old rendering engine. If that happens without
>>> me noticing, I'm prone to accidentally 3D print an older
>>> version... stuff like that.
>>>
>>>
>> _______________________________________________
>> OpenSCAD mailing list
>> To unsubscribe send an email to discuss-leave@lists.openscad.org
