Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Clarify and possibly slightly redefine the % and # operators #304

Closed
MichaelAtOz opened this Issue · 30 comments

6 participants

Michael Marius Kintel TakeItAndRun Peter Uithoven donbright Chris
Michael

For both debugging, and graphical documentation (for example showing a build platform under an object, or showing a part which the current object is mounted to [see image], or even text), it would be handy to have non-rendered objects display in multiple different colours.

OpenSCAD color eg

I had hoped color("red",0.25) %cube(10); or %color("red",0.25) cube(10); would have worked, but it is still grey.

Overriding % where color() is routinely used could make debugging more of a hassle, so perhaps allowing override only when specifically applied to color(), e.g

color("green") 
    translate([10,0,0]) 
        rotate([45,0,0])
           %cube(5);    // this is not rendered & grey as usual for debug
%color("green")       // this subtree is not rendered but is displayed in green not grey
    translate([10,0,0]) 
        rotate([45,0,0])
            cube(5);

For %color() a default Alpha, where not specified, of whatever the % Grey Alpha is, would be handy, save typing and it would be a visual reminder that the non-rendered object doesn't exist.

Alternatively another modifier or command that causes non-rendering, but does not change color??

Marius Kintel
Owner

I'm not sure if color() %cube() should be difference from %color() cube.
Both are background objects and both have color, so it would make sense that they give similar results.

Suggestions:

  • The background operator sets the transparency to half of the object color transparency
  • The default color if none given will be 50% gray

What about the highlight operator?

Michael

Your suggestions would meet my needs, but I would not override a transparency already applied.

%color("green",0.2) cube(5); // would stay 0.2 transparent (v's 50% of the existing 20%)
%color("green") cube(5);  // would be 0.5 transparent

But if it is easier, I could live with 50% of existing transparency.

Unless it is programatically difficult to distinguish the absence of transparency, with transparency=1, I would even allow

%color("green",1) cube(5); // object does not render in the model, but looks like a solid
%color("green") cube(5); // object does not render and is 50% transparent

I can see cases where the background object graphically looking 'solid' would be handy. In my image above, the grey thing is the leg of a power-tool mounting table, in reality it is black painted metal so color("black",1) would make it a better graphical rendition.

By highlight, I assume you mean the Debug Modifier '#', given its intended use I can't see any reason to change it, so it should override any color() as it does now. Unless you want to get fancy and somehow merge the colors or make a hatched pattern. CORRECTION - I just did a test

color("green")
    translate([0,7,0])
        cube4();
color("blue",0.8)
    translate([0,14,0])
        cube4();

module cube4() {
    cube(5);
    translate([7,0,0]) {
        #cube(5);
        translate([7,0,0]) {
            %cube(5);
            translate([7,0,0]) 
                %#cube(5);
        }
    }
}

produces
scad color highlights
So it (#) is doing something.
Interestingly the wiki says "also draw it unmodified in transparent pink" which it is not doing (at least on Win).

I'm sure others may have a view, but I think the wiki intent would be handy for debugging v's the current unpredictable color effects.

Michael

Perhaps my other suggestion, re another modifier character e.g. '&' that does not render, but doesn't fiddle with transparency or colour. Thus existing users won't be impacted by changes as described above.

color("blue",0.5) &cube(5);
Marius Kintel
Owner

Perhaps it's time to redefine or clarify the meaning of those two operators. I'm a bit unsure myself what the original intention was vs. how they're being used in practise.

I guess the % modifier is good for things which are only visible in preview mode. If that's the intended use, there might not be any need to modify transparency at all if the object in question has an explicit color. How to distinguish between explicit color and unique color is a valid question though.

The # modifier is good for highlighting object, both positive and negative. The main purpose is to easily locate objects for debugging purposes. Perhaps something more intense than "pink" would make sense, as well as clarify all the special cases wrt. transparency and such.

I don't think adding another modifier makes a lot of sense - it's hard enough to remember the difference between % and # as it is :/

So, without thinking about historic use, do you have any ideas how to define the function of these operators in a clear way?
Perhaps we should take this discussion to the mailing list next..

Michael

There are two issues from my perspective. Being able to graphically document/context an object without the extraneous items being rendered into the final output object (without having to use debug=1/if (debug)... constructs); and using modifiers for debugging.

The first became an issue because the only way to have a background object (%), also changes its colour/transparency. However changing this would make % less useful for debugging.

The way I use # is like you, # to highlight an element in the mess of all the others. I tend to use % to make an element temporarily transparent so I can see other elements around it. So if # also made the element transparent, it could reduce the need for % in this context. However sometimes I use % as a second type of #, ie so I can visually flag two elements, but that is just because I can. I'm sure others have their own methods.

Technically the problem is that % has two functions, which in a language will always cause issues when someone only want one of the functions. So from a purist approach, having a separate mechanism to flag an element as non-rendered would be the best, and then % can be left as-is for debugging.

Then there is the non-purist approach to workaround the issue, by doing the explicit colour thing, ie if the element is the default color() {& alpha=1}, then do 50% grey, else do nothing but flag as non-rendered. The complexity of determining explicitness could be tricky. Someone will no doubt want to have a non-rendered item in the same colour as the default, which depending in the method of determining explicitness could be handled, or not.

So in summary;

  • making # transparent, could reduce the need for % to be transparent, % could then just be used to flag as non-rendered, so color() would be unaffected.
  • or use another flag, '&' or maybe render(false), so # and % can retain existing debug uses.
  • alternatively, use the explicit colour test.

A final thought, possibly have a special variable, $highlightpercent with some parameters for options, e.g. true (default - as is), false (don't change colour/alpha), [r,g,b,a] (custom color setting), "green",0.5 (custom color - other type). Could also do a $highlighthash similarly. This is the other type of workaround - modify the meaning of the language ;)

I'm not on the mailing list, but I suspect others there will have entrenched views that they would want to express.

Marius Kintel
Owner

Also, Using the % operator on the only object in the scene currently renders nothing. It would make sense to render the object in that case.

Michael

Also, Using the % operator on the only object in the scene currently renders nothing. It would make sense to render the object in that case.

Purely as a convenience measure for debugging, I agree, even though it is non-purist.

TakeItAndRun
Michael

Also note that # and % are documented elsewhere too

e.g.

You can use %(the Background Modifier) to ignore the subtree for the normal rendering process and draw it in transparent gray. In other words to ghost an object.

So too radical a change wouldn't be good.

Marius Kintel
Owner

None of the changes suggested are really radical. Also, tutorials reflect a certain version of the program, and naturally need to be updated as the world around them changes :)

I'm less concerned about breaking GUI compatibility as I am breaking parsing and export compatibility.

Marius Kintel
Owner

Suggestion:
o Make sure a model with a single top-level %-tagged node render in preview mode
o % operator: This is the Preview Modifier. Render in transparent gray as default, but if any color was given, use that color instead with no transparency changes
o # operator: This is the Highlight Modifier. Always render it half-transparent. Use a color which is easily distinguishable from the current color.

Open question: How to choose an "easily distinguishable" color?

Michael

Why do you have the top two points separately? Are you distinguishing "a single top-level %-tagged node" from a non-top level %-tagged node?

I can think of uses for a non-rendered (ie not in the STL) object in the middle of a larger object, mainly from the visual documentation perspective. Particularly where it may be in multiple nested layers of translates/rotates etc, it is easier to add a % object there than to recreate all the layers for a separate top level node.

Yep, your described % colour behaviour is good.

Also need to consider %#cube(5); too. And

%translate()
    rotate()
        #cube();
// or
#translate()
    rotate()
        %cube()
// etc

I just tested, it currently makes no difference #% v's %# - with not much deep thought so far, this seems as it should.

The left most cubes (transparent brown) in above image are %#. Ugly, but seems OK.

From that image it appears # is already doing something to the colour (right cube v's next left #cube).
So it just needs the added transparency from you proposed # behaviour.

Marius Kintel
Owner

ok, my first point might not be important enough to spend time on.

Peter Uithoven
Marius Kintel kintel was assigned
Marius Kintel kintel referenced this issue from a commit
Marius Kintel kintel Modified tests for #304 794b80f
Marius Kintel kintel referenced this issue from a commit
Marius Kintel kintel Updated tests as part of #304 85d4656
Michael

Note Github has a problem serving your png's above

Marius Kintel
Owner

weird - anyway, they link to files inside the repository, so you should be able to find them there.

Michael

Nope, Github doesn't display them properly (a tiny little vertical line), downloading one (eg example024-expected.png) doesn't display either, I think they are corrupt.

Michael

Nope Github doesn't display them (ie via test/regression...), but it also doesn't display the old ones, so looks like a Github issue, assuming you could view them previously.

donbright
Collaborator

maybe its a brwoser thing? they are fine here on firefox/linux

Chris
Marius Kintel
Owner

Fine on Mac Chrome and Firefox

Michael

Interesting, checked just now, working. (same browser, no restart/reboot just a sleep/wakeup)
The interweb gnomes must have been busy...
gnome on strike

Michael

Yet to test # & % but noticed an issue first usage.
On file Open, both File/Open & File/Open Recent, the auto compile does not happen.
Auto reload & compile is ticked.
Just get the loaded message in the console.
Interestingly, after doing a manual compile, subsequent Opens do auto compile.
Close OS and re-run, then it does not compile first or any files loaded (ie open another) until manual compile is done.

Will examine color() and #/% later today, but my initial look is that it would be more useful if #%something() produced a different look than just #something(). edit/ thinking cap is on for what sort of look /edit

Marius Kintel
Owner

thanks for the test - I just fixed the reload issue.

Actually, #%something() does differ from #something() as the latter will take part in CSG operations and the former won't.

The idea is that by highlighting something, you want to find it, but don't worry too much about colors, so that's pretty much what that operator will provide. I will now call this the highlight operator.
The % operator is meant for illustration and will not take part in the rendering process. This will now be called the preview operator.

Michael

I said LOOK, it would just be handy so visually #% looks distinct from # or % IMO, but you're the man, I can live with it.

Marius Kintel
Owner

If you look carefully, they also look different :)
e.g., in the following example, the former doesn't perform CSG before highlighting, while the second does:

difference() {
  cube(15, center=true); 
  #%sphere(10);
}

translate([20,0,0])
difference() {
  cube(15, center=true); 
  #sphere(10);
}
Michael

OK it looks like it doing as intended, apart from the effect noted in issue #310, where it is not transparent when viewed from different sides and depending on the rendering order - but that's another issue.
e.g.
color highligh-preview a
color highligh-preview b

Marius Kintel
Owner

cool - thanks for testing!

Marius Kintel kintel closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.