Question about Debug Modifier (#)
I really like the transparency that comes with the Debug Modifier (#) but I'm
not sure I understand what determines its behavior. Some objects are
rendered in transparent pink, others are not. I couldn't find anything in
the documentation that explains what factors are at work.
If there's some other way of achieving transparency - so that I can see an
object inside an object - please share it with me. I tried using the
transparency argument in color() but that didn't work.
Thanks!
--
View this message in context: http://forum.openscad.org/Question-about-Debug-Modifier-tp14384.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Hi!
Use alpha
color
Displays the child elements using the specified RGB color + alpha
value. This is only used for the F5 preview as CGAL and STL (F6) do not
currently support color. The alpha value will default to 1.0 (opaque)
if not specified.
https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/The_OpenSCAD_Language
section color
Peter
Am Wed, 11 Nov 2015 20:26:49 -0700 (MST)
schrieb Mekko serve@perdix.org:
I really like the transparency that comes with the Debug Modifier (#)
but I'm not sure I understand what determines its behavior. Some
objects are rendered in transparent pink, others are not. I couldn't
find anything in the documentation that explains what factors are at
work.
If there's some other way of achieving transparency - so that I can
see an object inside an object - please share it with me. I tried
using the transparency argument in color() but that didn't work.
Thanks!
--
View this message in context:
http://forum.openscad.org/Question-about-Debug-Modifier-tp14384.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
--
Mit freundlichen Grüßen
Kind Regards
Peter Ragosch
Also, if you want to see objects behind a transparent one you have to draw
them first.
On 12 November 2015 at 09:16, Peter Ragosch peter.ragosch@kabelmail.de
wrote:
Hi!
Use alpha
color
Displays the child elements using the specified RGB color + alpha
value. This is only used for the F5 preview as CGAL and STL (F6) do not
currently support color. The alpha value will default to 1.0 (opaque)
if not specified.
https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/The_OpenSCAD_Language
section color
Peter
Am Wed, 11 Nov 2015 20:26:49 -0700 (MST)
schrieb Mekko serve@perdix.org:
I really like the transparency that comes with the Debug Modifier (#)
but I'm not sure I understand what determines its behavior. Some
objects are rendered in transparent pink, others are not. I couldn't
find anything in the documentation that explains what factors are at
work.
If there's some other way of achieving transparency - so that I can
see an object inside an object - please share it with me. I tried
using the transparency argument in color() but that didn't work.
Thanks!
--
View this message in context:
http://forum.openscad.org/Question-about-Debug-Modifier-tp14384.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
--
Mit freundlichen Grüßen
Kind Regards
Peter Ragosch
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
This example shows that the order of operation matters as nophead pointed
out.
This holds for the debug modifier (#) as well as for the transparancy value
(alpha channel) of color():
//color(.5*[1,1,1,1])
#translate([-10,0,0])
cube([10,2,10]);
translate([-10,2,0])
cube([20,2,10]);
//color(.5*[1,1,1,1])
#cube([10,2,10]);
--
View this message in context: http://forum.openscad.org/Question-about-Debug-Modifier-tp14384p14398.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Well, I wasn't aware of this behavior.
Someone who is familiar with openSuSE manual editing should ad it there.
vicnet, may I please you to add it to your agenda?
Many thanks in advance.
Kind regards
Peter
Am Thu, 12 Nov 2015 02:49:55 -0700 (MST)
schrieb herdima martin.Herdieckerhoff@mnet-mail.de:
This example shows that the order of operation matters as nophead
pointed out.
This holds for the debug modifier (#) as well as for the transparancy
value (alpha channel) of color():
//color(.5*[1,1,1,1])
#translate([-10,0,0])
cube([10,2,10]);
translate([-10,2,0])
cube([20,2,10]);
//color(.5*[1,1,1,1])
#cube([10,2,10]);
--
View this message in context:
http://forum.openscad.org/Question-about-Debug-Modifier-tp14384p14398.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
--
Mit freundlichen Grüßen
Kind Regards
Peter Ragosch
Am I right that the F5 renderer optimisation routine takes no care about
the colour/transparency of an object in the foreground and therefore
doesn't render the covered object, if it comes first in code?
Am Thu, 12 Nov 2015 02:49:55 -0700 (MST)
schrieb herdima martin.Herdieckerhoff@mnet-mail.de:
This example shows that the order of operation matters as nophead
pointed out.
This holds for the debug modifier (#) as well as for the transparancy
value (alpha channel) of color():
//color(.5*[1,1,1,1])
#translate([-10,0,0])
cube([10,2,10]);
translate([-10,2,0])
cube([20,2,10]);
//color(.5*[1,1,1,1])
#cube([10,2,10]);
--
View this message in context:
http://forum.openscad.org/Question-about-Debug-Modifier-tp14384p14398.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
--
Mit freundlichen Grüßen
Kind Regards
Peter Ragosch
On Nov 12, 2015, at 05:32 AM, Peter Ragosch peter.ragosch@kabelmail.de wrote:
Am I right that the F5 renderer optimisation routine takes no care about
the colour/transparency of an object in the foreground and therefore
doesn't render the covered object, if it comes first in code?
Yes, that’s how it currently works. We haven’t focused on fixing such rendering issues, as the larger task is to move the rendering code to a real framework: https://github.com/openscad/openscad/wiki/Project%3A-Improve-OpenGL-rendering
-Marius
Thanks for all the comments. My take-away is that the order of operations
matter but I'm still unclear how. The code example that nophead offered
seems to preview exactly as I would expect.
Here's a trivialized example of the behavior that is confusing me: This code
lights up in transparent red (which is what I want):
#difference() {
union() {
cube(size=[30, 30, 35]);
//cube(size=[5,5,40]);
}
translate(v=[-10, -10, 10]) cube(size=[20, 20, 20]);
}
and this does not (which is what is confusing me):
#difference() {
union() {
cube(size=[30, 30, 35]);
cube(size=[5,5,40]);
}
translate(v=[-10, -10, 10]) cube(size=[20, 20, 20]);
}
Thanks!
--
View this message in context: http://forum.openscad.org/Question-about-Debug-Modifier-tp14384p14416.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
On Nov 12, 2015, at 14:46 PM, Mekko serve@perdix.org wrote:
and this does not (which is what is confusing me):
[…]
humm, that might be considered a bug.
-Marius
Looks like a strange bug to me. If I put render() between # and
difference() it works.
On 12 November 2015 at 19:46, Mekko serve@perdix.org wrote:
Thanks for all the comments. My take-away is that the order of operations
matter but I'm still unclear how. The code example that nophead offered
seems to preview exactly as I would expect.
Here's a trivialized example of the behavior that is confusing me: This
code
lights up in transparent red (which is what I want):
#difference() {
union() {
cube(size=[30, 30, 35]);
//cube(size=[5,5,40]);
}
translate(v=[-10, -10, 10]) cube(size=[20, 20, 20]);
}
and this does not (which is what is confusing me):
#difference() {
union() {
cube(size=[30, 30, 35]);
cube(size=[5,5,40]);
}
translate(v=[-10, -10, 10]) cube(size=[20, 20, 20]);
}
Thanks!
--
View this message in context:
http://forum.openscad.org/Question-about-Debug-Modifier-tp14384p14416.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