[OpenSCAD] Evaluating imported STL's

nop head nop.head at gmail.com
Thu Jun 16 10:16:44 EDT 2016


I think querying the geometry during evaluation and the attendant slow down
is fine as long as it only happens when the user explicitly invokes it. It
is no worse than the current situation with render(). Those of us who don't
need it would still get a fast preview.

On 16 June 2016 at 14:48, doug moen <doug at moens.org> wrote:

> Roger said:
> > The thing is: What costs time? The evaluation until you get there, or
> > the "keep going"?
> >
> > Yesterday I spent an hour gathering the dependencies of a software
> > package. I would run "./configure" it would spend three minutes
> > checking for header files, and then it would say: Can't find XXXX and
> > bomb out.
> >
> > So, normally my strategy is to fix the first error (or occasionally a
> > random error) and try again. But if it works like yesterday where the
> > wait until the error occurs I'll quickly switch to fixing ALL errors
> > before I try again.
> >
> > For openSCAD as I know it, the "ignore undefined modules" strategy has
> > its merits. But a bigger "warning: ignored 3 undefined modules" would
> > IMHO be better...
>
> You raise a good point.
>
> OpenSCAD has an evaluation phase (which generates the CSG tree), then a
> rendering phase (which generates the mesh).
>
> Normally, the evaluation phase is quick (milliseconds). This is the phase
> where undefined modules are detected. Since there's normally no wait, I
> want this phase to abort on first error and highlight in the text editor
> the subexpression where the error occurred, because that would be the most
> productive way for me to fix errors. That's what works for me. If other
> people disagree, maybe this should be configurable?
>
> The rendering phase is slow, and takes minutes or hours for any serious
> model. During this phase, it would make sense to print informative error
> messages and keep going, so that you can fix all the errors in a batch.
> Unfortunately, CGAL assertion messages don't give you helpful information
> that points back at the location in the source where the error occurred.
> This is something that I think may improve in the future, based on active
> pull requests.
>
> Now, there is pressure from some parts of the community to support
> geometric evaluation during the evaluation phase. (Recently, a request for
> a boolean function to test if two shapes intersect, but there's a long
> history of similar requests.) And, there are other parts of the community
> who push back on this, and uphold the benefits of a fast evaluation phase
> and fast preview. If we do go in the direction of making OpenSCAD more
> powerful, at the expensive of long evaluation times, then the tradeoff
> changes, and maybe abort on first error starts to make less sense.
>
> The goal is to provide a productive workflow. Since we have a fully
> integrated system with our own GUI and our own evaluator, we have the
> ability to make this work very nicely. I would like the ability to jump
> into the editor at the error location the instant an error occurs so that I
> can fix the bug, regardless of whether evaluation continues past that
> point. If evaluation does continue, then a button to advance to the next
> error would be desirable.
>
> On 16 June 2016 at 00:41, Rogier Wolff <R.E.Wolff at bitwizard.nl> wrote:
>
>> On Wed, Jun 15, 2016 at 09:14:09PM -0400, doug moen wrote:
>>
>> > if C() is not defined, I want the evaluator to halt, highlight the
>> > expression C() in the editor, and display an error message, so that
>> > I can quickly fix my typo and try again. I can't get a correct
>> > result if C() is undefined, so the best thing the system can do for
>> > me is help me to correct the error as quickly as possible.
>>
>> > I don't want the system to keep going, making me wait for a bad result.
>>
>> The thing is: What costs time? The evaluation until you get there, or
>> the "keep going"?
>>
>> Yesterday I spent an hour gathering the dependencies of a software
>> package. I would run "./configure" it would spend three minutes
>> checking for header files, and then it would say: Can't find XXXX and
>> bomb out.
>>
>> So, normally my strategy is to fix the first error (or occasionally a
>> random error) and try again. But if it works like yesterday where the
>> wait until the error occurs I'll quickly switch to fixing ALL errors
>> before I try again.
>>
>> For openSCAD as I know it, the "ignore undefined modules" strategy has
>> its merits. But a bigger "warning: ignored 3 undefined modules" would
>> IMHO be better...
>>
>>         Roger.
>>
>> --
>> ** R.E.Wolff at BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998
>> **
>> **    Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233    **
>> *-- BitWizard writes Linux device drivers for any device you may have! --*
>> The plan was simple, like my brother-in-law Phil. But unlike
>> Phil, this plan just might work.
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> Discuss at lists.openscad.org
>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
>>
>>
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss at lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscad.org/pipermail/discuss_lists.openscad.org/attachments/20160616/f1e4572c/attachment-0002.html>


More information about the Discuss mailing list