Auto reload and preview behaviour?
Would one of you please provide an example of where to put this render()?
Thanks
Jon
On 12/13/2020 12:37 PM, Troberg wrote:
nophead wrote
It seems that a nested difference explodes in OpenCSG complexity. The
simple solution is to add a render because GCAL doesn't find it too
difficult and of course doing it in 2D is much faster.
Yep, that is usually my problem. I add a seemingly harmless difference, and
it locks up. Adding a render solves it.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
jon_bondy wrote
Would one of you please provide an example of where to put this render()?
Right before the last working operation.
So, for example:
difference(){ //no longer fails
difference(){ //works
myobject();
myotherobject();
}
difference(){ //works
myspecialobject();
myveryspecialobject();
}
}
I would change this to:
difference(){ //fails
render()
difference(){ //works
myobject();
myotherobject();
}
render()
difference(){ //works
myspecialobject();
myveryspecialobject();
}
}
Think of it like this (simplified...): Difference retains the original
geometries and the added "cut boundaries". This can get too much when you
stack enough differences on complex objects. Render kind of removes
everything that is not needed, and creates an optimized geometry which
contains only what's needed for the result, without any "history" geometry.
This is much simpler, and thus doesn't get too much for the next difference.
--
Sent from: http://forum.openscad.org/
Normaly the os catches them and raises a seg fault signal against the
process, cant openscad trap the signal, show a diagnostic, and jump to the
outer loop with a modal dialog that has a quit/contine option, continue
reentering the command loop/listenrer/dispatcher?
On Sun, 13 Dec 2020, 18:54 Hans L, thehans@gmail.com wrote:
It already does if i remember correctly. Try/catch just doesn't help for
a null pointer dereference.
Anyways I feel like crashes are fairly rare(particularly once a stable
release is finalized), and usually very promptly fixed once identified.
The crash above was fixed within a day.
So I'm not sure it's worth the effort to add special handling of crashes
as a new feature.
On Sun, Dec 13, 2020 at 3:06 AM Tim Hawkins tim.thawkins@gmail.com
wrote:
Can the whole rendering process not be run in a try/catch block and have
a message box show a suitable error message if an exception is thrown. That
way if rendering fails it does not blow out the app.
On Sun, Dec 13, 2020, 16:22 Troberg troberg.anders@gmail.com wrote:
I agree.
Also, it would be nice if it detected a previous crash, and offered to
open
the backup file, without trying to rendering it, on the next start.
Now, I'll have to open it in another editor, fix the error, open an empty
project, paste the edited version and save as over the original. Not that
hard, but a chain of steps that can be effed up badly if you don't pay
attention.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Tim Hawkins wrote
Normaly the os catches them and raises a seg fault signal against the
process, cant openscad trap the signal, show a diagnostic, and jump to
the
outer loop
Often crashes leave the process in an indeterminate state, particularly
memory.
OpenSCAD Admin - email* me if you need anything, or if I've done something stupid...
- on the Forum, click on my MichaelAtOz label, there is a link to email me.
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.
--
Sent from: http://forum.openscad.org/