<kintel>
peepsalot Thx. I think the key is to make sure the code producing vertices are equivalent between OpenCSG and final render
<buZz>
just had a discussion on revision
<InPhase>
foul_owl: When a design is out of reasonable levels for runtime, what I do is turn down resolution at the top level, and measure the scaling factor of the render times with resolution. It usually scales by number of facets with CGAL, but that can mean N^2, N^4, or other things, for different design approaches, particularly when minkowskis are involved. Measuring with some low res settings lets you
<InPhase>
quickly measure this factor, and then you can extrapolate up to your target resolution. If it is, in fact, completely unreasonable, then you can choose an acceptable resolution that is achievable, or hunt for the parts of the design that are making it scale completely unreasonably and redesign them.
<buZz>
some people are very charmed by the idea of reusing OpenSCAD's animation engine as a full demoscene engine
<buZz>
soooo; can we get music support in openscad? :D
<buZz>
hehehe jk
<InPhase>
foul_owl: Note that "number of facets" does not necessarily mean ones that make it into the final design. Invisible facets that need to have interactions calculated before they can be removed, can also impose a steep penalty.
<InPhase>
foul_owl: Remember to Design, Flush Caches, before each measurement. :)
<kintel>
peepsalot The curious thing is that that wireframe rendering bug crept into OpenSCAD at some random point in time, without us making changes to how we render wireframes. The wireframe shader is as old as OpenSCAD itself..
<InPhase>
kintel: Do we have wireframe tests?
<InPhase>
kintel: And... Is my testing algorithm adequate to detect the wireframe issue?
<kintel>
Yes, but only a single test
<InPhase>
"Ignore edge artifacts" was a design criteria for the test design. But there can be other test algorithms if it doesn't work for the purpose.
<kintel>
This isn't an edge artifact though
<kintel>
it's general z-fighting across the model
<InPhase>
Ah, ok. I hadn't been following along.
<kintel>
But CPU renderers and GPU renderers may behave sufficiently different not to trigger the issue
<InPhase>
Right...
<kintel>
Summary: Fixed pipeline vertex transformation generate slightly different vertices than GLSL, causing any GL_EQUAL depth testing to become unstable
<kintel>
OpenCSG uses fixed pipeline to generate z buffers, and OpenSCAD's wireframe renderer uses GLSL
<kintel>
Tested to fail on nVidia on Linux
<kintel>
I verified by porting OpenCSG to GLSL, which causes our wireframe rendering to work again, but with buggy regular rendering
<InPhase>
Failing design example code?
<kintel>
example001.scad :)
<InPhase>
So, some old stuff...
<kintel>
yeah, haven't tried to find the regression, but likely years. Possible a nVidia driver update even
<InPhase>
I don't get any z-fighting for example001.scad with intel graphics under Linux. But I ALSO don't get any wireframe for example001.scad in the master branch.
<kintel>
..or GPU generation
<InPhase>
The last release gives me a wire frame.
<InPhase>
For the master branch, clicking wireframe is basically a no-op.
<buZz>
can i eh, start a executable from a .scad? :P
<kintel>
Something is fishy on some drivers: I get "Fallback to SW vertex for line stipple" on macOS
<buZz>
thinking of ways to get a openscad animation synced to audio ;)
<InPhase>
buZz: No, and we intentionally won't add such a feature. :)
<buZz>
kintel: woa, macos still has opengl?
<kintel>
hehe, legacy is too powerful for even Apple to kill ;)
<buZz>
InPhase: any other ideas? :P starting music before and 'hoping it matches up' seems iffy
<buZz>
kintel: i saw those new M1 apples dont have it by default but have undocumented features to turn it back on, so weird
<InPhase>
buZz: Pre-generate and make a movie the sensible way? :)
<buZz>
InPhase: its for a democompo
<buZz>
so has to be realtime generated
<kintel>
buZz Run animation on the cmd-line and filter echo statements to a cmd-line sample player
<buZz>
actually
<buZz>
hmm
<InPhase>
buZz: You can set the framerate, and you can measure for a specific system under a specific load which animation frame rates are actually achievable by spec. But those rates are approximate in the end.
<buZz>
InPhase: yeah its fine, usually those compo machines are core i999999999 at 9999999ghz or something
<InPhase>
buZz: What I mean is it's pretty much guaranteed to end up desynched.
<buZz>
i'll just write it on a pentium4 or whatever
<buZz>
InPhase: yeah i gather
<buZz>
no way to stop rendering if a frame takes too long?
<InPhase>
Nope.
<buZz>
well, totally fine
<buZz>
frames wont get skipped i imagine
<buZz>
can i skip frames myself?
<buZz>
i'll just try something
<InPhase>
Canceling things in progress is a dodgy proposition with the current architecture.
<buZz>
maybe its ok if i just play a flute next to the screen
<InPhase>
lol
<buZz>
:D
<kintel>
..or if you rebuild OpenSCAD yourself, you can redirect ECHO to stdout, and use that to send a frame tick
<buZz>
it'll be in the 'wild compo' anyway, so almost anything goes
<buZz>
yeah that was something i considered aswell
<InPhase>
Yeah, certainly you could add a tick output. It simply doesn't exist.
<buZz>
then i could also just add libmikmok or something
<kintel>
caveat: This is likely on Windows, so "you're on your own" is somewhat of an understatement ;)
<buZz>
libmikmod*
<InPhase>
Other than image writing, but that's a little heavy for the purpose.
<buZz>
kintel: no :) i can say it has to be linux, np
<kintel>
cool, so the echo trick should work, and if your model is smallish, frame times should be somewhat consistent
<buZz>
plus i am not completely code deaf, just dont practise C/C++ enough i guess
<buZz>
yeah thats my thoughts too
<buZz>
you dont need a lot of triangles to make art
<buZz>
:)
<InPhase>
buZz: You could for example mount a RAM filesystem, put images from that animation in the RAM filesystem, and have another process that goes along deleting them and counting each one as a tick. This is stupidly hacky, but achieves the goal for a single pass of the animation.
<buZz>
yeaaah no, it has to be realtime-realtime
<InPhase>
That would be realtime.
<buZz>
oo
<buZz>
just for the tick
<buZz>
hehe
<InPhase>
Yeah. Wastefully hacky.
<buZz>
quite :D i like it
<InPhase>
But, RAM, so not too bad.
<buZz>
maybe i could mount a nullfs
<buZz>
:P
<InPhase>
Anything that you can do a monitor on for file open events.
ur5us has joined #openscad
<InPhase>
Animation goes a little bit slower when it's writing images, but that should be lessened a bit for a RAM fs, and you are proposing strong hardware.
<InPhase>
buZz: And I hereby issue a disclaimer against any and all tech support for that ridiculously hacky idea. ;)
<buZz>
InPhase: ilu2 <3
<buZz>
:)
<peepsalot>
kintel: my guess is that the bug was always there, but hardly anyone uses view edges with preview to notice it. Also having a model with various face normals (like sphere with high fragments) seems to bring make it a lot more noticeable (plus aforementioned using perspective view also makes it worse)
<buZz>
i was watching the 'PC Demo Compo' and maybe 50% of them were just webgl/js , so dumb
<peepsalot>
our one test of it, i don't think is using perspective view
<kintel>
..plus Linux tests run on a SW renderer
<kintel>
macOS tests run on HW, but the edges test is disabled due to "z buffer issues" :)
<kintel>
I can try to force HW for LInux and see what happens
<kintel>
peepsalot On Intel GPU, I do get edges on master, and I do get the rendering bug
<kintel>
..but interestingly enough: For exactly the camera angle used in tests, the rendering is perfect. Any other angle exposes the bug it seems : /
<peepsalot>
it happens on any GPU / graphics drive as far as I've seen
<peepsalot>
driver
<InPhase>
kintel: While humorous, that sounds suspicious as a coincidence...
<InPhase>
Let me find these angles...
<peepsalot>
ie regardless of softare or hardware rendering. also last I remember, I thought macOS CI uses some "Apple Software Renderer" for the driver
<InPhase>
kintel: There are a lot of angles in there for different things. Which angles were these?