teepee changed the topic of #openscad to: OpenSCAD - The Programmers Solid 3D CAD Modeller | This channel is logged! | Website: http://www.openscad.org/ | FAQ: https://goo.gl/pcT7y3 | Request features / report bugs: https://goo.gl/lj0JRI | Tutorial: https://bit.ly/37P6z0B | Books: https://bit.ly/3xlLcQq | FOSDEM 2020: https://bit.ly/35xZGy6 | Logs: https://bit.ly/32MfbH5
<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
<peepsalot> i thought not
<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)
<gbruno> [github] kintel closed issue #4525 (Problems in the preview) https://github.com/openscad/openscad/issues/4525
J23628 has joined #openscad
J236 has quit [Ping timeout: 260 seconds]
epony has joined #openscad
fedorafan has quit [Quit: Textual IRC Client: www.textualapp.com]
<gbruno> [github] kintel edited pull request #4576 (Refactor offscreen context management) https://github.com/openscad/openscad/pull/4576
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
teepee has quit [Quit: bye...]
teepee has joined #openscad
<gbruno> [github] cymplecy closed issue #4591 (Text isn't centered if ttb or btt direction used) https://github.com/openscad/openscad/issues/4591
Guest2 has joined #openscad
<Guest2> Did anyone try using Topology Optimization (TO) in openscad?
<Guest2> Let me know if anyone is interested. I wanna use TO to generate  3D CAD and simply the cross-section beam in the complex geometry.
Guest2 has quit [Quit: Client closed]
snakedGT has joined #openscad
epony has quit [Remote host closed the connection]
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
castaway has joined #openscad
snakedGT has quit [Remote host closed the connection]
snaked has quit [Remote host closed the connection]
snakedGT has joined #openscad
snaked has joined #openscad
epony has joined #openscad
epony has quit [Remote host closed the connection]
epony has joined #openscad
<gbruno> [github] asdil12 opened pull request #4592 (Allow printing by custom command) https://github.com/openscad/openscad/pull/4592
<gbruno> [github] asdil12 synchronize pull request #4592 (Allow printing by custom command) https://github.com/openscad/openscad/pull/4592
epony has quit [Remote host closed the connection]
<gbruno> [github] asdil12 synchronize pull request #4592 (Allow printing by custom command) https://github.com/openscad/openscad/pull/4592
kintel has joined #openscad
<teepee> nice, that looks like full size
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.
L29Ah has left #openscad [#openscad]
L29Ah has joined #openscad
epony has joined #openscad