I agree that this would be a useful tool to have. It would mean we could
code a "visual representation" (F5), and a "layout for 3D printing" that is
automatically generated on F6.
--
View this message in context: http://forum.openscad.org/Variable-for-render-mode-tp5340p15580.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Yes that is exactly how I would use it.
When I press F5 I want this
And when I press F6 I want this
... without having to modify the file and remember to put it restore it
when I check it in. Accidentally pressing F6 with the assembly view
selected can bring my PC to its knees if it is a complicated assembly.
Novice uses trying to build Mendel90 often make this mistake.
On 9 January 2016 at 03:03, shadowwynd shadowwynd@gmail.com wrote:
I agree that this would be a useful tool to have. It would mean we could
code a "visual representation" (F5), and a "layout for 3D printing" that is
automatically generated on F6.
--
View this message in context:
http://forum.openscad.org/Variable-for-render-mode-tp5340p15580.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
There's a by now quite old github issue for that:
https://github.com/openscad/openscad/issues/149
tp3 wrote
There's a by now quite old github issue for that:
https://github.com/openscad/openscad/issues/149
Surprising it hasn't been tackled as it has a $100 bounty.
Newly minted Admin - PM me if you need anything, or if I've done something stupid...
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
View this message in context: http://forum.openscad.org/Variable-for-render-mode-tp5340p15598.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Oh, that was nophead, just now...
Newly minted Admin - PM me if you need anything, or if I've done something stupid...
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
View this message in context: http://forum.openscad.org/Variable-for-render-mode-tp5340p15599.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
On 01/09/2016 11:45 PM, MichaelAtOz wrote:
Oh, that was nophead, just now...
Yep, actually I wanted to do that some time ago, but after discussion
with Marius it turned out, it might not be as easy as it sounds.
The feature itself is clear and very useful, but main concern was
the internal caching I think.
I'm still not sure we'll run into issues with a fixed value for each
new evaluation (except maybe using more cache memory, but that would
not be much different from just changing the value manually). I guess
we'll find out, hopefully soon :-).
Any ideas how to name it? I think it would make sense to
a) not introduce more $ variables as this also makes no sense for
a fixed value
b) maybe have something like ENV.something that can then be extended
for similar things like access to some system information as
requested in other issues.
ciao,
Torsten.
I'd go with a built-in function,
var = system("render"); // boolean - in this case
Initial set of options;
"preview" boolean
"render" boolean
"mainfilename" string
"datetime" string, YYYYMMDDHHMMSSmmd, mm=millisec, d=0-6 (day of week)
"GUI" boolean - false if command line
I was going to suggest the following, but that is too late, the compiling
has been done. Unless an auto-rerender concept...??
"export" [ returns the export type,
"STL","OFF","AMF","DXF","SVG","CSG","PNG"]
Note other discussion here
https://github.com/openscad/openscad/issues/907 , some idiot ;)
suggested;
openscad.isRender()
openscad.isPreview()
and later...
env.platform()
env.date()
So perhaps
var=openscad.system(as per above);
You don't need a separate env
Newly minted Admin - PM me if you need anything, or if I've done something stupid...
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
View this message in context: http://forum.openscad.org/Variable-for-render-mode-tp5340p15604.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
It could also be used to deprecate $vpr etc.
Newly minted Admin - PM me if you need anything, or if I've done something stupid...
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
View this message in context: http://forum.openscad.org/Variable-for-render-mode-tp5340p15606.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Not sure how caching is a problem. I currently have if(0) ... else ... that
I manually change to if(1) when I switch from F6 to F5. How is automating
that so if can do if(preview()) going to affect the cache or cause any
other problems? It is just automating what I have to do manually.
If I changed $fn on the state then it might use more cache, but again it is
only automating what some people do manually.
I don't care what sort of variable it is communicated with as I can just
wrap it in my own function called preview(). It seems odd to start
inventing new syntax for such a simple feature. That seems to be why it has
never been implemented. I can't see why another $variable or built in
function is a bad thing. Especially as user variables and functions
override built in ones, so even if someone uses the same name it gets
overridden.
The same applies to my proposal for export, it just automates what people
do manually, with ! and * and the export menu.
On 9 January 2016 at 22:53, Torsten Paul Torsten.Paul@gmx.de wrote:
On 01/09/2016 11:45 PM, MichaelAtOz wrote:
Oh, that was nophead, just now...
Yep, actually I wanted to do that some time ago, but after discussion
with Marius it turned out, it might not be as easy as it sounds.
The feature itself is clear and very useful, but main concern was
the internal caching I think.
I'm still not sure we'll run into issues with a fixed value for each
new evaluation (except maybe using more cache memory, but that would
not be much different from just changing the value manually). I guess
we'll find out, hopefully soon :-).
Any ideas how to name it? I think it would make sense to
a) not introduce more $ variables as this also makes no sense for
a fixed value
b) maybe have something like ENV.something that can then be extended
for similar things like access to some system information as
requested in other issues.
ciao,
Torsten.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 01/10/2016 12:57 AM, MichaelAtOz wrote:
Note other discussion here
https://github.com/openscad/openscad/issues/907 , some idiot ;)
suggested;
Oi, someone reading the Debian bugtracker? ;-)
Right, that openscad.isRender() vs. env.platform()
was mainly to have some kind of logical grouping.
It's not strictly needed.
On 01/10/2016 01:12 AM, nop head wrote:
I can't see why another $variable or built in function is
a bad thing. Especially as user variables and functions
override built in ones, so even if someone uses the same
name it gets overridden.
For just one, that probably does not matter too much, but
there's lots of more stuff requested. Having like 20
global $variables for various stuff that could even
be overwritten in user assignments clutters the global
namespace quite a bit.
Having constants as $ variable also seems quite strange
in itself.
Also the dot notation is existing already (even if it's
just for some obscure special case) and that's the proposed
style for a possible OpenSCAD future.
The function notation might work too. This could automatically
clarify the values are just returned and can't be overwritten
and maybe even allow additional parameters like a format
string for the date.
I think it makes sense to think about the style that
will allow implementing the other issues in the same
way, even if this specific issue will just add one
small part.
ciao,
Torsten.