I would like to know if there is some way to detect if doing a render so that I can ensure that I remove excess debugging crap. Is this possible? -- View this message in context: http://forum.openscad.org/Is-there-a-way-to-determine-if-doing-a-render-as-opposed-to-a-preview-tp20588.html Sent from the OpenSCAD mailing list archive at Nabble.com.

Well $preview will be false when you press F6, so if your debugging stuff is only to be shown in the preview then you can put put if($preview) around it if my PR is accepted. On 26 February 2017 at 16:52, adrian <adrianh.bsc@gmail.com> wrote: > I would like to know if there is some way to detect if doing a render so > that > I can ensure that I remove excess debugging crap. > > Is this possible? > > > > -- > View this message in context: http://forum.openscad.org/Is- > there-a-way-to-determine-if-doing-a-render-as-opposed-to- > a-preview-tp20588.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 >

Also anything preceded with % is only shown in the preview and doesn't take part in geometrical operations. On 26 February 2017 at 16:56, nop head <nop.head@gmail.com> wrote: > Well $preview will be false when you press F6, so if your debugging stuff > is only to be shown in the preview then you can put put if($preview) around > it if my PR is accepted. > > > > On 26 February 2017 at 16:52, adrian <adrianh.bsc@gmail.com> wrote: > >> I would like to know if there is some way to detect if doing a render so >> that >> I can ensure that I remove excess debugging crap. >> >> Is this possible? >> >> >> >> -- >> View this message in context: http://forum.openscad.org/Is-t >> here-a-way-to-determine-if-doing-a-render-as-opposed-to-a- >> preview-tp20588.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 >> > >

Excellent nophead, I like the $preview. The % isn't useful for me because the debugging process mostly requires cutting out chunks so I can see what's underneath. I do use the transparency, but if an inner object is specified after the outer object, the inner object isn't visible, which is annoying. Would also be nice if one could modify the colour of an object as opposed to only being able to specify it. Something like: color([0,0.5,0.5,.4], [ignore, increase, decrease, set]) The 2nd array are numerical symbolic constants which would state how the first RGBA array is applied, where: *p* - previous value specified in the RGBA element defined closer to the leaf node. *c* - current value specified in the RGBA array element of the function call. *ignore* - ignores value specified. Results in /p/. *increase* - increases the value specified. Results in /p+(1-p)*c/. *decrease* - decreases the value specified. Results in /p*c/. *set* - sets the value specified (default). Results in /c/. -- View this message in context: http://forum.openscad.org/Is-there-a-way-to-determine-if-doing-a-render-as-opposed-to-a-preview-tp20588p20595.html Sent from the OpenSCAD mailing list archive at Nabble.com.

Adrian, re your proposal for modifying colours: *increase* - increases the value specified. Results in *p+(1-p)*c*. *decrease* - decreases the value specified. Results in *p*c*. I wouldn't be very happy with this limited interface, because working directly in the RGB space for tweaking colour values isn't very intuitive. I'd rather work with HSV (https://en.wikipedia.org/wiki/HSL_and_HSV), and add or subtract offsets from each of the HSV coordinates: H=hue, S=saturation (distance from white), V=value (distance from black, aka brightness). On 26 February 2017 at 12:44, adrian <adrianh.bsc@gmail.com> wrote: > Excellent nophead, > > I like the $preview. The % isn't useful for me because the debugging > process mostly requires cutting out chunks so I can see what's underneath. > > I do use the transparency, but if an inner object is specified after the > outer object, the inner object isn't visible, which is annoying. > > Would also be nice if one could modify the colour of an object as opposed > to only being able to specify it. Something like: > > color([0,0.5,0.5,.4], [ignore, increase, decrease, set]) > > The 2nd array are numerical symbolic constants which would state how the > first RGBA array is applied, where: > > *p* - previous value specified in the RGBA element defined closer to the > leaf node. > > *c* - current value specified in the RGBA array element of the function > call. > > *ignore* - ignores value specified. Results in *p*. > > *increase* - increases the value specified. Results in *p+(1-p)*c*. > > *decrease* - decreases the value specified. Results in *p*c*. > > *set* - sets the value specified (default). Results in *c*. > > ------------------------------ > View this message in context: Re: Is there a way to determine if doing a > render as opposed to a preview? > <http://forum.openscad.org/Is-there-a-way-to-determine-if-doing-a-render-as-opposed-to-a-preview-tp20588p20595.html> > > Sent from the OpenSCAD mailing list archive <http://forum.openscad.org/> > at Nabble.com. > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > >

I don't quite understand what Adrian is trying to do, but can it be done with a user module that sets the colour and also sets dynamic variables that affect lower instances of itself in the tree? On 26 February 2017 at 18:10, doug moen <doug@moens.org> wrote: > Adrian, re your proposal for modifying colours: > > *increase* - increases the value specified. Results in *p+(1-p)*c*. > > *decrease* - decreases the value specified. Results in *p*c*. > I wouldn't be very happy with this limited interface, because working > directly in the RGB space for tweaking colour values isn't very intuitive. > I'd rather work with HSV (https://en.wikipedia.org/wiki/HSL_and_HSV), and > add or subtract offsets from each of the HSV coordinates: H=hue, > S=saturation (distance from white), V=value (distance from black, aka > brightness). > > On 26 February 2017 at 12:44, adrian <adrianh.bsc@gmail.com> wrote: > >> Excellent nophead, >> >> I like the $preview. The % isn't useful for me because the debugging >> process mostly requires cutting out chunks so I can see what's underneath. >> >> I do use the transparency, but if an inner object is specified after the >> outer object, the inner object isn't visible, which is annoying. >> >> Would also be nice if one could modify the colour of an object as opposed >> to only being able to specify it. Something like: >> >> color([0,0.5,0.5,.4], [ignore, increase, decrease, set]) >> >> The 2nd array are numerical symbolic constants which would state how the >> first RGBA array is applied, where: >> >> *p* - previous value specified in the RGBA element defined closer to the >> leaf node. >> >> *c* - current value specified in the RGBA array element of the function >> call. >> >> *ignore* - ignores value specified. Results in *p*. >> >> *increase* - increases the value specified. Results in *p+(1-p)*c*. >> >> *decrease* - decreases the value specified. Results in *p*c*. >> >> *set* - sets the value specified (default). Results in *c*. >> >> ------------------------------ >> View this message in context: Re: Is there a way to determine if doing a >> render as opposed to a preview? >> <http://forum.openscad.org/Is-there-a-way-to-determine-if-doing-a-render-as-opposed-to-a-preview-tp20588p20595.html> >> >> Sent from the OpenSCAD mailing list archive <http://forum.openscad.org/> >> at Nabble.com. >> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> >> > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > >

Nop head: I have no experience with the style of programming you mention, but based on your previous description of it, I think you are right that Adrian's colour manipulation operator could be done in user space. As long as you don't use built in colour strings like "red" and "blue". On 26 February 2017 at 13:26, nop head <nop.head@gmail.com> wrote: > I don't quite understand what Adrian is trying to do, but can it be done > with a user module that sets the colour and also sets dynamic variables > that affect lower instances of itself in the tree? > > On 26 February 2017 at 18:10, doug moen <doug@moens.org> wrote: > >> Adrian, re your proposal for modifying colours: >> >> *increase* - increases the value specified. Results in *p+(1-p)*c*. >> >> *decrease* - decreases the value specified. Results in *p*c*. >> I wouldn't be very happy with this limited interface, because working >> directly in the RGB space for tweaking colour values isn't very intuitive. >> I'd rather work with HSV (https://en.wikipedia.org/wiki/HSL_and_HSV), >> and add or subtract offsets from each of the HSV coordinates: H=hue, >> S=saturation (distance from white), V=value (distance from black, aka >> brightness). >> >> On 26 February 2017 at 12:44, adrian <adrianh.bsc@gmail.com> wrote: >> >>> Excellent nophead, >>> >>> I like the $preview. The % isn't useful for me because the debugging >>> process mostly requires cutting out chunks so I can see what's underneath. >>> >>> I do use the transparency, but if an inner object is specified after the >>> outer object, the inner object isn't visible, which is annoying. >>> >>> Would also be nice if one could modify the colour of an object as >>> opposed to only being able to specify it. Something like: >>> >>> color([0,0.5,0.5,.4], [ignore, increase, decrease, set]) >>> >>> The 2nd array are numerical symbolic constants which would state how the >>> first RGBA array is applied, where: >>> >>> *p* - previous value specified in the RGBA element defined closer to >>> the leaf node. >>> >>> *c* - current value specified in the RGBA array element of the function >>> call. >>> >>> *ignore* - ignores value specified. Results in *p*. >>> >>> *increase* - increases the value specified. Results in *p+(1-p)*c*. >>> >>> *decrease* - decreases the value specified. Results in *p*c*. >>> >>> *set* - sets the value specified (default). Results in *c*. >>> >>> ------------------------------ >>> View this message in context: Re: Is there a way to determine if doing >>> a render as opposed to a preview? >>> <http://forum.openscad.org/Is-there-a-way-to-determine-if-doing-a-render-as-opposed-to-a-preview-tp20588p20595.html> >>> >>> Sent from the OpenSCAD mailing list archive <http://forum.openscad.org/> >>> at Nabble.com. >>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> Discuss@lists.openscad.org >>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>> >>> >> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> >> > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > >

nophead wrote > I don't quite understand what Adrian is trying to do, but can it be > donewith a user module that sets the colour and also sets dynamic > variablesthat affect lower instances of itself in the tree? No, wrong direction. Say I have the following: module foo(){ color([1,0,0,.5]) sphere(r=10); translate([10,0,0]) color([0,1,0,.25]) sphere(r=10);} Now I want to modify only the alpha channel in foo() so that it is all set to 100% color([0,0,0,1], [ignore, ignore, ignore, set]) foo(); If I want increase the alpha value (make it 50% less transparent): color([0,0,0,.50], [ignore, ignore, ignore, increase]) foo(); If I want decrease the alpha value (make it 50% more transparent): color([0,0,0,.50], [ignore, ignore, ignore, decrease]) foo(); doug.moen wrote > I wouldn't be very happy with this limited interface, That's fine, then add another module operator colorHSV() for that -- View this message in context: http://forum.openscad.org/Is-there-a-way-to-determine-if-doing-a-render-as-opposed-to-a-preview-tp20588p20600.html Sent from the OpenSCAD mailing list archive at Nabble.com.

Another really useful modifier when debugging is the ! Operator. It allows you to display only one part of the model. This helps when designing internals that are obscured in the final design. You can also place it between the transforms and the model to get an untransformed section of the design which helps a lot when trying to work out things like placing holes in a subassembly that has been translated and rotated a few times. It's also really helpful when exploring someone else's design to understand how it is built up. Sent from my iPhone > On 27 Feb 2017, at 4:56 am, nop head <nop.head@gmail.com> wrote: > > I don't quite understand what Adrian is trying to do, but can it be done with a user module that sets the colour and also sets dynamic variables that affect lower instances of itself in the tree? > >> On 26 February 2017 at 18:10, doug moen <doug@moens.org> wrote: >> Adrian, re your proposal for modifying colours: >> increase - increases the value specified. Results in p+(1-p)*c. >> >> decrease - decreases the value specified. Results in p*c. >> >> I wouldn't be very happy with this limited interface, because working directly in the RGB space for tweaking colour values isn't very intuitive. I'd rather work with HSV (https://en.wikipedia.org/wiki/HSL_and_HSV), and add or subtract offsets from each of the HSV coordinates: H=hue, S=saturation (distance from white), V=value (distance from black, aka brightness). >> >>> On 26 February 2017 at 12:44, adrian <adrianh.bsc@gmail.com> wrote: >>> Excellent nophead, >>> >>> I like the $preview. The % isn't useful for me because the debugging process mostly requires cutting out chunks so I can see what's underneath. >>> >>> I do use the transparency, but if an inner object is specified after the outer object, the inner object isn't visible, which is annoying. >>> >>> Would also be nice if one could modify the colour of an object as opposed to only being able to specify it. Something like: >>> >>> color([0,0.5,0.5,.4], [ignore, increase, decrease, set]) >>> The 2nd array are numerical symbolic constants which would state how the first RGBA array is applied, where: >>> >>> p - previous value specified in the RGBA element defined closer to the leaf node. >>> >>> c - current value specified in the RGBA array element of the function call. >>> >>> ignore - ignores value specified. Results in p. >>> >>> increase - increases the value specified. Results in p+(1-p)*c. >>> >>> decrease - decreases the value specified. Results in p*c. >>> >>> set - sets the value specified (default). Results in c. >>> >>> >>> View this message in context: Re: Is there a way to determine if doing a render as opposed to a preview? >>> >>> 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 >>> >> >> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

adrian wrote > No, wrong direction. You seem to want a module higher in the tree to affect a module lower in the tree. The is the right direction for dynamic scope variables. They are visible to all the lower modules in the tree, i.e. nearer and including the leaves. So instead of using color in foo you use a module that gets information from higher in tree to set the colour. -- View this message in context: http://forum.openscad.org/Is-there-a-way-to-determine-if-doing-a-render-as-opposed-to-a-preview-tp20588p20602.html Sent from the OpenSCAD mailing list archive at Nabble.com.