Building master this morning produced an odd problem: the F5 preview
shows a positive image of a volume that's been subtracted away, but only
across the top quarter (more or less) of the OpenSCAD preview pane, only
with the OpenSCAD window maximized, and only before I move the window.
Zooming out slides more of the model into the visible region below the
boundary. Zooming back out shows the boundary doesn't move.
Reducing the size of the window and moving it lower on the screen shows
that the positive overlay tracks the *absolute* screen position: the
lower boundary of the overlay has a fixed position with respect to the
bezel around the 1600x1200 LCD! Moving the window lower reveals more and
more of the correct view, until ...
Moving the window to put the boundary outside the preview pane
eliminates the problem, as you'd expect, but then moving the window up
again or maximizing it works perfectly: the rendering bug vanishes.
Starting OpenSCAD with no model, positioning the window a bit below the
top of the screen, and then loading the model contradicts everything I
just wrote: the boundary tracks only the window, *not* the absolute
screen, and eventually vanishes as I rotate the model. After that,
maximizing the window behaves fine during that session.
Clearing the caches has no effect.
So it looks like something has gone kaflooie in the F5 preview rendering
of negative volumes.
Now, ordinarily, I'd say this was a window manager or display driver
problem, but it's been triggered by some previous OpenSCAD versions and
Went Away with subsequent updates that were involved with other
rendering problems. I'm using Xubuntu 10.10 / nVidia, if that's any
help, and OpenSCAD 2011-12-28 works fine.
Compile-and-render with F6 seems to be OK, too.
The source for the model shown in the attached PNG is at:
Wordpress has a weird source-copy function: hover over the OpenSCAD
source listing at the bottom of the post and a set of buttons will
appear at the upper right of the block. You can then view the source as
a separate page (and save-as-text or copy-paste the whole thing) or
Anything else I can do to help track this one down?
A few questions to better determine what happened:
o Can you copy and paste me the output of Help->OpenGL info?
o Just to clarify: You've built the master from Dec 28 and the master from Jan 5, and the bug appeared after that?
o Can you copy and paste Help->OpenGL info from the working version as well, if it differs?
On Sun, 2012-01-08 at 02:44 +0100, Marius Kintel wrote:
> A few questions to better determine what happened:
Just to make things even more frustrating, building today's version
works *perfectly* on all my failing models, so (once again) the problem
has popped up and vanished. The various commits between 28 Dec and 7 Jan
don't seem to have anything to do with the problem, so I haven't the
foggiest idea what's happening.
Don has been patiently walking me through some version checking and this
box is 0.0.1 behind the OpenCSG state of the art. So I must re-fetch
that, rebuild everything, and see what transpires. Given even the
slightest bit of luck, it'll continue to work perfectly.
Until I get that settled, you may as well assume the hole is in my end
of the boat.
> Don has been patiently walking me through some version checking and this
> box is 0.0.1 behind the OpenCSG state of the art.
The OpenCSG 1.3.2 release contained some important fixes, so that's pretty much required for the F5 function to work properly.
Also, another debugging tip if this arises again:
If you're building the test suite, the opencsgtest program will render similarly to the F5 function to a png file. It would be interesting to know if you get different behavior between this and the GUI version.