Is there a way to determine if doing a render as opposed to a preview?

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Is there a way to determine if doing a render as opposed to a preview?

adrian
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?
Reply | Threaded
Open this post in threaded view
|

Re: Is there a way to determine if doing a render as opposed to a preview?

nophead
This post was updated on .
See https://github.com/openscad/openscad/pull/1963

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
>

_______________________________________________
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Is there a way to determine if doing a render as opposed to a preview?

nophead
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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Is there a way to determine if doing a render as opposed to a preview?

adrian

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.

Reply | Threaded
Open this post in threaded view
|

Re: Is there a way to determine if doing a render as opposed to a preview?

doug.moen
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 <[hidden email]> 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Is there a way to determine if doing a render as opposed to a preview?

nophead
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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Is there a way to determine if doing a render as opposed to a preview?

doug.moen
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Is there a way to determine if doing a render as opposed to a preview?

adrian
In reply to this post by nophead
nophead 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?

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

Reply | Threaded
Open this post in threaded view
|

Re: Is there a way to determine if doing a render as opposed to a preview?

Greg Frost
In reply to this post by nophead
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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?
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Is there a way to determine if doing a render as opposed to a preview?

nophead
This post was updated on .
In reply to this post by adrian
adrian wrote
No, wrong direction.
You seem to want a module higher in the tree to affect a module lower in the tree. That 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.
Reply | Threaded
Open this post in threaded view
|

Re: Is there a way to determine if doing a render as opposed to a preview?

adrian
nophead wrote
adrian wrote
No, wrong direction.
You seem to want a module higher in the tree to affect a module lower in the tree. That 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.
Oh, you're right, but you can't modify based on the previous value, you can only override th value.  So, given the example I suggested, I can set, but not increase or decrease.  Or perhaps I could but not in a scalable way.

Reply | Threaded
Open this post in threaded view
|

Re: Is there a way to determine if doing a render as opposed to a preview?

adrian
In reply to this post by Greg Frost
Thanks Greg,

Forgot about that operator.  Still, I need the context, so not exactly what I'm looking for.
Reply | Threaded
Open this post in threaded view
|

Re: Is there a way to determine if doing a render as opposed to a preview?

nophead
I don't see why you can't do exactly what you want as you can pass as much down the tree as you want, but without coding it myself I can't be sure.

On 26 February 2017 at 20:15, adrian <[hidden email]> wrote:
Thanks Greg,

Forgot about that operator.  Still, I need the context, so not exactly what
I'm looking for.



--
View this message in context: http://forum.openscad.org/Is-there-a-way-to-determine-if-doing-a-render-as-opposed-to-a-preview-tp20588p20605.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Is there a way to determine if doing a render as opposed to a preview?

adrian

Hi nophead,

Try doing it with the example that I posted above:

module foo()
{
  color([1,0,0,.5])
    sphere(r=10);
  translate([10,0,0])
    color([0,1,0,.25])
      sphere(r=10);
}