<kintel>
-> ARB vertex program shaders, as used by OpenCSG have an option to use the fixed pipeline for vertex transformations, and the shader for everything else. OpenCSG uses this option
<kintel>
GLSL is either or (fixed or shader)
<kintel>
..so if we could render wireframes without a shader in OpenSCAD, it should work again.
<peepsalot>
wait, are there shaders in opencsg? i don't even remember
<kintel>
That's the shader I attempted to rewrite in GLSL
<kintel>
Only in SCS mode, not Goldfeather, so we should see a difference between those in OpenSCAD
<peepsalot>
hmm, "// Emulates eye texgen" i don't know what that means, sounds like for textured rendering? does openscad even use that code?
<kintel>
It's to obtain texture coordinates for reading the FBO at the same framebuffer position as is being currently written to
<kintel>
In GLSL we can use gl_FragCoord instead
<peepsalot>
i wonder if there any reason not to just hard-code "force goldfeather" instead of what we currently do which is use some kind of auto detect. iirc it ends up using goldfeather for all but the most trivial (i.e. no difference or intersections)
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<peepsalot>
not having to worry about two different algorithms would help simplify any refactoring that might be needed
<peepsalot>
kintel i think rendering wireframes without a shader would be a step backwards
<peepsalot>
would love to see us being able to use opengl 3.2 core profile
buZz has quit [Ping timeout: 276 seconds]
buZz has joined #openscad
buZz is now known as Guest9365
Guest9365 is now known as buZz
kintel has joined #openscad
<kintel>
peepsalot The differentiator between the algos are whether there are concave solids in the CSG tree
<peepsalot>
ah, that makes sense, its convexity based
<kintel>
Doing a convex decomposition could also be an idea, as we already do that for things like minkowski, but it may be expensive if the object changes often
<kintel>
Issue is that Goldfeather performance degenerates quickly if there are many subtractions
<peepsalot>
i wonder if geometry shader could blast through something like that
<kintel>
I haven't thought about that.. But a fast path for cases with better hardware is always nice, as long as it doesn't complicate the code too much
<peepsalot>
i only very vaguely understand what capabilities of a geometry shader would be
<kintel>
OpenCSG is pretty old though, it was written for OpenGL 1.x, so there may be better alternative algorithms by now, but I haven't seen libraries
<kintel>
One day, ray casting will outperform all of this, but mesh input is still the achilles' heel
<peepsalot>
yeah i don't think i've seen anything else like it which is emulating CSG for display only
<kintel>
I think there just isn't a huge need for it, so nobody is putting effort into research
<kintel>
peepsalot But yeah, I agree that reverting to the fixed pipeline is not desirable. I think my next try could be to implement GLSL shaders for all our rendering paths instead.
<kintel>
..and make sure we keep OpenCSG rendering paths in sync with application rendering paths
<kintel>
Same might apply to Goldfeather, but I haven't dug into that algo in detail yet
<peepsalot>
yeah i haven't had the energy to dig in and try rewriting opencsg, but I think that is needed in order to get around those shader based artifacts with holes in faces
<kintel>
Yeah, that's the box I opened a couple of days ago, but the rabbit hole is getting a bit deep already
<kintel>
Btw., do you have pointers to bugs or other records of existing rendering issues that I could keep an eye on?
<kintel>
(I finally have a couple of systems to test on with different OS'es and GPUs, so it's a lot easier now to look for commonalities)
Sauvin has quit [Read error: Connection reset by peer]
<J23628>
yeah at least E14
Sauvin has joined #openscad
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
snakedGT has quit [Quit: Leaving]
kintel has joined #openscad
Guest2 has joined #openscad
Guest2 has left #openscad [#openscad]
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ur5us has joined #openscad
<foul_owl>
Is there a way to view time left on a render? I left it running overnight and it's stuck on 999/1000
<J23628>
foul_owl no but some experimental features (fast-csg, manifold, lazy union) can speed up the render
teepee_ has joined #openscad
<teepee_>
so, dinner finished, may the demo competition begin ;-)
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
<J23628>
yes after their shedule is off by 1h20 no the final demos
<peepsalot>
kintel: the issue with random holes during preview + edges is the only major rendering issue I can think of. I think I first saw it from obliviand's original VBO PR, where they had noticed that happening and were trying to solve it.
<peepsalot>
however at the same time it was noted that the artifacts were not caused by the VBO code, and could be reproduced on earlier releases.
<peepsalot>
around that time, obliviand also reported that using higher precision calculations resulted in much worse artifacting. in hindsight it makes a little more sense, that using higher precision would be much less likely to get an exact match via GL_EQUAL ... although the internal buffer bit depth was never altered AFAIK, so *shrug*
<peepsalot>
I think the main vertex / fragCoord calculations would need to be identical across any shader used by opencsg for setting depth buffer, and openscad for coloring the faces
<peepsalot>
GLSL also has plenty of confusing options about high precision and low precision calcuations for values of the same nominal type bit size
castaway has quit [Ping timeout: 265 seconds]
<peepsalot>
I get that GPU aren't really designed with ultimate precision in mind, but I would hope that at least the calculation is deterministic and reproduceable across multiple shaders.